IDR meeting at IETF 101 Monday, 15:50-17:20 pm, 3/19/2018 Room: Buckingham John is chairing, Sue is not here due to health issues. Jie is taking notes. Acee is on the Jabber room. 0) Agenda bashing and Chair's slides New note well. Please read it. John Scudder: MD5 "flag out" for LDP. MD5 is deprecated and considered insecure. This makes the security section of drafts more difficult. MPLS chairs bringing attention to their deprecating MD5 efforts. Will be presented in MPLS. Suggests that people in IDR may care. Alvaro Retana: MPLS group deprecating MD5, there will be presentation also in SAAG.We got a lot of pushback from security guys. Security wants everything protected. There are also other operational realities to deal with. RTG ADs are trying to have better communication with security ADs. TCP-AO has been specified for many years. ItĄ¯s the matter of implementation and deployment. We agreed to document scenarios and use cases for security considerations in routing. We could have some templates for the security section. We should at least mention security considerations in documents. John Scudder: Clarification. This draft will be discussed on Thursday MPLS session, and we can talk to Deborah about the bigger effort. Jeff Haas: Please see presentation I did in IEPG about this. (Mail will be sent to idr mailing list.) http://www.iepg.org/2018-03-18-ietf101/haas-iepg-101.pdf Code Point Allocations: FCFS is great, early allocation is also great. But requesting a specific out-of-sequence code point will take longer time. Please read RFC8126: guidelines for writing IANA section, section 1.3 has the checklist. Please be clear in your IANA request. Early Allocations: bgp-ls-eag, IANA section needs update. 3 drafts in WGLC. BGP-prefix-sid: one change needs discussion. Post-WGLC documents: mostly wait for shepherdsĄ¯ work. 1) Methods for Detection and Mitigation of BGP Route Leaks Kotikalapudi Sriram presenting. New version focus on RLP solution for inter-AS, draft-bgp-open-policy provides the solutions for intra-AS. Many sections moved to Appendix. Introduce the RLP attribute. Alex Azimov: Glad to see you link your draft to open policy draft. There is another draft you havenĄ¯t mentioned (eOTC). Disclosing of ISP AS relationships may be a concern. Suggest to merge the drafts to create some joint solution. Sriram: This draft have been here for 3 years, the disclosing of ISP AS relationship has been discussed and captured in appendix. We welcome the merging of the two drafts. The chairs can guide this. John: At what point do we think this is ready for implementation? Sriram: Per hop values. Other draft only has single flag. Basic idea is same. Need to figure out which to do. John: Please authors of both try to get this deal with. [Poll of who has read or willing to implement]. Please let's just get this recnciled so we can implement Acee: We'll implement the solution that gives us traction. 3 ways to do it. Sriram's proposal is currently most well discussed. Jared Mauch: Asking Acee about implementation that floods routes out all sessions as well. (RFC ? ) Acee: Path to backward compatibility, there'd be an easier way to do this. "Default default." 2) BGP Link State Extensions for IPv6 Segment Routing(SRv6) Gaurava Dawra presenting. The new version merged with another draft from Huawei. Introduce the TLVs, all function codes now in SRv6 Network Programming draft. John: Please fix the authors list. 3) BGP Signaling of IPv6-Segment-Routing-based VPN Networks Gaurava Dawra presenting. Will fix the authors list. Ali Sajassi: This draft is about BGP enabled VPN services, should be renamed and presented in BESS. John: Good point. Ali:This draft introduces a new encapsulation, what is the motivation? What is the benefit, why cannot be done with existing encapsulations (e.g. VxLAN). What about IPv4? Gaurav: The motivation is in SR architecture and the SRv6 NP draft. Ali: Can you summarize it in 2 sentences? Gaurav: Integrate vpn with TE services. Ali: Still donĄ¯t see the benefit compared to existing EVPNs over SRv6. Why do it? Performance improvement? Need discussion. Stephane Litkowski: Speaking as BESS chair, it needs to be presented in BESS but no time slot available this time, need to be presented on next IETF (Montreal). Jorge Rabadan: This needs to be presented in BESS. Do you mandate the advertisement of this VPN SID TLV? Gaurav: Not mandated. Depends on whether the originator supports SRv6. Jorge: I can re-use the existing label field. Gaurav: No. Originating router can be srv6 or vpn router. If you want to use srv6, then you need to attach it. Jorge: So itĄ¯s for all the EVPN routes except route-type 4? The SRv6 network programming draft talks about encoding the ESI label in the existing extended community, which I agree, but that is inconsistent with this draft. Gaurav: We are actually using the argument field. Jorge: If you make this the function and argument, and limit the length to 3 bytes each, you donĄ¯t need new TLV, can actually make the existing EVPN compatible with SRv6. In EVPN, we use BGP encapsulation attribute or encapsulation ext. comm to signal from the egress PE the tunnel and the length of VPN label identifier. Here defines another way to do this. Why not use the existing approach? Gaurav: Implicitly signaling the SRv6 (based on the local policy) tells whether you want to use SRv6 or VxLANĄ­ Jorge: need info in the route to make this decision, right? You're saying we don't need that. Need a way to signal ingress PE Why not signal encaps community/tunnel type? John: You will be presenting this at future bess. Out of time. Ali: Jorge says why use existing feature? It'll impact route packing. Why not use existing evpn? Then could use 20/24 bit. Gaurav: How is packing different? It's same attribute; packing should be same. Ali: If same, that's fine. If decide to use the new encapsulation, why not use the existing mechanism, convey the SID as part of the EVPN route? Etree, leaf indication bit etc. are not covered yet. Keyur: IDR is finalizing the tunnel encapsulation attribute draft, please donĄ¯t define a third mechanism. 4) BGP-LS Extension for Inter-AS Topology Retrieval Under Different Scenario Aijun Wang presenting Acee: I haven't read the draft. You redistributing route originator, RFC7752 prefix has both node and prefix descriptors. The node descriptor can just be the router-ID of the route originator, and I donĄ¯t think you need the new identifier. Aijun: In current BGP-LS, there is no prefix originator. Acee: It would be the node descriptor. It is used for the route originator, not the BGP speaker. Aijun: BGP-LS only reports the information it has in the local routing table. Acee: It can also from the OSPF AS external LSAs. AS-external routes are flooded throughout the entire routing domain. BGP-LS can use the originator ID of the AS external route. Ketan: As Acee said you already have it in OSPF, and you have source router ID in IS-IS for the same purpose. So I think (the new identifier) is not required. But the inter-AS part is necessary. Aijun: When the router run BGP-LS is not the originator, it does not report the originator of the external prefix to controller, so we cannot build the inter-AS topology automatically. 5) BGP Extended Community for Identifying the Target Node Jie Dong presenting Ali: Are you sending this extended community with the route target or in lieu of the route target? Jie: This extended community is independent from RT, they are for different purpose. Ali: How do you ensure the receivers with the target address will receive it? In BGP how to ensure the routes will be pushed to the specific target PE? Jie: Before reaching the target node, the BGP nodes will keep advertising the routes in the network. Jeff: Router-ID makes sense for intra-AS scenario, there is no guarantee that the collection of all addresses may not be unique. It does not work for inter-AS scenario, need some discussion. The current procedure describes the RR case, does not cover the confederation case. The inter-AS case may further complicate the procedure. DonĄ¯t think the flowspec use case is a good fit, in that case you may want to numerate the set of interfaces to receive the filter, so you may consider to use the interface set draft, or maybe consider to use a group ID to address a set of routers. Stephane: How is it different from the use of RT for MVPN or EVPN procedures? For example, currently use the IPv4 RTs in the explicit tracking for MVPN. Ruediger: In current BGP you have a mechanism for this, you can use BGP policy configuration to implement any kinds of filtering. Jie: But you need to do the configuration on each node. Ruediger: There is a trade-off. Whether rely on the vendors to implement it, or you use your signaling system and code the policy to the router configurations yourself. 6) BGP Link-State Extensions for BGP-only Fabric Ketan presenting. Keyur: I've not read this draft. There is no new TLVs defined. Is this a informational document, or is it doing something which requires interoperability or standardization? Ketan: This is proposed standard track because it describes the procedures for BGP only network, specify which descriptors are needed to ensure interoperability. Keyur: I may not choose to honor those procedures, just send everything in BGP-LS and should still work. Ketan: Links and nodes are described with right descriptors for two way. If they are done differently by implementation there's issues. The procedures are in this version, new TLVs may be introduced in future.