IETF 85 - GROW WG Meeting - November 9, 2012 Chair: Chris Morrow Minutes: Danny McPherson -------------------- Rob Shakir - BGP Error Handling Received 5 comments in IETF LC and RTG Dir review. 1. How do we classify errors? – Critical vs. Semantic - essentially, those that are length errors vs. those that are in content (current draft) – rename to “Critical” vs. “Non-Critical”? – Critical/Serious/Ignorable/Recoverable – Essentially, length errors as above, and then some special treatment – are Ignorable and Recoverable are special cases requiring knowledge of the attribute? – PROPOSAL: Follow recommendation to rename to “non-critical” unless there are better suggestions. 2. How much detail of how to classify errors should the draft go to? – Current level: Overview of key considerations for Critical vs. Non-Critical – no detailed analysis of particular attributes. – Lower level: As discussed by Chris Hall – discussion down to what level of framing error is acceptable and how certain we need to be. – PROPOSAL: Leave GROW draft as-is, and allow further detail in IDR draft (drat-ietf-idr-error- handling). 3.Analysis of existing behaviour (Section 3). – Is this required in the document? Potentially should be part of the problem statement. – Historically motivating treat-as-withdraw being implemented wider than Optional Transitive only. – This looks to be happening within draft-ietf-idr-error-handling. – PROPOSAL: Follow suggestion and integrate this into the problem statement section – noting historical view 4. Operational Toolset section in the draft. – Note that this potentially is a scope creep. Should it be separate? - PROPOSAL: Note criticality of addressing operational monitoring in parallel with changing procedures. Recommend that it is kept within this draft – rather than spinning separate draft off. 5. Duplication of requirements/analysis between sections. – Need to clarify wording, based on historical growth of the document – to be addressed following discussion of above proposals. Ready for publication? Feedback from WG: No comments, everyone "seemed" happy with this. -------------------- John Scudder - BGP Monitoring Protocol (BMP) Revision -02 - 07 This draft was last presented in IETF 75. Authors believe they have incorporated or choose not to incoporate all input to date. If you made suggestions please review draft now to make sure they weren't missed. He took one of three actions with feedback: - Incorporated (with credit, I hope), – Not incorporated on purpose, – Or conceivably dropped though I hope not. Please check. Changes from -02 through -07 were discussed as detailed in slides. John: "Analogies are like quickstand, so I won't use one.." Reudiger Volk: If there is actually a flood of bad announcements he thinks it would be extremely helpful to have a buffer for the first 'n' and push those out and to something that says "I'm getting flooded with bad stuff" so that there is diagnostic information easily available. John Scudder: Interensting, don't provide all but provide some. Rob Shakir: Comment on other ways to push data out. One of things in error handling work was logging remotely. In operational message draft in IDR there is a way to push it back towards the peer. Not sure if this has the same issue with implementions and John hightlighted. John Scudder: IETF way of inventing as many ways as possible to get information out of the router. Need to have conversation on list to see if WG is willing to take this 'ornament' on. Rob Shakir: Also echo's Reudiger's point. Robert Raszuk: In company using BGP message reflector. If not for experimental purposes, for monitoring stability of Internet. Question to entire group. John said if there is need, write new draft. Robert would like to write type into existing draft rather than writing a new draft. John: If this is for implementation of BMP running on server or X86 blade and not on router, comments about operational utility do not apply in that case. Jeff Haas: We do have MRT for dumping BGP information. We probably don't want to put this in the stream of an opeational router. Do we bound the data somehow? If we want to use BMP, we have to get this off the box without impacting the BGP service. If we want to do this then there probably needs to be parallel sesssions so box can survive. [NAME-1?]: How about you Have separate session? Suggestion that this mode is for router as parallel thing, best effort, and if you run out of buffer, then run it at lower priiroty. John Scudder: If at lower priority makes it even riskier per slow monitoring station and at risk of preemption, forcing buffers to build up. John Scudder: Would like to request discussion of this draft and these issues on the list, get discussion of this and gauge consensus of WG to accept or make changes, etc.. [NAME-2?]: Can you easily distinguish between installed and not installed paths, and if not, can you support this in order to enable RIS and make it much easier? I would like to distinguish best path (Loc-RIB) Jeff Haas: BGP gives us this data. [NAME-2?]: If BMP had this feature it'd be good to use it for that. Jeff Haas: Reflecting state coming in off the wire. If we did this we would need post route selection routes. Would be problematic and force data to be replicated and shared at several stages inside a router, which could be very problematic. [NAME-2?]; Then should we ask for this in "add path"? John Scudder: Don't want to say yes or no at the mic, let's take to mailing list and hear from everyone. Encouraged others to provide feedback on this as well. Danny McPherson: I understand why you don't want to lose state compression and send all messages. Given this, can we please at least list in draft that other ways that might need to be used to get visibility to all updates? John Scudder: Makes sense, will have a look at this. Reudiger Volk: I think that of growing interest is to figure out and trace back why routes don't make it post policy things into the RIB, esp. as more complicated policy will cause rejection of routes. We really need to be able to say WHY it was rejected (e.g., RPKI, policy, etc..). Are we expecting to see post policy records with reason code? John Scudder: Current spec is silent on this. It would be possible to be explict. In terms of decorating with reason, currently, do not, seems sensible thing to ask for. Need to go back and check the spec and see if messages can be extended to add later. Really good point.. Reudiger Volk: If reason field is missing would really like to see it included early on, because the whole thing gets a lot more attractive if can use that. John Scudder: Please comment. Review now, it's a good time. Getting ready to bake into software, want to get this published and want to be sure all issues have been addressed. Think of this as pre-WG LC LC, comments please! ----- Graceful BGP Session Shutdown - Pierre Francois John Scudder: Commented that they don't want to keep him dancing, will talk to offline about moving this along. ----- IRR draft from Eric - Would like to ask for adoption as WG document. Describes what is and isn't in IRR, what has and hasn't happened, and what's happened and where it is now. Chris Morrow (chair): Have to ask on mailing list if this sound like something that seems worthwhile to adopt. Chris Morrow (chair) will send message out to request adoption ------------ Chris Morrow (chair): Item came up through SIDR and IDR and discussion and ideas about route leaks. Do folks who operate networks care about this? Are these a problem that should be worked on? Ron Bonica: OPSEC is working on doocument related to this... For operating BGP securely, but not exactly this. Jeff Haas: One of things that came out of SIDR work is inital attempt to define taxonomy. If that work is still in SIDR pull it here, better qualified to deal with it here. Once we have place to talk about this we can work on issues related to route leaks and what to do about them. Chris Morrow (chair): Brian Dickson wrote three drafts related to this. They included some ideas about how to identify leaks. Separate from whether they're a problem or not. There's also a route leak draft from Shame Amante, Danny McPherson, Eric Osterweil, others? The draft say this is a real problem. Chair believes more discussion needs to talk place on whether this is a problme or not. Discission for work here would be good. Solve it somewhere, needs some help. Danny: This is a probem. Shane Amante / Level(3) agrees... Believes GROW is a good place to discuss this, and not certain this problem needs to be solved in BGP. Chris: Will address on list.., Adjourned.