IETF 65 Routing Area Meeting Minutes Notes taken by Adrian Farrel; minutes distilled by Bill Fenner Note when comparing against the agenda that the routing protocol standardization topic was moved to the end, since it was noted that it was the kind of topic that could expand to fill any amount of time. A summary of WG status reports BFD - port assignments from IANA so last update and then close CCAMP - 6 new RFCs published - new charter ok'd but WG is a little behind the milestones FORCES - no report IDR - 8 new RFCs published - base BGP spec and its companion documents - more documents still on RFC ed queue - some more work in progress - A bunch of I-Ds are in the working group but not progressing because of a lack of implementations. ISIS - no new RFCs - MIB is complete - recharter in progress L1VPN - two WG docs - may WG last call framework after this meeting - focus on basic model solution MANET - common message format was not anticipated when rechartered - now all looking at common format and everyone looking at it Question: would different protocols using the same message format be confused if they see each other's messages or would they use, e.g., different type codes to distinguish? A: looking at this. MPLS - met Monday morning - completing a couple of docs - one stuck in RFC ed queue - some issues around progressing LDP to draft standard; it has normative references to some documents that aren't yet draft standard. OSPF (slide) - docs progressing - OSPF PE/CE in RFC Ed queue - OSPF MANET flooding going ok - recharter under consideration PCE - architecture discussed in last telechat addressing comments now - generic requirements for protocol gone to ADs - chosen a protocol (PCEP) and are standardizing - 5 (sic) volunteers to write MIBs - requirements for discovery in progress - policy is being discussing PIM - major work item is through IESG RPSEC - first RFC is on its way - other work well progressed - few other docs to take up for review - possible recharter for a few new things RTGWG - IP FRR basically done - appear to have two implementations - will write up and complete - ordered FIB for 100% coverage against microloops - next steps for WG - poll in room suggests multicasts, advanced IP FRR for 100% coverage - GTSM (Pekka and Dave Meyer) SSM - Was only hanging around waiting for IESG review - now complete so close WG? VRRP (slide) - no meeting this time - v3 spec (IPv6) protocol draft has an interesting discuss - interaction with secure neighbor discovery (SEND) - MIB comments received and need respin - subsecond timers for VRRP v2 needs discussion Wider applicability of loop-free convergence (Stewart Bryant) (see slides for presentation) Discussion: - JP is concerned that you may not converge if you configure a one hop tunnel as an FA. Stewart agrees. - Eric Gray began an extensive discussion of whether this could be solved by simply never sending a packet out to the neighbor from which it was received ("split horizon"). The discussion covered a lot of ground; some of the points included: - Repairing a loop may be preferable to dropping a packet (e.g., because you don't have anywhere to send it) - Multi-hop microloops are still possible even with split horizon. - Can continue forwarding assuming that protection is available at the point of failure, then wait for convergence. - In the context of management (e.g., planned maintenance), there's no need to have any repair mechanism to avoid loops during these types of changes since they can be planned for. - Bill suggested that in the interest of time, we continue this conversation on the routing area mailing list. GELS status (Dimitri Papadimitrious) (see slides for presentation) The biggest points of discussion were: - Do solutions have to go to the IEEE for approval? - No, because we're constraining the solution space to those that already exist in the IEEE-defined data plane, we are not defining new ethernet mechanisms. - Are we reinventing label swapping? - No, we're using a mechanism that 802.1ad introduces. - Suggest liaising with MPLS to see if this is needed, with IEEE on data plane issues. - What's the plan for moving towards a working group? - thinking of a BoF at next IETF RFC1264 update (Alex Zinin) (see slides for presentation) The discussion mostly centered on scope. Example scope concerns: - LDP has been extended by PWE3 as a control protocol; while this document says those extensions are in scope, there was no expectation that would be the case when the work was begun. - The description of changing how packets are forwarded could be considered to apply to the DiffServ architecture. - There are BGP extensions that carry non-routing information - information that is not used to make any forwarding decisions. Is this covered? Yes. (Should it be?) - What problem is this trying to solve, and is it casting the net too wide? Protocol scaling? Packet formats? Original was more specific about the risk of new routing protocols. (The net is wide because the line is very unclear.) One observation was that much of the pushback against these rules come when they're sprung upon the WG at the end of the process - the WG says "here's something we're done with," the IESG says "surprise! here are some rules for you to comply with." It might be less frustrating if the status of a document is agreed to at the beginning of the work, when it's put on the WG charter. The tension between requiring implementations and requiring certain technologies was also discussed. For example, there is a strong desire to include IPv6 support in all protocols. If IPv6 support is a completely obvious extension (e.g., having another TLV with the same contents other than a larger address field), then why should an implementation be required? Other forward-looking topics include 4-byte AS numbers and strong security. Several comments brought up the problem that the IETF has with the time that it takes to get from I-D to RFC, and that these procedures would tend to make that longer. It was suggested to take the opportunity to make 1264 obsolete, and perhaps 2026 at the same time. It was noted that fixing 2026 is out of the scope of the routing area (and in the scope of newtrk). However, 2026 does permit requiring implementations for Proposed Standard, so the IESG could use that without any additional guidance as this document tries to provide. Implementors pointed out that customers want standardization before a sale; this introduces a bit of catch-22 with respect to implementing. What's the vendor's motivation to implement something that nobody is asking for, because it's not a standard, because it's not implemented? Many views were expressed, and it was clear that there was not a consensus on either side of the issue. Further discussion should happen on the routing-discussion list.