Welcome to Etherpad! This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents! Get involved with Etherpad at http://etherpad.org Agenda: Existing Drafts (10 mins) draft-ietf-grow-bmp-adj-rib-out - RFC8671 draft-ietf-grow-wkc-behavior - RFC8642 draft-sa-grow-maxprefix - Adopt? • Will not happen in GROW draft-ietf-grow-bmp-registries-change IESG bound draft-ietf-grow-bmp-peer-up Adopted draft-ietf-grow-bmp-tlv re-Charter Discussion Please discuss on-list Presentations: Camillo Cardona BMP Marking Extensions Draft overview: tries to communinicate the path status via BMP, be it best-path or otherwise Open Questions: Today the path-status is a different field, we might become very successful so maybe we want to have the path status be a variable length field Defintiitons of path status outside the BMP path marking draft - we might not have it defined in the draft, perhaps it will be somewhere else No Questions Next up: BMP loc-RIB - Paolo Lucente - NTT presenting No questions BMP-TLV support Adding TLV support to peer-down and route monitoring messages, update version number to support backward compatability Next steps: no open questions, we should wrap-up (last call?) Job/Chairs: Looking at implementors in room, are we good to go Jeff Haas/Juniper: I think there's a desire to make this done soon, and I think what you're going to find is this is a plug-in architecture for the rest of the group. If you try to finish this now, we will have to do it again. draft-lucente-grow-bmp-tlv-ebit Supporting of enterprise-specific TLVs in BMP Borrowing from idea in IPFIX for using PEN/IANA assigned private enterprise number. John Scudder/Juniper: We have seen at least one proposal of this kind in IDR also. I think it's a fine solution for the problem, but the push back we heard - when I use this playground to experiment in, I have to change my packet format when it is standardized. We have to try it to find out how it plays out. I don't believe this will get rid of squatting, but we might as well try. You could be lazy in two directions, you could define a code point in enterprise space, and may never migrate to IANA assigned space. Everyone has to put enterprise data into code base, or it ends up in RFC. 4 bytes of enterprise space, and 2 bytes of IANA space Jeff Haas/Juniper: John is likely referring to https://tools.ietf.org/html/draft-haas-idr-extended-experimental, and since people seldom get features right the first time, do people break their deployments by re-using the code points or use one from a larger range. The majority of comments I have on BMP - I'm wondering if the chairs would entertain 5 minutes at the end? (chairs: yes) Job Snjiders/NTT: The goal here is to have specifications that promote interoperability, what I worry about is that if we allow enterprise type TLVs we do not meed the objective of standardizing protocols. I also am very concerned about squatting in the space. Jared Mauch/Akamai: I think the point here is sometimes you need a standardized place to put your unique innovations to avoid squatting. Job/NTT: What you said here reminded me of the 'MAC Address Local Administrator bit' and how you can flip a single bit to achieve local significance. Perhaps a single bit is all that is needed rather than using PEN addresses. Ruediger Volk/DT: Jareds comment about making the metadata explicity managed, TLV makes it eaiser to parse and interpret BMP in MRT : Colin Petrie/NTT I put this together as an intitial idea to use MRT which is explicitly for this purpose. It supports type codes, so they can be added to and archived. MRT files are usually stateless, split by various time intervals and need to be parsed independently from the previous file. Questions: RV/DT: What you are talking about it essentially information from the presentation layer, it's incredibly hard to transition to something more future proof Jeff Haas/Juniper: This presentation is worth doing Thank you Colin next-up Yunan Gu BGP route policy trace with BMP We have been working with the team at Swisscom and they are interested in this draft. We have restructured the format, the data around the prefixes, attributes are not together. We have moved it into a TLV format. I'm looking for feedback on the future direction of this draft RV/DT: I'm really surprised I did not forsee this, you are mentioning that the policies are complex. The actual content and intent and use has complexity, I'm not sure if I am happy to include this complexity - which is related to the presentation layer. Job/NTT: I think it's an interesting discussion about what it means. I'm planning on looking at the work in the CBOR WG, there may be some appliciability here. Jeff Haas/Juniper: This is the exact comment, there's many binary protocols - the presentation of the binary may be unclear, but using a yang model would allow us to decode the message Next presentation: BMP for route leak detection I am looking for feedback on this proposal Alexander Asimov/Yandex: Since this draft depends on ASPA roles, that data isn't there on a per-prefix basis. Jared Mauch/Akamai: Much of this depends on the business logic, and while BMP is a great way to monitor the routes they may be unique based on the provider relationship and there's no good way to understand the intent behind the routing announcement. Next Presentation: draft-chen-grow-enhanced-as-loop-detection Routes with a AS_PATH loop in them may need to be detected for hijack cases, but the detection can be used to find configuration errors. Please send feedback to the mailing list for discussion Alexander Asimov/Yandex: My message is - the way it's stated in the draft, where you take updates is not limited to the scope of what's causing the route hijack or leak. It may have some prefixes captured by the upstream provider - these prefixes are seen from the outside. Also, it may highlight there may be a policy issue. Spealing of hijacks: BMP has a lot of options to be used, but getting experience in how it can be used, what information can be easily revealed in the monitoring. It would be very interesting for the industry to take up. Thomas Graf/Swiscomm: Maybe a use-case, perhaps use the signed origin for example Improv part of session - 5 minute update on their hackings We identified issues with the draft-ietf-grow-bmp-local-rib - it doesn't define what should happen when the route is locally originated, should provide some recommendations around the next-hop guidance. The peer-up message isn't consistent between vendors, should we make them consistent Chairs: Thank you for the report! Presenter: Paolo Lucente/NTT Compression of BMP route monitoring messages It's beleived that BMP may generate a lot of data, flag compressor info in a TLV in the init message John Scudder/Juniper: I hadn't heard of this work prior to this meeting, it's a very short draft. I like this work. The one warning is that tonys draft is an individual submission Ignas Bodonis/Equinix: Yes this is needed, this addressses a real problem on the processing side of the received BMP messages • What you are proposing a single message compression, is that valuable vs a larger set of data? • removing the marker will deserialize the message, this may take out some of that message • having a mechanisim to signal when compression starts may be of value to avoid replaying the entire stream if it's written to disk • Job/NTT: the topic of compression has come up in idr, if it were to become a wg item, it would concern me as an operator. often times when it comes to routing, it can be of importance to understand what happened on the wire and what's flowing through the system. I have concerns about debugging this. • Jared Mauch/Akamai: I may be bandwidth blessed, so I'd like to understand from other operators (in private) what they see as the issue, i'm concerned about any delays in the data flow due to batching. • Paolo: I've heard this from multiple sources since Chicago, I share the same concerns • Presentation/Jeff Haas: • The architectural implications of PDU formats - they have limitations - things that slow down the data flow make networks unhappy • 1) BMP is basically BGP - anything that happens in one impacts the other • 2) the majority of this is tagging the data on top of the attributes, if you are doing anything else with it, it forces the unpacking of the message. • The other general problem is that BMP has loc-rib and rib-out have strong correlation with existing data structures directly available, if the data that needs to be encoded isn't directly available, it may cause either memory or cpu impact to find or store that information more readily. • What we are doing in each of these BMP presentations is adding some level of annotation to the BGP messages • Recommendations: stick to core uses cases. For telemetry try to stick with the same data format. Several things involve attaching a string or parsing a string, we know this is very expensive to parse things with scanf() • John Heasley/NTT: YOu mentioned dictionaries, would a registry of the meanings make sense? • Jeff: many of these deserve a registry, there will always be something proprietary about where in the policy it's rejected may not be standard • Paolo/NTT: If you remember the packing isn't optimal, should we restructure these to make more sense? • Job/NTT: you are offering us foundational insights to help us better design protocols