Working group status: No new working group items. Moved one doc from this working group to softwires wg to reflect comments from last wg. - ----- Presentations: draft-dickson-idr-second-best: Brian Dickson Originally about second best and backup routes. Removed the "backup_only" mechanism from the I-D prior to the meeting in the protocol extension since it appears to not be strictly necessary. Will propose backup_only as a well known community instead. Provides a solution to path hunting and intended to fix persistent oscillations . Requires additional adj-rib-in (memory). Extra initialization costs. Update processing will be often reduced. Reducing path hunting reduces update frequency. and thus total cost. No impact to FIB size. Basic idea, pick local second best and send both best and second-best. When the best route is withdrawn use the second best. Calculation of new best deferred until we get a new second best. The second best route must always be feasible. Comparison with draft-walton: - - It [walton] only addresses oscillation. - - It requires more than 2 instances. - - It doesn't affect path hunting. Comparison with draft-filsfils - - Cute hack for fast convergence for one case. - - Requires multipath-bgp and carrying peering network in IGP. - - Only affects local convergence. Does not affect path hunting - - Needs comparison to second best in specific scenarios. Comparison with sigcomm2000 paper example. - - 4 router full mesh topology. - - [See slides.] Summary: - - Incremental to current bgp standard. - - Uses extra memory. - - Reduces CPU usage. - - Faster local and global convergence. Questions: Ilijitsch van Beijnum: Implementing this is a fair amount of work. Instead of going from 1 to 2 paths, why not go to multiple paths? Brian Dickson: That seems like a reasonable suggestion. It seems like something that would have to be negotiated between neighbors. Inter-vendor, inter-implementation issue. Would require additional changes to proposal. John Scudder: I was going to make almost to make the same comment. N is more attractive than 2. Disagrees with BD that it is a big design change. Wanted to point out - ... add path authors here? Draft-walton requires more than 2 instances - it does permit more routes. Thinks encoding more attractive. Innovation in your proposal is what is done with path selection rather than encoding. You should look at the draft-walton again BD: There were choices for encoding for withdrawals the way he did it. JS: Walton also withdraws the correct path. You also sorted the paths? Doesn't seem that crucial in the implementation BD: The reasoning between the choice of sorting is that when you get to choices of best path, you know that you've withdrawn the best path. It's a mark and sweep update process. Cleaner for bulk withdrawals. David Ward: Another take on "we need more than two". I don't think an attribute is a way to encode this. 1. Just send me multiple paths - let me choose. 2. Don't get caught using an attribute so we have ordering issues. Yakov Rekhter: I don't think it would work the way you said - DW: Knowing your choice of second best isn't useful? YR: Knowing your second best is what we want to do here. DW: I don't want my second bests getting thrashed in the control place. Chandra: Just make this N. Beyond 2, the churn in next bests is bad. BD - for every extra value, you have to run your path selection. This is very inefficient. Continue discussion on mailing list. A poll of the room thinks we should: 1. Solve the multiple path issue. 2. Uncertain response as to marking them first, second, third best.... 3. Doesn't think we should adopt this particular proposal (yet) - ----- draft-chakrabarti-idr-rfc4893-mod-00 (4 byte AS) Samita Chakrabarti [Slide commentary] Unclear about what to do when processing some of the messages. - - Proposal for handling as_path/as4_path - - Proposal for additional clarification text - - Proposal for specifying a open message notification - use an existing code. What problem does it address: - - Lack of clarity. - - Unclear spec = inconsistent implementation. - - Leads to interoperability issues. - - Human error is unavoidable - diagnostic info can help. - - Scenarios for transition. Change requests: - - Open message - AS_TRANS values on transmit only. - - Provide text for handling the receive case: + When AS4 capability is present, new BGP uses the cap and ignores open message AS. + If new BGP receives OPEN without AS4 capability it must use open message AS. if AS number is as_trans it sends notification. Old BGP implementation ignores AS4 capability. Section 4.2.1: What happens when old BGP peers with multiple AS with AS-TRANS? Proposed text: Careful considerations are required such that it does not affect the routing path of the traffic due to some local policy on AS number at the old BGP speaker. during transition to new BGP speaker from an old bgp speaker, the above scenario should be avoided. Comment from Enke Chen: RFC 2270 should be provided as guidance. Proposal for handling AS4 attributes: - - Always have AS_PATH as AS4_PATH from BGP [don't recompute AS_PATH] - - No overloading of AS_PATH as in RFC 4893 - - No conversion of AS4_PATH and AS4_AGGREGATOR - - Path length computed from AS_PATH Comments from Enke Chen and Geoff Huston - - Too late since there are implementations. - - Similar proposal was discussed and discarded. Proposal for notification: - - Notification code 2 and subcode 2 Transition cases: - - Point out cases where special care is needed. - - Possible ambiguity in originating AS. - - AS override at PE. - - PE routers must be converted to NBGP before CEs. Conclusion: - - Request wg to adopt proposals for clarifications and changes Questions: None. How many read draft? [Some] No one thinks we should do an update. Will take adoption question to mailing list. - ----- draft-van-beijnum-idr-iac-00 Iljitsch van Beijnum inter-as-cost Problem: - - No good inter-AS metric in bgp. - - No easy inbound traffic engineering. - - MED is one hop. - - Origin - not updated in transit. - - Only have the AS path length. AS path length: - - Increases with every hop. - - AS hierarchy is Too Flat. IAC - - Metric that is increased at every hop. - - Needs to be compatible with existing implementation. Solution: - - iaclocal: Uses path length plus IAC attribute. - - More granular than AS path length. Compatibility - - Don't want routers to suddenly change path selection after update. - - Solution: multiplier value. - - Deploy gradually in existing networks. Deployment - - Optional transitive attribute. - - Just won't increment/decrement if not recognized. Questions? Yakov Rekhter: draft-ietf-idr-bgp-dpa-05 It was a WG doc. just died out. (simple) draft-ietf-idr-bgp-metrics-00. WG and died. ("baroque" complexity) Take the past into consideration. Danny McPherson: Affects scalability of bgp due to yet another item in BGP. YR: One of these was un-deployable. It had persistent forwarding loops due to not being incrementally deployable. John Scudder: Incremental deployment observation that with these sorts of things - sites that are doing as path padding would still do so. What's the plausible path where people are using IAC instead? IvB: Depends on what these people want to accomplish. Rudiger Volk: Operators may not want to respect this value. That's not to say that this isn't deployable, but it's not straight forward. Brian Dickson: In the preamble - the origin attribute isn't usable? I've used it? IvB: Some vendor decided uses this in path selection. You wouldn't normally use this as an inter-as metric. BD: The sender is setting this value differentially. It's respected everywhere and it affects path selection. IvB: It has no fine grained influence. It's a very blunt tool. BD: More subtle than LOCAL_PREF or AS path padding. IvB: You don't update every hop. BD: That's a good thing. If this thing is an optional attribute - and can be configured to be ignored - this may achieve desired results. IvB: If someone in the middle has a different opinion they'll either not re-advertise or they'll change the IAC value themselves. Sue Hares: You should examine the discussion on the DPA attribute. BD: Don't know if we're seeing good analysis as to what different types of people are trying to accomplish with AS path padding. YR: What should the working group to do with draft? IvB: Talk about whether this is interesting or not? YR: Support for general idea? [Some] Support for this specific idea of a metric? [Some] Get more discussion going in the mailing list for more feedback. - ----- draft-ietf-idr-bgp4-mib2-06.txt Jeffrey Haas BGP MIBv2 update - - Brief history of what went on with BGP MIBs during standardization process. - - New v2MIB stalled while completing v1MIB during standardization. - - Author unavailable for IETF work for a while. MIB at that time wasn't in a state suitable for wide implementation. - - Last year working group decided to drop this working group item if there was no progress. - - As of today, there's a Juniper implementation of -04 of this draft. - - Author says current draft incorporates all previous comments, is integrated into base BGP MIB and ready for widespread implementation. Asks that the working group item be left up for another two sessions. Discussion: Yakov Rekhter: We had this on the working group chair for more than 7 years. Last year we agreed that it would only last one more year. Shall we continue? David Ward (Area Director): I have no objection if there is active work on the MIB. Jeff has done the active work on the MIB so we should do a last call. Jeffrey Haas: I have cleaned up the MIB and it is ready to implement. YR: We need an implementation to progress the draft. Juniper has an enterprise MIB that derives from the MIB. DW: We should have a last call on the document and progress it. JH: We should get two MIB doctors to look at the MIB and review it. DW: We can do "last call" and then have the MIB Doctors look at it. JH: The MIB doctors churned a bit on the original draft. Sue Hares: The MIB doctors also churned a bit on RFC 4273. DW: Jeff Haas should send a note requesting a MIB doctor review. YR: After the MIB doctor review, this document will go to final review. - ----- draft-manral-idr-mpls-explicit-null-00 Samita Chakrabarti 6PE-ALT [Slides] - - No change to protocol is required. - - Adds a new afi/safi combination to bgp - - Each route is at ached to a label and exchanged - - Use of this label: allows PHP, IPv4 explicit NULL label is used in last hop - - One IPv6 lookup can be prevented. RFC4798 gives reason to have 2 labels. 6PE-ALT - - Uses IPv6 explicit null as VPN inner label. - - Changes required: + Allows load balancing by using v4 null and v6 null + Ask IANA for another set o explicit null labels. Advantages: - - No additional signaling required. - - Memory savings of 8 bytes for every route (IPv6 null). - - Lookup faster. - - Any router having BGP IPv6 support can become 6PE router. - - Same functionality as 6PE in data plane. - - No different inter-provider changes affecting eBGP like 6PE. Feedback from v6ops and idr - - Lighter weight approach and can be used along with 6PE. Questions? Eric Rosen: The chance of getting new reserved label from IANA is very small (approaching zero). Eric Rosen: 6PE does not require a new AFI/SAFI, just an AFI/SAFI that some vendors may not have implemented. 6PE is already deployed, and there is no motivation to change the existing implementations just because some vendor would rather implement it differently. Yakov Rekhter: MPLS WG MUST buy into explicit null labels. Bounce this off mpls first. Francois Le Faucheu - said on list - not a good idea. Solves a solved problem. 6PE put in two options for a good reason. The extra signaling isn't that big of a deal. The AFI/SAFI was previously existing. Not advertising the extra label isn't that big of a deal. Francois Le Faucheur: with the lack of explicit signaling as proposed in 6PE-ALT, BGP routers could not disambiguate between: - an environment where IPv6 traffic is to be carried over IPv4 MPLS (ie a real 6PE scenario), and - an environment where IPv6 traffic is to be carried natively as IPv6 but where the native IPv6 addresses just happen to be IPv4- mapped addresses.