IDR WG minutes IETF-68 Prague March 21 2007 0900 1. Document status report (Yakov) Lots of progress in publishing docs as RFCs -- many published, many more in queue, see slides. Procedures for handling AFI allocations -- brief discussion at last IETF, subsequently on mailing list. Rules approved by IESG. We have SA, FCFS, and reserved. See slides for details. List of docs on which no progress -- see slides. No objections for draft-lefaucheur-idr-v4nlri-v6nh-00 as WG doc, but weak support. Since revised to -01. Note that softwire mesh framework refs this as normative, so there is need for this doc to exist, so will be accepted as IDR WG doc. BGP MIBv2 -- been around for six years. -05 version of draft expired a year ago and nobody seems to care. Editors seem to have abandoned it. Yakov and Sue periodically bump milestone forward a couple years. What should WG do with this draft? - Pekka Savola -- speaking as an operator, current MIB isn't sufficient, we are using new MIB and some vendors are implementing, for example being able to see amount of prefixes we receive and have filtered out is useful. Would be good to survey what is actually useful in MIBv2 - Sue Hares -- Pekka, can you do the MIB revision? - Pekka -- I'd be happy to send feedback but not to edit it. - Yakov -- unless we get an editor to adopt it, we won't have progress on it. Pekka, you have a valid point but without someone to work on it, there's nothing to be done. - Simon Leinen -- I also have concerns that this is really required to operate BGP in a multiprotocol world. I volunteer to do what's necessary to help. I'm not normally on the IDR mailing list, but I'm concerned about this. - Yakov -- OK, how about this? We extend the milestone one more year. If we make progress, great. If there's again no progress on the MIB, we remove the milestone. - Simon -- fair enough. draft-fedyk-bgp-te-attribute-02.txt (Hamid Ould-Brahim) Traffic Engineering Attribute -- completing VPN auto-discovery for L1VPN. See slides for details. - JP Vasseur -- should we resurrect 2 year old TE attribute draft we did for L3VPN and integrate the two? - Yakov -- which WG should it be in? L1VPN, L3VPN, CCAMP, IDR...? - Adrian Farrel -- we should discuss at routing area open meeting. CCAMP seems like the right place. - Yakov -- will integrate John Scudder's comments. - JP -- how about old draft? - Yakov -- old draft introduces new SAFI, we don't understand why. - JP -- would need to discuss with authors of old draft. draft-asati-bgp-mpls-blackhole-avoidance-00.txt (Rajiv Asati) Data plane failure in MPLS networks has bad consequences. Should fix this in the route resolvability check. See slides for details. - Ina Minei -- seems to me that this is implementation specific. Why should this be fixed at protocol level? Other implementations don't suffer from similar problems. - Rajiv -- fair enough. Just because some implementations don't suffer from a subset of the problem, doesn't mean it's not a valid problem. For example if you use ordered LDP that hides the problem, but what about data plane failures, e.g. data corruption? - Ina -- OK you agree that LDP-ordered fixes it. What about corruption in labeled path? Other implementations have a fix for that too. So, why spec it? - Rajiv -- well we can fix anything in theory. What is sense from operators in the room? - Ina -- AND, should solution be at protocol level or implementation level? - Yakov -- for presenter: what specific changes do you require from the protocol? What do I need to change to support this? - Rajiv -- bestpath changes. That's all. Not a change within the on- the-wire protocol at all. Other change is the means to interact with LSP Health DB. - Yakov -- LHD is outside scope of BGP, base spec doesn't talk about how to interact with ANY other protocols. Sounds like you want this WG to change route selection algorithm. - Chandra Appanna -- I pretty much agree that there is not much to standardize here. - Rajiv -- changing the route resolvability check is the only part relevant for the WG. - Ina -- and does that need to be spec'd? - Yakov -- well the current spec is nebulous. - Chandra -- maybe we need to say that implementations should be smart about interpreting what "next hop reachability means" - Yakov -- exactly. They shouldn't be dogmatic when reading the BGP spec. - ??? (name not stated at mic) -- I agree with Yakov. I suggest this is informational. LDP black holing is an implementation problem. I think that this is very helpful. - Yakov -- any closure on what to do with this doc? Anyone read it? (Lots of hands.) OK what do you want to do with doc? - Chandra -- if there is interest on the list, maybe this can be informational. Other than that, not much point in making the "be smart" statement. - Yakov -- one thing we should try to avoid is to prescribe a certain way of implementing. Not our business. - John Scudder -- fundamental premise OK but seems like a lot of pages to make a simple point, and too much implementation details. Isn't basic point that if network layer foo is used for forwarding, network layer foo reachability is needed to qualify NH? - John -- could make this a one-page doc that says "please be careful about selecting a next hop if j. random network layer reachability isn't there". - Yakov -- yes, that could be a one-page draft (one line plus boilerplate). - Yakov -- up to authors to do what they like bearing in mind comments.