############################ * Discuss Current Draughts draft-ietf-grow-bmp-adj-rib-out draft-ietf-grow-bmp-local-rib draft-ietf-grow-rpki-as-cones draft-ietf-grow-wkc-behavior draft-scudder-grow-bmp-registries-change ######################################### Randy Bush: I suggest to the people working on AS-Cones to talk to someone who knows security to have some guidance. There were no more questions nor comments ######################################################### * Solution for Route Leaks Using BGP Communities - sriram ######################################################### Sriram Ruediger Volk: This looks easy. Large communities can do it. Other things are complicated and we don't like it. For Large communities to make sure the propagation works the right way, we will need documentation giving advice on how to handle this in the local policy configurations. Without this advice, you are not getting an idea on how it's going to be handled. With Large commiunities available for things like this, I think providing some advice on how to handle it in policies is good. Consider also what Randy Bush is going to discuss later. It's a matter of time that 100% of the networks will be able to deal with them. Everything done to add features to large communities will take more time. Jacob: Someone will have to configure large communities for them to work. If you're relying on standard software to pass on large communities, things might be tricky. Sriram: We are hoping that the leaking ASn would let large communities pass. Job: There's still no weay for IANA to register well known large communities numbers. We will need a document for that. Ruediger Volk: The IDR chairs can request the global administrator AS. That will go into the registry then. My take is that working more with LC we will need it more and more. Job: Thank you. Sriram: Thank you. Please send feedback on the list. There were no more questions nor comments. ################################### * Communities Are EveryWear - Randy ################################### Randi Bush presented the slides. Jared Mauch: I'm curious about LC seeming to propagate much further than normal communities. Did you study it ? Randy: No Jared: Iss there any recommendation in the document about it ? Randy: No Chris: Are you asking Randy to write a document with recommendations ? Jared: Shall we align the behaviour with normal , extended large communities ? do we want to make recommendations on how to strip communities ? Juniper has the ability to do so, arbitrarily matching routes with a value in the TLV. Maybe we should give guidance to operators on what options to have. Randy: Good idea. Ruediger: I think some documentation about good practice on what BGP information is adequate would be a good thing. My view would be that there might be agreement on what to exchange between operators, but it's someone's responsibility (mic was cut.) Time was out. No more questions nor comments allowed. ############################################################ * Draft-ietf-grow-bmp-(local|adj)-rib(?:out) - Paolo Lucente ############################################################ Paolo Lucente presented the slides. Humming for last call was considered successful. (I missed the person who talked at this point and what he said. My etherpad session disconnected.) There were no more questions nor comments. ################################################### * draft-gu-grow-bmp-route-leak-detection - Yunan Gu ################################################### Yunan Gu Presented the slides. Jared Mauch: We are using BMP to validate our routing policy decisions and validate when we're leaking routes where it's not intended. You're trying to catch what Qrator labs have suggested to look at. There are cases where we route space internally, but we don't want it to leak outside. A document like this is incredibly valuable for us. YUnan: Thanks Alexander Azimov: What are you getting in advance in terms of BGP leak prevention ? You can detect but not prevent leaks with this method. Yunan: Correct. Alexander: You could have policy configured in your router. With this document, you have to configure all your peering in your system. This does not simplify the work of preventing route leask. Yunan: Correct. There were no more questions nor comments. ######################## * Living Documents - Job ######################## (can't figure out the name): This is a good idea. I was asked to look at the IGPs, and we were Can you start the ball rolling on this ? It would be immensely helpful. People could draw and add content. Valid security issues could be presented there. Alvaro Retana: I think this is a great idea. I wish more people would look at living documents because they are more useful. What more than a draft do you need ? A draft could be considered as the way of achieving this. Job: If you look at the optics of a draft, they're different from an RFC. The logistics of a draft are different. The URLs change, but we want something stable. We want something slightly different. (Didn't get the name): I would be in favour of having something long-lived as a standard. Tim Bruijnzeels: I worked on documents explaining how the RIPE NCC Validator and implementation works. I'd like to see this. Jeff Tentsura: I would like to be able to normatively reference this document. It wouldn't work if we keep it as a draft. Joel Jaeggli: I think We don't have a way to discuss about consensus for a document with. It seems the only requirement we have here is to have metadata to reference the document. Warren Kumari: I've heard people wanting something that's an RFC but that is not an RFC. Something in-between. You could do it as a WG document, calling last-call every now and then, but that would be strange. Ruediger Volk: It seems to me that considering consensus every now and then could be a broken idea. Having a precise versioning of official points could and should be done. I have the concern that there are things that are fundamental and never change, while there are things that are currently discussed and are moving. I think going for a living document will tend to expose what is being discuss, while the fundamental stable long-term things will not be presented the right way for newcomers, which should be focusing on them first. Job: Thank you for your feedback. We are attacking two problems at the same time: exploring live documents as a concept, and routing security explained to newcomers. Let's face these one at a time. We will meet tomorrow and then report to the list. We should start with a document soon. Jeff Tentsura: We started an effort a year ago to be able to reference non-IETF documents in IETF drafts. This could be interesting for this live document. Job: Please, email me the link. The session ended.