# IDR meeting at IETF 111 ## Session 1: Tuesday, 16:00-18:00 (UTC -7), July 27, 2021 ### 0. Agenda bashing and Chairs' Slides (10 mins) IDR will adopt draft-ietf-bgp-autoconf-considerations-01.txt IDR will welcome bgp autoconf protocol proposals. Interims on 8/23 (new drafts), 9/13 (flowspec-v2), 9/21 (TBD), and 10/11 (TBD). Potential topics: Auto-configuration protocols, and error handling for embedded NLRIs, and proposed topics. ### 1. BGP YANG model [Mahesh Jethanandani] (5 mins) https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model/ Major issues to be discussed today: extended communities and large communities. Jeff Haas: Explained the issues about large community , the extended communities and YANG typedef in detail. Jeff Haas: Please take a look at the open issues tracked at: https://github.com/mjethanandani/ietf-bgp-yang/issues. The target is to get most of the work done by next IETF. ### 2. BGP Color-Aware Routing (CAR) [Dhananjaya Rao] (10 mins) https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car/ There is ongoing effort to merge the two problem statement drafts. Srihari Sangli: It says you can advertise different labels for different encapsulations, are they still separate NLRI? As the labels in NLRI are non-key? Dhananjaya: Confirm that labels are non-key. Srihari: Raised the question about key/non-key on mail list. How will the NLRI grow with the key and non-key? For new attributes whether put it the NLRI or in the attribute would be a question. Dhananjaya: THe non-key in NLRI is for per-route specific information rather than generic attribute. Aijun Wang: What is the advantage to define new NLRI? It can be done with the existing color ext-community. Dhananjaya: Did not get the question fully, the color ext-comm is used to indicate the request for an intent. Can take to the list. Kaliraj (from chat): Is CAR a service-layer family or a transport-layer family? Ketan (from chat): they are two different SAFIs - one for transport other for service, Plz check sec 8 of the v02 for the VPN CAR. ### 3. BGP Classful Transport (BGP CT) [Kaliraj Vairavakkalai] (10 mins) https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes/ Linda Dunbar: Is the color consistent across all the nodes？Is this similar to Flex-Algo? Kaliraj: Flex-Algo is one approach for intra-domain. BGP-CT is for inter-domain. The color is usually consistent in one domain, but may not be consistent when cross domains. Border nodes can rewrite the route target. Linda: Can Flex-Algo be used inter-domain? Kaliraj: Even if it is the case, it can coexist with BGP-CT. Swadesh Agrawal: About local convergence. You need to do import at ABR. When advertising to the upstream, the same local label will be carried in different CT routes. THis seems like a hack. Kaliraj: The routes are collected into transport RIB. One reason is for service mapping to tunnels of a certain kind. There is no such thing in BGP CAR. Swadesh: BGP CAR can also provide the resolution based on the same color. What is the advantange of 2 different routes with different RDs but the same local label？ Kaliraj: The prefix allocation is on the scope of prefix:transport class. There is nothing that stops you from announcing two routes with the same label. The advantage is to tell the upstream ABR different nexthops. Swadesh: This can have some problem. Jeff: No time for further discussion. This is a interesting point. Please post this to the mailing list for further discussion. Haibo Wang: VPN routes use next-hop and color to match the transport tunnels. The key in BGP CT route (RD, prefix) does not match with the key used for VPN route resolution. Kaliraj: Didn't get the question. The service route asks for a tunnel resoluation of a color, the tunnel can be either intra-domain flex-algo or RSVP, or inter-domain BGP-CT. If there is no tunnel with the color, it will use best effort. Haibo: It would good to have further discussion of this on the list. ### 4. BGP MPLS-namespaces: Improve Scaling and Convergence in Seamless-MPLS networks [Kaliraj Vairavakkalai] (10 mins) https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels/ Swadesh: How many routes will be seen by the PE if the domain has 100 PEs and 1000 vrfs? Kaliraj: ... (some of response begun here)... Jeff: Suggest to take the discussion to the list. ### 5. Generic Metric for the AIGP attribute [Reshma Das] (10 mins) https://datatracker.ietf.org/doc/html/draft-ssangli-idr-bgp-generic-metric-aigp/ Swadesh: The metric type is decided by the original domain？I am not sure what benefit you are gaining over the IGP domain. Reshma: If you are low cost in one route in one domain, and delay in the metric in another domain. Shraddha: Can carry different metric types in different routes. Only metric of the same type can be accumulated. Swadesh: Is the metric type used to represent the intent? Try to understand the advantage. Shraddha/Reshma: We should discuss this on the list. ### 6. BGP SR Policy Extensions to Enable IFIT [Giuseppe Fioccola] (10 mins) https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-ifit/ No questions on the meeting. ### 7. Advertising p2mp policies in BGP [Hooman Bidgoli] (10 mins) https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy/ Gyan Mishra: Huaimo: We don't have BGP sessions to P nodes. P2MP SR Policy needs to send instructions to P nodes. Hooman: Does not require BGP sessions for each node, can use P2P Policy between nodes. If need replication segment Hop by Hop, will need BGP session to each node. Gyan: Is SRv6 and inter-domain covered? Hooman: It is covered in the drafts. Gyan: There is a mechanism in PCE WG. How does this interact with this mechanism? Hooman: The PCE mechanisms are a second mechanisms. Jeff: The draft also presented in BESS, the content will be developed in IDR. ### 8. BGP-LS with Multi-topology for SR based VTN [Cong Li] (10 mins) https://datatracker.ietf.org/doc/html/draft-xie-idr-bgpls-sr-vtn-mt/ Ketan (from chat): this is an informational document with really no signaling or protocol extensions for BGP-LS. Do we need such a draft? Note that consumers and use-cases for use of BGP-LS is outside the scope of BGP-LS. Best case, considering adding necessary text to the corresponding LSR draft ... which is also informational. Jie (from chat): Yes this is an informational document. Comparing to the LSR draft, it also covers the distribution of inter domain topology and TE attributes for a VTN. Les Ginsberg (from chat): @Jie +1 to what Ketan has said. The draft simply describes what is discussed in other drafts - I see no need for it. Time would be better spent in making sure all the drafts referenced in draft-xie-idr-bgpls-sr-vtn-mt are themselves complete.09:00:43 Jie Dong (from chat)： @Les we had similar discussion about the LSR draft, the consensus was it is useful to document the usage of MT for VTNs. ### 9. Deterministic Route Redistribution into BGP [Enke Chen] (10 mins) https://datatracker.ietf.org/doc/html/draft-chen-bgp-redist/ Note: Enke requested WG Adoption after -03.txt is posted. John Scudder (from chat）: I'm pretty sure this is a rerun (with different details) of a presentation Rich Woundy gave around IETF-30 or so, plus or minus. Same problem (ish). Same solution (ish). It even was implemented in early GateD, but poorly documented and nobody understood it. Maybe we can make the fix stick this time.08:50:43 ### 10. Update and Discussion on RD-ORF Solutions [Gyan Mishra/Aijun Wang] (10 mins) https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf/ https://tools.ietf.org/html/draft-wang-idr-vpn-routes-control-analysis/ No comments or questions on the meeting. ### 11. (If time allows) Connecting IPv4 Islands over IPv6 MPLS using 4PE [Gyan Mishra] (5 mins) https://tools.ietf.org/html/draft-mishra-v4-islands-v6-mpls-4PE/ No time to present. [5 minutes for switching] # IDR meeting at IETF 111 ## Session 1: Tuesday, 16:00-18:00 (UTC -7), July 27, 2021 ### 0. Agenda bashing and Chairs' Slides (10 mins) IDR will adopt draft-ietf-bgp-autoconf-considerations-01.txt IDR will welcome bgp autoconf protocol proposals. Interims on 8/23 (new drafts), 9/13 (flowspec-v2), 9/21 (TBD), and 10/11 (TBD). Potential topics: Auto-configuration protocols, and error handling for embedded NLRIs, and proposed topics. ### 1. BGP YANG model [Mahesh Jethanandani] (5 mins) https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model/ Major issues to be discussed today: extended communities and large communities. Jeff Haas: Explained the issues about large community , the extended communities and YANG typedef in detail. Jeff Haas: Please take a look at the open issues tracked at: https://github.com/mjethanandani/ietf-bgp-yang/issues. The target is to get most of the work done by next IETF. ### 2. BGP Color-Aware Routing (CAR) [Dhananjaya Rao] (10 mins) https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car/ There is ongoing effort to merge the two problem statement drafts. Srihari Sangli: It says you can advertise different labels for different encapsulations, are they still separate NLRI? As the labels in NLRI are non-key? Dhananjaya: Confirm that labels are non-key. Srihari: Raised the question about key/non-key on mail list. How will the NLRI grow with the key and non-key? For new attributes whether put it the NLRI or in the attribute would be a question. Dhananjaya: THe non-key in NLRI is for per-route specific information rather than generic attribute. Aijun Wang: What is the advantage to define new NLRI? It can be done with the existing color ext-community. Dhananjaya: Did not get the question fully, the color ext-comm is used to indicate the request for an intent. Can take to the list. Kaliraj (from chat): Is CAR a service-layer family or a transport-layer family? Ketan (from chat): they are two different SAFIs - one for transport other for service, Plz check sec 8 of the v02 for the VPN CAR. ### 3. BGP Classful Transport (BGP CT) [Kaliraj Vairavakkalai] (10 mins) https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes/ Linda Dunbar: Is the color consistent across all the nodes？Is this similar to Flex-Algo? Kaliraj: Flex-Algo is one approach for intra-domain. BGP-CT is for inter-domain. The color is usually consistent in one domain, but may not be consistent when cross domains. Border nodes can rewrite the route target. Linda: Can Flex-Algo be used inter-domain? Kaliraj: Even if it is the case, it can coexist with BGP-CT. Swadesh Agrawal: About local convergence. You need to do import at ABR. When advertising to the upstream, the same local label will be carried in different CT routes. THis seems like a hack. Kaliraj: The routes are collected into transport RIB. One reason is for service mapping to tunnels of a certain kind. There is no such thing in BGP CAR. Swadesh: BGP CAR can also provide the resolution based on the same color. What is the advantange of 2 different routes with different RDs but the same local label？ Kaliraj: The prefix allocation is on the scope of prefix:transport class. There is nothing that stops you from announcing two routes with the same label. The advantage is to tell the upstream ABR different nexthops. Swadesh: This can have some problem. Jeff: No time for further discussion. This is a interesting point. Please post this to the mailing list for further discussion. Haibo Wang: VPN routes use next-hop and color to match the transport tunnels. The key in BGP CT route (RD, prefix) does not match with the key used for VPN route resolution. Kaliraj: Didn't get the question. The service route asks for a tunnel resoluation of a color, the tunnel can be either intra-domain flex-algo or RSVP, or inter-domain BGP-CT. If there is no tunnel with the color, it will use best effort. Haibo: It would good to have further discussion of this on the list. ### 4. BGP MPLS-namespaces: Improve Scaling and Convergence in Seamless-MPLS networks [Kaliraj Vairavakkalai] (10 mins) https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels/ Swadesh: How many routes will be seen by the PE if the domain has 100 PEs and 1000 vrfs? Kaliraj: ... (some of response begun here)... Jeff: Suggest to take the discussion to the list. ### 5. Generic Metric for the AIGP attribute [Reshma Das] (10 mins) https://datatracker.ietf.org/doc/html/draft-ssangli-idr-bgp-generic-metric-aigp/ Swadesh: The metric type is decided by the original domain？I am not sure what benefit you are gaining over the IGP domain. Reshma: If you are low cost in one route in one domain, and delay in the metric in another domain. Shraddha: Can carry different metric types in different routes. Only metric of the same type can be accumulated. Swadesh: Is the metric type used to represent the intent? Try to understand the advantage. Shraddha/Reshma: We should discuss this on the list. ### 6. BGP SR Policy Extensions to Enable IFIT [Giuseppe Fioccola] (10 mins) https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-ifit/ No questions on the meeting. ### 7. Advertising p2mp policies in BGP [Hooman Bidgoli] (10 mins) https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy/ Gyan Mishra: Huaimo: We don't have BGP sessions to P nodes. P2MP SR Policy needs to send instructions to P nodes. Hooman: Does not require BGP sessions for each node, can use P2P Policy between nodes. If need replication segment Hop by Hop, will need BGP session to each node. Gyan: Is SRv6 and inter-domain covered? Hooman: It is covered in the drafts. Gyan: There is a mechanism in PCE WG. How does this interact with this mechanism? Hooman: The PCE mechanisms are a second mechanisms. Jeff: The draft also presented in BESS, the content will be developed in IDR. ### 8. BGP-LS with Multi-topology for SR based VTN [Cong Li] (10 mins) https://datatracker.ietf.org/doc/html/draft-xie-idr-bgpls-sr-vtn-mt/ Ketan (from chat): this is an informational document with really no signaling or protocol extensions for BGP-LS. Do we need such a draft? Note that consumers and use-cases for use of BGP-LS is outside the scope of BGP-LS. Best case, considering adding necessary text to the corresponding LSR draft ... which is also informational. Jie (from chat): Yes this is an informational document. Comparing to the LSR draft, it also covers the distribution of inter domain topology and TE attributes for a VTN. Les Ginsberg (from chat): @Jie +1 to what Ketan has said. The draft simply describes what is discussed in other drafts - I see no need for it. Time would be better spent in making sure all the drafts referenced in draft-xie-idr-bgpls-sr-vtn-mt are themselves complete.09:00:43 Jie Dong (from chat)： @Les we had similar discussion about the LSR draft, the consensus was it is useful to document the usage of MT for VTNs. ### 9. Deterministic Route Redistribution into BGP [Enke Chen] (10 mins) https://datatracker.ietf.org/doc/html/draft-chen-bgp-redist/ Note: Enke requested WG Adoption after -03.txt is posted. John Scudder (from chat）: I'm pretty sure this is a rerun (with different details) of a presentation Rich Woundy gave around IETF-30 or so, plus or minus. Same problem (ish). Same solution (ish). It even was implemented in early GateD, but poorly documented and nobody understood it. Maybe we can make the fix stick this time.08:50:43 ### 10. Update and Discussion on RD-ORF Solutions [Gyan Mishra/Aijun Wang] (10 mins) https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf/ https://tools.ietf.org/html/draft-wang-idr-vpn-routes-control-analysis/ Jeff: Will have an interim on Auguest 23 to discuss this topic. ### 11. (If time allows) Connecting IPv4 Islands over IPv6 MPLS using 4PE [Gyan Mishra] (5 mins) https://tools.ietf.org/html/draft-mishra-v4-islands-v6-mpls-4PE/ No time to present. May move to the second idr session. Sue: Will send out the draft adoption list. [5 minutes for switching] ## Session 2: Friday, 14:30-15:30 (UTC -7), July 30, 2021 ### 0. Agenda bashing (5 mins) ### 1. BGP over Quic [Zhenbin Li/Shuanglong Chen] (10 mins) https://datatracker.ietf.org/doc/html/draft-chen-idr-bgp-over-quic/ Sergey Fomin: Useful and interesting work. Comment 1: The delay in BGP connection establishment may not be an issue. It is a minor benefit. Comment 2: Not clear how the certificate management could be simplified with BGP over Quic. Jeff Haas: The certificate part will be an interesting work. TLS can provide integrity and privacy, but cannot protect the session agaisnt some types of attacks. Something in TCP-AO is not seen in the TLS implementations. Robin Li: For the delay part, in scenarios where a large amount of BGP sessions are reestablished, the session setup time may become an issue. Sergey Fomin: If consider the overall time for BGP session establishment, the route exchange and the installation, the session setup time is really negligible. Can discuss further offline. (From chat) Tom Hill: Robin - have you measured any improvement in seeding a full DFZ table? I recall some time ago that there was a lot of excitement over 9000b MTU for BGP convergence speed. Does QUIC help here? Jared Mauch: @Jeff - w/ TLS, what if the certificate expires in the middle of the session? (worried) Tom Hill: In reference to Sergey's point, I guess that if QUIC were to 'make BGP better', it may be there. Jared Mauch: P-MTU for iBGP works well for BGP.. i've not seen the transport be the slow part of BGP in a very long time Tony Li: Typically, BGP is not transport limited. Tom Hill: If it doesn't help, so be it. Curious to hear if any testing has been undertaken. Jeffrey Haas: Jared, bgp works fine over all sorts of things so on one part I'm not worried. On another part, my work in tls libraries has shown they're buggy and may not be up to bgp sessions staying up for months to years. ia Sergey Fomin: QUIC could be an interested application as a replacement for some current BGP over IPSec connectivity usecases. Think like SDwan, cloud peerings, etc Jared Mauch: Yes, i share your concern about long lived sessions.. by the time one bounces the TSV/Q people may have rev'ed it a few times (Keep in mind many networks may see TCP/BGP sessions up in times measured in years) ### 2. BGP Dissemination of FlowSpec for Transport Aware Mobility [Linda Dunbar] (10 mins) https://datatracker.ietf.org/doc/html/draft-dmc-idr-flowspec-tn-aware-mobility/ Sue：Encourage authors to indicate whether this is for flowspec v1 or flowspec v2. Is this for flowspec v1? Linda: Yes this is for flowspec v1. Jeff: The indirection ID part is compatible with flowspec v1. Authors are encouraged to talk about the interaction with other actions today. The interaction and control of multiple actions is one major motivation for v2. The application of the matching criteria belongs to v1, encourage authors to consider the ordering with other flowspec rules. Linda: Will add text to address the ordering issue. Tianji Jiang: UPF+PE is confusing. To which node the Flowspec rules are sent from the controller? Linda: The flowspec control goes to PE. More information in the RTGWG presentation on Wed. Kausik: Another draft in RTGWG has more information covering the UPF. Sue: Please send further comments to the list. Will have longer discussion about Flowspec on an interim. ### 3. Flowspec TTL (Time to Live) Match [Philippe Bergeon] (7 mins) https://datatracker.ietf.org/doc/html/draft-bergeon-flowspec-ttl-match/ Sue: Is this for both v1 and v2? Philippe: Yes. Jeff: This is ddos related, while it requires a new component type, which need to be done in V2. draft-haas-flowspec-capability-bits proposed to try to carry new things in v1. Philippe: Does it mean adding new component without that draft is impossible? Jeff Haas: The consensus from the interim was to not work on the capability-bit draft for v1 and do this kind of extensions in v2. Sue: The feedback from the intrim was to move v2 quickly forward. Appreciate to put this feature in V2. (From chat) Robert Raszuk: Well TTL could be added to v1 only if we define that it is single match in MP_REACH. So it would not impact any of other MP_REACH fields. Even without adding capabilities Jeff Tantsura: only range would be meaningful. Jeffrey Haas: you cannot add flowspec component types without causing session resets. ### 4. Extended Communities Derived from Route Targets [Jeffrey Zhang] (10 mins) https://datatracker.ietf.org/doc/html/draft-zzhang-idr-rt-derived-community/ https://datatracker.ietf.org/doc/html/draft-zzhang-idr-tunnel-encapsulation-label-stack/ 4.1 label stack in Tunnel Encaps Ask for WG adoption on label-stack draft. Jie Dong (from chat): @Jeffrey, can BGP SR policy provide the steering functionality you want? 4.2 RT derived Extended Communities Ask for WG adoption of this informational draft. ### 5. BGP for BIER-TE Path [Huaimo Chen] (10 mins) https://datatracker.ietf.org/doc/html/draft-chen-idr-bier-te-path/ Jeff Tantsura (from chat): @Huaimo - requests BIER-TE path over BGP? Sue: Please take comments to the list. May take a look at the interation between PMSI tunnel attribute and this work. Tony Przygienda (from chat): Pmsi signaling doesn’t encode the path normally just Id. ### 6. (If time allows) BGP Peer Auto-Configuration [Venkata Shiva] (5 mins) https://datatracker.ietf.org/doc/html/draft-minto-idr-bgp-autodiscovery/ Acee: This is similar to Xiaohu's autodiscovery draft, with different encoding. Jeyananth: This is simple protocol without two-way mechanism. Jeff Haas: The lack of state machine is the biggest changes comparing to Xiaohu's draft, which is with LDP thinking. The design team's consideration is not to prefer the session based approach, but more prefer the annoucement based like the L2 solutions. Acee: We certainly need more auto discovery proposals. Jeff Haas: The design team have agreed on the requirements and the contents, we will work on the PDU encodings. Please provide proposals and comments to the list. Sue: Today is the deadline to send the comments on the BGP autoconf requirements. [5 minutes for switching]