## First IDR Session: November 7, 2023 {#first-idr-session-november-7-2023} 13:00-15:00 (CET) Tuesday session II Room: Ballroom ### 0. Agenda bashing and Chairs' Slides (10 mins) {#0-agenda-bashing-and-chairs-slides-10-mins} [Chairs] Sue introduced the status of documents in IDR. ### 1. Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle (5 mins) {#1-segment-routing-bgp-egress-peer-engineering-over-layer-2-bundle-5-mins} draft-lin-idr-sr-epe-over-l2bundle-03 [Mengxiao Chen / Changwang Lin] No comment. ### 2. BGP SR Policy Extensions for Path Scheduling (10 mins) {#2-bgp-sr-policy-extensions-for-path-scheduling-10-mins} draft-zzd-idr-sr-policy-scheduling-03 [Li Zhang] Duruv: The PCE RFC is for RSVP-TE, there are also documents in TEAS talks about scheduled resources, also focusing RSVP-TE now. The encoding is a little different, suggest to have consistency between protocols. Fang Gao: A simple question. SR Policy is controller based computation. Are you proposing a data plane (device based) solution? Do you have a use case? Li: The data plane is the same. It is still SR Policy. Fang Gao: Can the controller trigger the path switch on time? Ketan: Do we need the protocol encoding here? Why couldn't controller run a scheduler and download the path when it is the time? Jie: With the tidal usecase the scheduling is predictable, so that the policy sheduling can be pre-provisioned to the headend and take effect at the specific time precisely. Ketan: Maybe need to see what is in the TVR architecture. Jie: Agree. Jeff: what is the format of the 32-bit time value in the encoding? 32-bit Unix time value will stop working in 2038. Andrew: Make sure TVR is aware of this work. It could have some impact there. Li: The tidal network use case has been documented in TVR use case draft. Think the protocol work belongs to IDR. ### 3. BGP Extension for Distributing CP Threshold Constraints of SR Policy (10 mins) {#3-bgp-extension-for-distributing-cp-threshold-constraints-of-sr-policy-10-mins} draft-liu-idr-bgp-sr-policy-cp-threshold-00 [Yisong Liu / Changwang Lin] No comment. ### 4. Interconnecting domains with Multiprotocol IBGP (5 mins) {#4-interconnecting-domains-with-multiprotocol-ibgp-5-mins} draft-smn-idr-inter-domain-ibgp-02 [Krzysztof Szarkowicz] Keyur: As WG chair. The draft tries to move Option A/B/C to IBGP. Option A/B/C are standardized for VPN and now belongs to BESS WG, please go to BESS WG. Without chair hat, there is a RFC in BESS about IBGP PE-CE, you need to have a section about the pros and cons of PE-CE or stocking IBGP. David Lamparter: Can you make the draft title more specific? It is about interconnecting VPNs. ### 5. Framework of Forwarding Commitment BGP (15 mins) {#5-framework-of-forwarding-commitment-bgp-15-mins} draft-wang-sidrops-fcbgp-framework-00 [Zhuotao Liu] Keyur: As WG chair, suggest to present in SIDROPS also. As WG member, you may think about decentralize this to solve different kinds of dos attack. In term of scale and convergence performance, need to consider router's CPU are different from computer CPUs. Jeff: The procedure in the draft is incomplete. Need to talk more about what goes into the path attributes. This is close to SoBGP, while replay and spoofing could be easier. Zhuotao: For the replay attack, plan to add timestamp. And think with pathlet it still can secure the entire path. Jeff: Then it means you need to rely on the immediate upstream to tell you the truth. Andrew: As operator without AD hat, have great concern about RIR based route invalidation. Randy Bush: We are in the condition now with ROV, nobody complains about serious breakage. Andrew: It does not mean it will not happen. Take a look at the number of routes being signed in Africa and ask why. ### 6. BGP Extensions for Source Address Validation Networks (10 mins) {#6-bgp-extensions-for-source-address-validation-networks-10-mins} draft-geng-idr-bgp-savnet-01 [Nan Geng] David Lamparter: Disagree with the security considerations in the draft, need to have more text there for eBGP. The presented mechanism on slide 6 is not clear to me. Nan Geng: Brief explanation of slide 6. Antoin: How to validate the prefixes which are not routed? It needs more clarification. Keyur: As WG chair, most of this work belongs to SAVNET WG. As WG member, you may need to consider more complex cases, such as when fast convergence is enabled. ### 7. BGP Community-based Attacks and Community Origin Authentication （10 mins） {#7-bgp-community-based-attacks-and-community-origin-authentication-10-mins} draft-liu-sidrops-community-authentication-00 [Jessie Hui Wang] Jeff: This needs to be reviewed by SIDROPS. The computational complexity of securing communities would be higher than BGPsec. The encoding of the new attribute proposed needs some more work. David Lamparter: Need a real example to show the attack is on the community itself. ### 8. Maintain consistency of inter-domain routing and forwarding (10 mins) {#8-maintain-consistency-of-inter-domain-routing-and-forwarding-10-mins} draft-cheng-idr-inter-domain-consistency [Shengnan Yue] Keyur: As WG chair, suggest to present in SIDROPS also. Without chair hat, suggest to run comparison against BGPsec and ASPA to see how this is better. ### 9. BGP Flowspec V2 (15 mins) {#9-bgp-flowspec-v2-15-mins} draft-hares-idr-flowspec-v2-05 draft-hares-idr-flowspec-v2-ddos-00 [Susan Hares] No comments. ### 10. BGP Flow-Spec Traffic Compress Action (5 mins) {#10-bgp-flow-spec-traffic-compress-action-5-mins} draft-shen-idr-flowspec-traffic-compress-action-01 [Ming Shen / Shuanglong Chen] Jeff Haas: This feature does not require Flowspec V2, only new BGP extended community. When the document is stable, can ask for early code allocation to advance this document soon. ### 11. BGP Flow Specification Extensions for Path Scheduling (10 mins) {#11-bgp-flow-specification-extensions-for-path-scheduling-10-mins} draft-zzd-idr-flowspec-path-scheduling-00 [Li Zhang] Jeff Haas: This is straightforward, look for more discussion on the list. ==================================================================== Second IDR Session: November 10, 2023 09:30-11:30 (CET) Friday Session I Room: Berlin 1/2 ### 0. Agenda bashing (5 mins) {#0-agenda-bashing-5-mins} [Chairs] ### 1. BGP MultiNexthop Attribute (10 mins) {#1-bgp-multinexthop-attribute-10-mins} draft-kaliraj-idr-multinexthop-attribute-10 \[Kaliraj Vairavakkalai\] Sue: Will start the adoption call on this document on the list. Satya Mohanty: The capability negotiation may not be needed. This attribute is defined as non-transitive, which is diverging from the next-hop capability. Kaliraj: Agree with the capability part, while think non-transitive is good to provide additional protection to the network, just need to get the RRs upgraded. Jeff: The non-transitivity of this attribute needs to be visited. The WG needs to review carefully how multi-nexthop attribute behave on the hop-by-hop base. Kaliraj: It nexthop is changed to self, this attribute is not readvertised. Only when nexthop is not changed, the attribute is reflected as it is. Keyur: This is more than non-transitive, at eBGP boundary this may needs to be filtered. Suggest to make it optional-transitive. There are multiple ways to do the filtering. There are multiple ways to signal label/SIDs, suggest to provide text on how to coordinate with other label/SIDs signaling approaches, e.g. prefix SIDs. Kaliraj: Yes will consider it. ### 2. Advertising SaaS Path Performance Metrics using BGP (10 mins) {#2-advertising-saas-path-performance-metrics-using-bgp-10-mins} draft-sheng-idr-advertising-saas-path-performance-00 \[Hang Shi\] Mankamana: Is BGP the right place for this information? These attributes can change dynamically. These performance metrics are share fate by many applications. Why not making it independent? Hang: The use case is SDWAN, where BGP is used as the control plane. Keyur: With chair hat on, will you present this in CATS? Hang: This is a different problem from CATS. Jeff Haas: There seems to be trend to inject dynamic information to BGP, may cause problem to BGP convergence. The WG needs to analyse each proposal. Another question is how many path attributes code points we end up burning for these. May need to look for a generic mechanism, which may overlap with the work in CATS. Louis Chan: Does the use case requires multi-vendor interop? Or suggest to make it proprietory? Andrew: Without AD hat, this seems to be related to CATS. Bringing more and more things to BGP can cause problems for operators. Keyur: Feedback to Luis, for proprietory implementations, you may want the TLVs to be registered to avoid conflicts. ### 3. BGP Extension for 5G Edge Service Metadata (5 mins) {#3-bgp-extension-for-5g-edge-service-metadata-5-mins} draft-ietf-idr-5g-edge-service-metadata-11 \[Linda Dunbar\] Jeff Haas: Would like to have more stable document to be ready for code point allocation. Ketan: Suggest to use experimental code point in the draft before it is allocated. Jeff: Suggest to not ship the code before the code point is allocated. Abdussalam Baryun: Consider to use RFC 7454 in security considerations. Loa (from chat): Isn't an upcominf wglc a counter indication for early allocation? Jeff Haas: @loa for chat as well minutes, the draft has received enough changes that early allocation and wglc are probably premature. we'll continue iterating. ### 4. Computing resource notification domain in network (15 mins) {#4-computing-resource-notification-domain-in-network-15-mins} draft-fu-idr-computing-info-notification-domain-01 \[Yuexia Fu\] Keyur: As WG chair, need to take this to CATS for further discussion. Yuexia: This draft focuses on inter-domain, CATS is on single domain for now. Jeff Haas: Suggestion to AD, CATS may needs to be recharted for inter-domain also. This draft is more abstract than the prior two presentations. Suggest to continue the discussion in CATS. Sue: BGP-LS can support distribution of a lot of information, what else is needed? Yuexia: This draft focuses on computing information notification among routers. BGP-LS is not in our consideration. John Scudder: As RTG AD, this is supposed to be in scope for CATS. It is premature to develop solutions before the cats architecture is finished. As individual participant, don't think BGP is the right protocol for this. ### 5. Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios (5 mins) {#5-extensions-to-rt-constrain-in-hierarchical-route-reflection-scenarios-5-mins} draft-ietf-idr-rtc-hierarchical-rr-03 [Jie Dong] Keyur: As WG member, existing RTC implementations do the override the attributes on RR. Jie: That rule was not for the hierarchical RR case. The Cluster\_LIST ID was not covered in the RTC RFC. Jeff Haas: There are implementations of using add-path mechanism to solve this problems, not aware of implementation of another option. Was hoping to considedr WG LC. Now it is time to restart the conversation. Krishnaswamy: Can't this be treated similar as AS loop? Could use policy to allow the loop for RTC AFI/SAFI. Jie: That may be one option, but in some cases you may want to detect the real loop. Keyur: If you do that, you definitely need to carry NO\_EXPORT to break the propagation. And confirm that for hierarchical RR case, the implementations use add\_path. ### 6. A solution to the Hierarchical Route Reflector issue in RT Constraints (10 mins) {#6-a-solution-to-the-hierarchical-route-reflector-issue-in-rt-constraints-10-mins} draft-mohanty-idr-rtc-hierarchical-rr-01 [Satya Mohanty] Keyur: Whatever you do, NO\_EXPORT is something you should consider. If there is link between lowest and highest level, need to consider how to break a loop. There is a draft on route oscilation in hierarchical RR scenarios, please take a look. Satya: The use case is for canonical networks. Think you mean NO\_Advertise community. Jeff: BGP is not a flooding protocol, we cannot get the properties of a flooding protocol. Juniper has one similar solution to overwrite some of the CLUSTER\_LIST, but there is concern about loop in some cases. No-export or No-advertise has limitations in inter-domain cases. John Scudder: The first solution of editing the CLUSTER\_LIST scares me, it is probably a bad idea, need careful analysis. Solution 2 only uses the received route for filter programming, it seems good. Satya: The second solution was the original solution. Jie: There are two potential issues with the rewrite mechanism. The first one is the loop in specific topology. The second is when the higher level RR only receives the RTC route from one client, advertising it back to the sender would create unncessary distribution tree for the VPN route. Jeff: The document Jie presented is the WG adopted work. Can you refresh it Jie? We can do further analysis based on Satya's proposal. ### 7. MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement (10 mins) {#7-mp-bgp-extension-and-the-procedures-for-ipv4ipv6-mapping-advertisement-10-mins} draft-xie-idr-mpbgp-extension-4map6-07 [Chongfeng Xie/Xing Li] Nan Geng: Thanks for the update. One suggestion: the security consideration can be refined further about the potential risks with this extension. Ketan: Had some discussion offline with the authors. There are two scenarios covered, one is connecting IPv4 host to IPv4 host via IPv6 only network, there is existing encapsulation solution in RFC 5449, think no need of translation solution for that. Another use case is connection between IPv6 host and IPv4 server. Need to read the draft further. Mapping may be needed, while not sure something is needed in BGP for this. Chongfeng: This solution is compatible with both translation and encapsultion. This has been disussed in previous meetings. Can talk about it more offline. Gyan: Is there any processing overhead on the PE for the mapping? Chongfeng: This is stateless mapping, do not need to maintain port level or user level mapping information. The scalability can be improved. Jeff: Please continue the discussion offline and look for an update version. Jeff (from chat): This is a flavor of interdomain provisioning for cgnat. I agree with ketan that the ability to carry the v4 piece is covered by rfc 5549. The encapsulation and translation is the piece that seems to need further discussion. ### 8. Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE) (5 mins) {#8-connecting-ipv4-islands-over-ipv6-core-using-ipv4-provider-edge-routers-4pe-5-mins} draft-mishra-idr-v4-islands-v6-core-4pe-06 [Gyan Mishra] No time for comments. ### 9. Generic Metric for the AIGP attribute （10 mins） {#9-generic-metric-for-the-aigp-attribute-10-mins} draft-ssangli-idr-bgp-generic-metric-aigp-05 [Srihari Sangli] No time for comments. ### 10. BGP BFD Strict-Mode (10 mins) {#10-bgp-bfd-strict-mode-10-mins} draft-ietf-idr-bgp-bfd-strict-mode-11 [Albert Fu] Tony P: 2 recommendations. 1: is there any deviation between OSPF and BGP behavior? 2. There is another unclear behavior, which in deployment, was causing havoc. You can flip on the remote side, the BFD up and down. This document may be a good place to document that. Jeff: The BFD admin downstate, which you're talking about, is explicitly called out of this draft. Keyur: Keeper lives were used from what I recall, for a really good, buffering point against Kernels that could not generate Fin when a process in the user plane crashed. Because you delay the keepalive till BFD is up, but the user plan crashes and the kernel cannot generate a FIN, how to solve that? That would delay 180 seconds. Jeff: There is a deadband timer for exactly that reason. We will not linger in there forever.