1 / 13

Update on Routing Protocol Standardization Process

This RFC provides background, motivation, requirements, and discussion on updating the standardization process for routing protocols to ensure scalability and stability in the Internet. It addresses the need for multiple implementations, document quality, and operational experience. The discussion covers the scope, extensions, and security considerations.

quasar
Télécharger la présentation

Update on Routing Protocol Standardization Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RFC 1264 UpdateIETF-65, Dallas, TX, USA Alex ZininRTG Area Director zinin@psg.com

  2. Contents • RFC 1264 Background • Draft-fenner-zinin • Discussion review • Comments

  3. RFC 1264 Background • Dates back to 1991: • Before RFC2026 • Before IESG approved documents • Yet, still the de facto process • Process (2026 now) allows IESG to ask for implementations for PS • RFC1264 documents what IESG is asking for Routing Protocols, i.e. FYI to community • AD practice showed document needs to be updated or retired

  4. RFC 1264 Motivation • “…reduce the risk that there will be serious technical problems with a routing protocol after it reaches Draft Standard.“ • “…to insure that the new routing protocol will support the continued growth of the Internet. “ • “Routing protocols are complex, widely distributed, real-time algorithms. They are difficult to implement and to test.“

  5. RFC 1264 Requirements • Problem: • Ensuring spec quality required 2 or more implementations • NOT THEORETICAL • Have been asking this for PS

  6. RFC 1264 Discussion • Initial discussion: • Made suggestion to deprecate RFC1264 • Got push back • Revised version • draft-fenner-zinin-rtg-standard-reqts-01.txt

  7. draft-fenner-zinin- • Motivation for elevating reqs for routing: “… greater cost of a mistake compared to other technologies used in the Internet, as well as in particular attention to the scaling characteristics” • Goals: • Document quality • Eliminate first-order problems, understand scaling & dynamics • Full STD only if implemented independently, scales well, and have operational experience • Ensure manageability using open, standard interface

  8. draft-fenner-zinin-… • Scope definition: • Distributed • Spans more than one link OR • Otherwise affects distributed routing state or forwarding behavior • Extensions • Examples: • In: OSPF, BGP, RSVP-TE, LDP • Out: VRRP, FORCES • Variance procedure defined for exception handling

  9. draft-fenner-zinin- Requirements • Two or more implementations for PS • Security description is not submitted separately

  10. Discussion Digest • Agreement that 1 implementation should be required for PS • Asking for “2 or more”: general • Pro: stronger “Running Code” req is Good for the Internet • Better filtering of practical mechanisms • Better STD quality • Con: more red tape will slow things more • More frustration • More “standard” I-Ds

  11. Discussion Digest… • Asking for “2 or more”: conflicts • IPv6: want to see it in specs; what if not implemented? • Security: ditto • What is in scope? • Why not DNS or DHCP?

  12. Discussion • Comments?

  13. Thank you!

More Related