RFC 1264 Update IETF-65, Dallas, TX, USA

1
RFC 1264 UpdateIETF-65, Dallas, TX, USA

• Alex ZininRTG Area Director
• zinin_at_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
PS DS STD
Spec Quality Allow indep. interop. implementations from spec Allow indep. interop. implementations from spec Allow indep. interop. implementations from spec
Implementations gt1 gt2 gt3
Security Authentication Tested Works as expected
Testing Major features tsted Tsted btw gt2 Tsted btw gt2
Ops Experience Non reqed Significant Signific, lrg scale
MIB I-D PS Together

• 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
PS DS STD
Spec Quality Allow indep. interop. implementations from spec Allow indep. interop. implementations from spec Allow indep. interop. implementations from spec
Implementations gt2 gt2 gt3
Security Authentication Tested Works as expected
Testing Major features tsted Tsted btw gt2 Tsted btw gt2
Ops Experience Non reqed Significant Signific, lrg scale
MIB I-D PS Together

• 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!