# IDR meeting at IETF 108 ## Friday, 14:10-15:50 UTC, July 31, 2020 ### Materials: https://datatracker.ietf.org/meeting/108/session/idr/ ### Meetecho: http://www.meetecho.com/ietf108/idr/ ### Collaborate on Note Takingļ¼š https://codimd.ietf.org/notes-ietf-108-idr/ (recommended) https://etherpad.ietf.org:9009/p/notes-ietf-108-idr/ ### 0. Agenda bashing and Chair's slides (10 mins) Requests for WG LC and WG adoptions will be sent to the idr list after the meeting. Check it. ### 1. RD based ORF [Wei Wang/Aijun Wang] (10 mins) https://tools.ietf.org/html/draft-wang-idr-rd-orf/ Wei Wang presenting. praveen Mada: I have a single domain case I want to ask a question regarding. When PE1 injects a prefix, will it impact other routers which are not overflowing the source? Wei Wang: The RR will check the IP source address, and it will not send to PE2 and PE4. Praveen Mada: It would be useful to provide more detail on the use cases in the draft. Do you have any implementation experience with this draft? Wei Wang: I cannot hear the question. John Scudder: Please take the questions to the list to regarding the use case and the implementation experience. Keyur Patel: The back-pressure to the PE may not be required. The prefix filter level filtering has more expense than a higher level filters. [Robert Razuk (chat list)]: An RD-ORF there was a number of technical problems sent to the list. None of these were addressed. This is not the right way to filter VPN. ### 2. BGP SR Policy Extensions to Enable IFIT [Giuseppe Fioccola] (10 mins) https://tools.ietf.org/html/draft-qin-idr-sr-policy-ifit/ Giuseppe presenting. WG adoption requested. [no questions] [from chat]: [Ketan Talaulikar]: Having a routing/control plane considerations of IFIT proposal in some document would help. Right now it is being introduced in multiple protocols, but I'm not getting a proper picture. Please point to any document that I am missing. Giuseppe: Good point @Ketan good point we will give a proper picture in the next revision. Ketan Talaulikar @ Giuseppe. Thanks. Would really appreciate a sort of routing consideration section in your base IFIT document that puts out requirements for all these various routing protocols that you are proposing to add IFIT extensions to. It would make it easier for review.10:49:04 Giuseppe Fioccola: @Ketan A new section in the beginning of the draft can help to clarify. We will work on that10:59:10 Joel: Hmm. I thought the ifit proposal in other WGs was distinct from the ioam and alternatve marking proposals.10:26:32] Giuseppe: Joel yes in other documents IFIT is also associated with the framework but in this document we just use IFIT acronym as "In situ Flow Information Telemtry" to summarize in one word IOAM and Alt Mark methods. @Giuseppe - given the different use of the term, I find it confusing to use it in this draft to mean "these two other things". @Giuseppe - depending upon how the draft evolves, the term may well become irrelevant. In which case it is not needed. [end chat] ### 3. BGP Bitmask Route Target and RT-Constrain Extension [Jeffrey Zhang] (15 mins) https://tools.ietf.org/html/draft-zzhang-idr-bitmask-route-target/ https://tools.ietf.org/html/draft-zzhang-idr-bgp-rt-constrains-extension/ Jeffrey Zhang presenting.. Jie Dong: First comment on the bit mask route target. Is it main use matching the group defined in teas. Jeffrey: yes, this is the use case. Jie Dong: We had another draft describing the generalized RTC which was not adopted. The draft-ietf-idr-bgp-ipv6-rt-constrain has a mechanism to allow for this. Jeffrey: The global administrator could be an IP address. Jie Dong: If the global administrator could be a prefix, and that would be a issue. Haibo: Why not use a (not heard) prefix? The receiver which receives the routes. Jeffrey: I will need follow up online. [from chat room] Jeff Haas: Please repost the general rtc draft name? Jie, Juniper's implementation of rtc-c allows for short than host length for rtc filtring. Haibo: rt-c RFC4684 is applied to many address families. This extension works in similarly address family agnostic fashion. Jie: http://tools.ietf.org/html/draft-dong-idr-vpn-route-constrain-02.txt Jeff: Thank you Jie. I recall reviewing at the time. I'll re-review for applicability to our problem. Jie: Another question is can the BIT mask RT be advertised in RTC as prefix? Jeff: Jie, there's still some encoding discussions happening with the authors about how a wide community rt-c would look, even for a dense case like we have in the proposed draft. Jeffrey Haas: Please expect us to followup the list on that point, Jie. Haibo Wang: @Jeff, Yes, RFC4684 is applied to many address families, but I don't think it's a good idea. If we want to extension the RTC, why not we may set AFI to resolve the problem like Jie has shown. Jeffrey Haas: Haibo, this discussion point covers a portion of what we had with the draft Jie had posted moments ago. We don't currently segregate route target types to specific vpn technologies.10:47:32 Haibo Wang: My another comments is that, whether should we to do it like RTC or like RFC7543 CP-ORF10:48:05 Robert: RFC4684 does not allow to send RT as a prefix. NLRI says fixed 8 octets. I proposed to the authors addition of RT as a variable length prefix as well - but that was not mentioned during the presentation. Jeff: Your memory for rfc4684 is incorrect, Robert. "The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 0 to 96 bits, encoded as defined in section 4 of [5]." Robert Razuk: Clearly RTC ... ORF is not transitive. RFC7543 Robert Raszuk: @Jeff - yes I take it back ... I was thinking about SAFI 128 not RTC10:52:09 Jeffrey Haas: It's okay, Robert. We keep repeating that point about RFC4684, so it's clear that it's in people's heads as being fixed length for some reason.10:53:44 Robert Raszuk: Probably as RFC does not show length field in the figure :)10:55:17 and figure says 8 bytes not 0-8 bytes too10:55:45 Jeffrey Haas: That would make sense, Robert. That may be worth an errata.10:56:12 Robert Raszuk: Agree.10:56:29 Bill Fenner: @jhaas in fact I had to fix tcpdump for that case too10:54:14 Jeffrey Haas: !Bill, probably because of our implementation. :-)10:54:30 [end chat room] ### 4. BGP-LS with Multi-topology for SR based VTN [Cong Li/Jie Dong] (10 mins) https://tools.ietf.org/html/draft-xie-idr-bgpls-sr-vtn-mt/ (Cong Li presenting) [chat room start (not sure if this is the correct link] Ketan Talaulikar: I'll post my comment here to save time. BGP-LS has been specified as a northbound distribution mechanism for topology information from network to controllers. One of these drafts is proposing to re-purpose BGP-LS for southbound provisioning. Leaving aside whethr BGP is suitable for this, why not consider doing this as a separate Conficg SAFI? Floor questinos: Zhaohui Zhang: Can we chat about scalability. The Bit mask route target has ways to reduce the flow. Jie: We have some BGP based mechanisms regarding this topic. We can talk about this more on the list. ### 5.Traffic Steering using BGP Flowspec with SRv6 Policy [Yisong Liu] (10 mins) https://tools.ietf.org/html/draft-jiang-idr-ts-flowspec-srv6-policy/ [Jeff]: As an author of the redirect IP draft, since you are specifying more than one community you need to be careful how this interactions. [Kaliraj Vairavakkalai]: How does this work with the inter-domain case? [Yisong]: We'll consider this information in future drafts. ### 6. BGP-LS Extensions for Advertising Path MTU [Yongqing Zhu/Shuping Peng] (10 mins) https://tools.ietf.org/html/draft-zhu-idr-bgp-ls-path-mtu/ (Shuping Peng presenting) WG Adoption called for by authors. Ketan: The draft is a trill draft that describes RFC7176. [missing the response from shuping so notes get text from Shuping] Ketan: Thank you for the clarification Jeffrey Haas: Shuping, with regard to the link MTU draft, I think it's a useful feature. However, I would suggest the document provide a warning that this is the signaled MTU which may be different in bad cases from the actual MTU. this is usually from configuration mismatches in a control plane and a data plane component.11:04:57 Tom Hill: +1 Jeffrey & Ketan - there are many "MTUs"11:06:25 It is otherwise not a bad idea11:06:49 Jeffrey Haas: IMO, having a way for probed MTU to be published in bgp-ls is a nice feature.11:06:52 but since once of the pathological cases is LAG with mismatched MTU component links...11:07:18 Takuya Miyasaka: The title of this document is confusing. I think it should be [BGP-LS Extensions for Advertising "Link" MTU]. 11:08. 11; Shuping Peng @Jeffrey, thank you for the comments. Your concern is acknowledged and we plan to add it in the next version.11:12:07 Alvaro Retana: @Ketan: The registry shows that the sub-TLV applies to the "normal" TLVs: 22, 23, etc.. It seems to me that we should be ok.11:12:10 Ketan Talaulikar: @ Alvaro : yes we should ok ### 7. BGP Classful Transport Planes [Kaliraj Vairavakkalai] (15 mins) https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes/ (kaliraj Vairavakkalai presenting) Robert Razuk: Today transport class can be embedded in the SID. Here we are opening it up to explicit signalling ... I understand you may want to support RSVP TE but not sure if this extra complexity is really needed. (read by Sue) [chat room: Jeffrey Haas: Robert, while it can cover such a scenario, this draft supplants the problems we were trying to solve in the prior labeled-color-unicast draft.11:21:09 So, a degree of similar flexibility is desired.11:21:19 Robert: @Jeff: I like the new SAFI sepration if we go for that .. I recall the BGP 3107 discussions about it too. Just not sure we still need it if we are up to SR everywhere paradigm Kaliraj: Works with other deployed technologies for tunnels we have. It is good to have a layer which I'm not sure if you are referring to Jie Dong: Policy has a color and and nlri. Are you transferring color as a SR-TE tunnels? [Kaliraj]: The color is the transport color of that tunnel. We will create a transport class with a color so that it fits seamless into the SR-TE tunnel. [scribed missed a portion of text] [Jie Dong]: I will take up more on this topic online. ### 8. (If time allows) Controller Based BGP Multicast Signaling [Jeffrey Zhang] (5 mins) https://tools.ietf.org/html/draft-ietf-bess-bgp-multicast-controller/ John: By the careful help of the presenters and by some miracle we have time for the last presentation. (Jeffrey Zhang presenting) [request early allocation for the code points ] John Scudder: The "any encap" would you be able to use a multiple next hop mechanism in BGP. The controller want you to replicate across 2 tunnels. Jeffrey: For one down stream ways to get to a down stream node, go through any of the 20 tunnels. John: If we had a way to represent 20 next hops, you would have used it (observation). The load balancing tunnel is not limited to multicast. Jeffrey: The load balancing concept introduced for multicast purpose. There seems to be an existing tunnel for the load-balancing of unicast. [missing a portion of the discussion. John: The programming incoming packet handling. The whole model that tunnel-encaps used is that you send information regarding the head of the tunnel. Your drafts talk about the tail of the tunnel. Jeffrey: Can you provide a bit more information on the tail end? John: ingress is head ends, and egress is tail end. Jeffrey: The route sent to all points. For the route sent to the egress point, it is for the Kaliraj: This is a reserved layer. Jeffrey: This gets to beyond the tunnel encapsulation draft. We are talking about controller signaling. Every router will use the same label. That label will be assigned by a controller. Kaliraj: Like from a static route configuration. To John, we did propose multiple next hops for a bGP route. Jeffrey: Could we use tunnel encapsulation instead of multiple next hops. Kaliraj: This draft is giving a specific tunnel endpoint. Your draft is slightly different. ### 9. WG adoption calls requested https://tools.ietf.org/html/draft-qin-idr-sr-policy-ifit/ https://tools.ietf.org/html/draft-zhu-idr-bgp-ls-path-mtu/ ### #### [5 minutes for switching]