IDR meeting at IETF 102 (version 3) Session I: Thursday, 18:10-19:10, 7/19/2018 Room: Viger 0) Agenda bashing (5) Keyur: Presentation #4 is not adopted according email list message, so why is on the agenda? John: There is quite some discussion going around on requirements and neighbor and liveliness dicussions. Many proposals emerged, and chairs didn't expect that this particluar topic would be on the agenda right now. Randy was asked to redeliver the talk from LSVR on requirements at at IDR WG Keyur: If solutions that are not adopted, we should removed it from speaking about on the agenda John: No, request noted, but it remains on the agenda Jeff Tantsura: The BGP model depends on the policy in the rtgwg model (draft-ietf-rtgwg-policy-model-03), and it is not done. Sue Hares: How quickly can you get it done. Jeff Tantsura: It is only 60% done. Sue Hares: Perhaps you should put it on high priority to get it done. 1) Update on merger of RLP and eOTC drafts for route leaks solution [Kotikalapudi Sriram] (8) https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation (solution)/ https://tools.ietf.org/html/draft-sriram-idr-route-leak-solution-discussion-00 (design discussion) Sriram presents the draft to WG Jacob H: Abouta year ago i put in a draft on another solution for this. So that neighbor can check this type of aspects. Did you see that? Sriram: Maybe Alexander can comment Sue: The chairs want a specific answer to Sriram questions and we need to focus on that and be specific if you discuss around something else Alexander: I would like to understand why we go from attribute to community. Attribute is better, but will take years and years. We know the limites of the communities, there may be issues, so please comment Randy Bush: Locally community communities are very strongly authenticated and integrity verified John Scudder: So that was a joke, go ahead please. Job Snijders: It's no difference for attributes like this. This doesn't need to propagate very far, so in the limited radius there is already benefits. John Scudder: 2) BGP Model for Service Provider Networks [Keyur Patel] (8) https://tools.ietf.org/html/draft-ietf-idr-bgp-model/ Keyur presents on YANG model updates Acee Lindem: We talked about this offline. You are going to change it to augment IETF routing protocol model instead of being at the top. Keyur:The model compiles, we'll make the change suggested. Would like to take it to WG LC. Dhanendra (Cisco): Do you plan to define BGP RIB structure in the base one? Keyur: Yes. Dhanendra (Cisco): And need to add support for clear RPC. Keyur: The clear should be taken on a separate track. Dhanendra (Cisco): The policy extensions, if policy extensions are required, then it looks like extensions for policy may need to be thought about also in the model Keyur: this model has only base extensions, and would like to reference these features to the extensions draft track Sue: What needs to change in the base model? Keyur: RIB Himanhsu: What extension will be needed for the BGP EVPN and L2VPN? Keyur: The AFI/SAFI support and the related BGP parameters. Himanhsu: Will it overlap with the BESS EVPN L2VPN model? Keyur: It should not overlap with the BESS EVPN L2VPN model 3) BGP Extra Extended Community [Jakob Heitz] (8) https://tools.ietf.org/html/draft-heitz-idr-extra-extended-community/ Jakob Heitz Cisco presents the draft Keyur: What if the WG thinks we need 30 byte communities 6 months later. Will we define a new AFI/SAFI for another RTC? Jakob: Yes. Keyur: I suggest based on that I suggest we stay with the wide community. Jeff Haas: We already did refactoring. Let's do the transitivity. Yeah! Let's do that. I do not like the 6 bytes. It may work for your code, but it does not work for mine. If put the field in the beginning we can have variable-size and do parsing based on the type. Jakob: (comment regarding length of time to be deployed) --- John: Both "unreasonable positions" have been noted - go on. Sue: +1. Jorge Rabadan: I am confused about your slide. The new RT are to be used in addition, and not as replacement. I assume that all your EVPN PEs need to support this community. That needs migration. Jakob: There will be no conversion between old and new. It could be done, but I would not do that Jorge: If you send both to all the leafs, then there is no gain as you still have to configure the other RT. Job Snijder: I want to comment on the transitivity aspect. Jeff Hass and keyur created some drafts on this. Maybe using common headers/container. From a marketing perspective saying that it is just like large communities, but then bigger, but transitivity should be the considered. How we solve this as WG it should be considered. Per attribute, per community or per color etc. may not be ideal. We need to think how to push to market Jakob: We need to look into scoping the solution. Chairs: 4) BGP Neighbor Autodiscovery [Ketan Talaulikar] (8) https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery/ Ketan presents the draft Chairs: we are 10 minutes in overtime, it would be appreciated if time can be respected Chairs: Due to the current status of the draft, lets not dig into further details at this time for the interest of time 5) Requirements for BGP Neighbor Autodiscovery (15) LSVR Hello Neighbor Requirements [Randy Bush] (8) Discussion (7) Randy Bush: Presents requirements summary Sue: The only thing I mentioned in the LSVR was the ES-IS protocol. John: Probes WG to understand if this a topic of interest to the WG: Mostly HUMS say yes John: Probes if we understand the requirements for IDR: Mostly hum that we don't know exactly the requirement Jeff Haas: LSVR has the liveness requirement, we don't, that may bias the solution. The solutions offered have significant overlap. I do not think we are far from the actual requirements. Keyur: +1 to Jeff Haas. We should think about this work to apply to IDR, LSVR, and to other points. John: The AD has asked us to work with the LSVR to have a unified solution instead of 2 proposals. Rajiv: Most of the MDSC are going to be IPv6. We should leverage IPv6 neighbor discovery or at least add it to analysis. Acee: The requirements have a lot more then that as the capability of IPv6 neighbor discovery Rajiv:I would like to ask if this list is expanded with IPv6 ND. John: Lets take the requirements as they are Acee: Lets make clear that the liveness requirement is not BGP liveness, but Ether liveliness Randy: I would like IDR to not take this up. LSVR has a constrained problem. IDR can expand to known universe. Ali Sajasi:With respect to the LLDP option, I would consider if Jumbo frame can be considered. John: Let's take of time have this address with the people that know more about LLDP Keyur: Jumbo frames is good to have, but not necessary. You do not want to go beyond one hop. John: Almost certain we will schedule an interim to talk about this. [Total 52 minutes] Session II: Friday, 11:50-13:20, 7/20/2018 Room: Place du Canada 0) Agenda bashing and Chair's slides (10) Sue and John Go over the Chair slides - Chairs ask for volunteers to be shepherds. - Chairs ask to know about implementations 1) LOCAL_PREF Overloaded = Overwritten [Alexander Azimov] (5) Alexander presents the slides Ruediger Volk: I do not like the idea that the router is setting attributes outside of the policy configuration. It is unlikely that there is any use-case related that should need such a solution. I prefer locally controlled policies as that is under operator control, with maybe vendor support for simple well known standard policies to insert if needed Alex: DT is fully capable, and so is NTT and so are the other 50k ISPs. In FRR (Open source router) and in there the local policy is already overwritten. John Scudder (as contributor): If you have a complicated set of criteria of policies, then you still have to come to conclusion. What about BGP custom decision, a WG document that is potentially applicable. I wonder if this is a problem that really needs to be solved, but it has been there for 2 decades Alvaro: Echo what John said. The custom decision draft addresses some of this. Alexander: The default policies that overwrite route-maps give me uncomfortable feeling. Ruediger: the concept of providing a library of standard policies would be a good thing. Alexander: People may copy it without understanding what they are doing. Templates going in the wild not really working. Jeff Haas: We are running into two things. Number space is gigantic. Another location of consideration that is messy is the tie breaking process, and the influence of extensions that have impact upon these preference tie breaking concepts. It may be worthwhile to have a draft to discuss these aspects 2) Updates to BGP Signaled SR Policies [Dhanendra Jain] (8) https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy/ Dhanendhra provides draft update Andrew Stone (Nokia): No a comment on this draft, wider scope. Consider advertise the range of Binding SID? Dhanendhra: we have plan to add deriving the binding SID from SRLB. Jeff Tantsura: Would be interesting to describe how the feedback mechanism works as the machinery is spread over different drafts Sue(Chair): Please put in a security section before WG LC. Ehsan Rezaaifar (Nokia): Signaling policy using BGP is OK, What about feedback mechanisms. If controller is peering with a RR, then there is no way for a controller to know if this is something that router can support this? Chair: this discussion go to deep, let have the discussion after the WG meeting Ehsan Rezaaifar(Nokia); The problem is router should advertise the capability using the same mechanisms (AFI/SAFI). Ketan: Fact that router support the capability and is peering with RR, whether that's sufficient indication of the capability. Keyur: I would like to see sections added to describe the RR in forwarding path, vs. the RR off forwarding path. 3) YANG data model for BGP Segment Routing Extensions [Dhanendra Jain] (8) https://tools.ietf.org/html/draft-dhjain-spring-bgp-sr-yang/ Dhanendra presenting draft John: let's keep the comments brief. Sue Hares (contributer hat): Work with RTGWG on policy. Please look at Keyur extension draft and harmonize/restructure the work. Is this based upon any other traffic studies outside of SPRING use-cases? Dhanendra: Yes, ther eare SR extensions in BGP. The approach is take the minto BGP and augmenting the structure. I will look at the BGPextension model, especially the BRIB model. Yes, it is in the context of SPRING and this related to it. Jeff Tantsura: We are trying to align all policies in single document. Naming of the document is policy , but is not doing BGP policy is unfortunate naming. Dhanendra: ack Jeff: there are some comon types in routing and they should be used in this document also 4) BGP-LS Extend for Inter-AS Topology Retrieval [Aijun Wang] (10) https://tools.ietf.org/html/draft-wang-idr-bgpls-inter-as-topology-ext/ Aijun presents draft John (Chair): Adoption discussion on list Ketan: It would be good to describe the new TLVs in the document Jeff Tantsura: The address space used on the interconnection address space is uncommon to be imported into the IGP. The adres space frm other operator does not belong in your IGP address space. 5) Distribution of Traffic Engineering (TE) Policies and State using BGP-LS [Ketan Talaulikar] (10) https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution/ Ketan presenting draft Jeff Tantsura: Anytime you signal something then you should be telling also how it is retrieved as this is distribution of operationalstate 6) Flexible Algorithm Definition Advertisement with BGP Link-State [Ketan Talaulikar] (5) https://tools.ietf.org/html/draft-ketant-idr-bgp-ls-flex-algo/ Ketan deliver presentation BGP Link-State Extensions for Seamless BFD [Ketan Talaulikar] https://tools.ietf.org/html/draft-li-idr-bgp-ls-sbfd-extensions/ Ketan deliver presentation John (Chair):We have little time. WG adoption request noted and request will be taken to the list 7) Applying BGP flowspec rules on a specific interface set [Jeff Haas] (5) https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset/ Jeff presents draft No comments or questions 8) Segment Routing Policies for Path Segment and Bi-directional Path [Cheng Li] (15) https://tools.ietf.org/html/draft-li-idr-sr-policy-path-segment-distribution/ SR Policies for Path Segment and Bi-directional Path in BGP-LS [Cheng Li] https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-segment/ Cheng Li presents drafts No comments and questions 9) BGP-LS Extensions for Advertising Path MTU [Fenghua Zhao/Zhibo Hu] (10) https://tools.ietf.org/html/draft-zhu-idr-bgp-ls-path-mtu/ Fenghua presents draft Jeff Tansura : There are multiple MTU's in play. Which one do you want to advertise? Fenghua: Let me come back Victor: Is there operator input that this likely a problem or something that will happen in real live? Fenghua: I will get back through email list [Total 86 minutes]