### 0. Agenda bashing and Chairs' Slides (5 mins) {#0-agenda-bashing-and-chairs-slides-5-mins} [Chairs] Sue: Drafts in adoption poll needs further feedback, please provide your opinion this week. Keyur: We will continue the discussion of some topics on the upcoming interim. ### 1. BGP Color-Aware Routing (CAR) (10 mins) {#1-bgp-color-aware-routing-car-10-mins} draft-ietf-idr-bgp-car-01 [Dhananjaya Rao] No comments. ### 2. BGP Classful Transport Planes (10 mins) {#2-bgp-classful-transport-planes-10-mins} draft-ietf-idr-bgp-ct-01 [Natarajan Venkataraman] Dhananjaya Rao: IOS-XR does not support BGP-CT. Probably not refer to it in the CT interop slides. Jeff： Please continue the discussion on the list. Sue: I'm sending calls to the WG to solve the open issues on CAR and CT drafts. （from chat） Ketan Talaulikar: @Natrajan Venkataraman, a suggestion. Saying there was an interop of your CT implementation with Cisco is a misrepresentation. You are right to call it an "experiment" in sending CT faked as SAFI 128. Would you please care to update/clarify on this to the list and wherever this is posted? It is interesting that you choose Cisco implementation for this "experiment" instead of some open source implementation. Could you share your reasons behind such a choice? Kaliraj Vairavakkalai: @Ketan Talaulikar, It is indeed mentioned as an "interop experiment" in the ietf "hackathon" where it was presented. https://github.com/IETF-Hackathon/ietf115-project-presentations/blob/main/ietf-115-bgp-ct-junos-ios-xr-hackathon.pptx pls go thru the link, and demo video - where we clearly mention this is an 'interesting experiment'. This experiment shows how the procedures of BGP-CT can be implemented easily on another implemention, one step at a time. Kaliraj Vairavakkalai: partial interop (and even End-to-end intent based forwarding) can be achieved even with a device not supporting CT as one of the BNs in the forwarding path. Ofcourse this hackathon experiemnt is done with some hacks (like using SAFI-128). That just shows the power of re-using RFC-8277 and 4364 procedures! ### 3. Advertisement of Segment Routing Policies/Traffic Engineering Paths using BGP Link-State (10 mins) {#3-advertisement-of-segment-routing-policiestraffic-engineering-paths-using-bgp-link-state-10-mins} draft-ietf-idr-bgp-ls-sr-policy-00 draft-ietf-idr-bgp-ls-te-path-00 [Ketan Talaulikar] No comments. ### 4. BGP YANG Model (10 mins) {#4-bgp-yang-model-10-mins} draft-ietf-idr-bgp-model-16 [Mahesh Jethanandani & Jeff Haas] Keyur: Jie will be the shepherd to provide the shepherding report. ### 5. Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP (5 mins) {#5-advertising-in-situ-flow-information-telemetry-ifit-capabilities-in-bgp-5-mins} draft-ietf-idr-bgp-ifit-capabilities-02 [Bruno Decraene] Sue: This document refers to draft-ietf-idr-sr-policy-ifit is waiting for implementations, would be helpful if you could provide implementations information, so that that document could go to WG LC. ### 6. BGP SR Policy Extensions for Template (10 mins) {#6-bgp-sr-policy-extensions-for-template-10-mins} draft-zhang-idr-sr-policy-template-02 [Ka Zhang] Jeff Haas: Note that Template number is local and not coordinated. If it is used for something out of SR Policy, there may be globally-issues to be further considered. (from chat) Shraddha Hegde: Sorry for the microphone issue. My question was can you use template name instead of template ID? Ka Zhang: @Shraddha Hegde, I think template name may be ok, but template id is enough, and it is shorter and simple to use in this case. Shraddha Hegde: @KaZhang names are more operationally friendly than the IDs. Also allowing a regular expression for names instead of exact names can be helpful Aijun Wang: For template ID draft, because there are many parameters in the SR policy, so there will be many combination of the possible policy template. The controller and the headend need also synchronize the contents of so many policy templates? Ka Zhang: There won't be too many templates on the headend, different SR Policies can share the same template. And in application, we may use one template for all the primary paths of all policies and another template for backup path. And all configurations can be synchronized by netconf/yang. Jeff Haas: One consideration for names vs. ids is that text strings in the names introduce internationalization considerations. That might make some forms of vendor neutral behavior challenging, even if it's a preferable operational model. ### 7. BGP SR Policy Extensions for Segment List Identifier (10 mins) {#7-bgp-sr-policy-extensions-for-segment-list-identifier--10-mins} draft-lin-idr-sr-policy-seglist-id-02 [Mengxiao Chen] Wang Aijun: Difference between the path-id and New defined Segment-List Identifier? Answer by Mengxiao: The purpose are different. Path ID is similar to the Path ID in PCEP and YANG. Path segment is mainly for path measurement and correlation. One coauthor is also the author of the path segment draft, discussed this issue and think there is no contrdiction between 2 drafts. (from chat) Aijun: There is the Path ID (segment) defined for SR policy, so what's the reason/scenario to define the segment list identifier then? Cheng Li: Path segment can be used in control plane I think. Btw, I think we see some drafts defining some similar terms... Liu Yao: @mengxiao we defined the sid list id in draft-lp-idr-sr-path-protection you may want to check that. Changwang Lin: The path-seglist id is used to identify the forwarding plane, not the management plane. In the case that both PCE and YANG are identified by ID and name, it is suggested that the seglist should also have the identification of the management plane. The application scenario is statistics reporting and configuration delivery Aijun: It's better to add some descriptions that why the Path ID can't be used in the the mentioned scenario. Jeffrey Haas: The seglist id chat is looking interesting. May the chairs ask that the conversation be summarized and continued on the idr mail list? Ka Zhang: There is Segment List that is configured in the headnode, and Segment List that is ceated by controller, no matter which method, there may need a segment ID, then how to process the conflict? ### 8. Advertising SID Algorithm Information in BGP (10 mins) {#8-advertising-sid-algorithm-information-in-bgp-10-mins} draft-peng-idr-segment-routing-te-policy-attr-04 [Yao Liu] No question or comment. ### 9. Loop Prevention for Route Import Between Protocols (10 mins) {#9-loop-prevention-for-route-import-between-protocols--10-mins} draft-li-idr-inter-protocol-anti-loop-00 [Wenyan Li] (from chat) Randy Bush: it's a little unusual to import from bgp into igp. Jeff Haas: I suspect you have good wisdom to share on this, Randy. Randy Bush: no wisdom, just many bad events over decades, remember 7007 incident? Ketan Talaulikar: and those events still happen :-( Keyur Patel: hmm redistributing/importing bgp routes in igp and then back into bgp. Fun!! Haibo Wang: The dual-egress scenario occurs from time to time. Fang Gao: Many IGP instance may bind to the same VPN ID. Should add some description about this scenario. David Lamparter: This may be better fit in RTGWG. Jeff Haas: Have you presented this in LSR WG? Suggest to do that. Please take a look at RFC 1403/1364 (and 1925(2.11)) on a related idea. ### 10. Generic Metric for the AIGP attribute (10 mins) {#10-generic-metric-for-the-aigp-attribute--10-mins} draft-ssangli-idr-bgp-generic-metric-aigp-04 [Srihari Sangli] Linda Dunbar: If one of the domains does not run IGP （for example overlay）, what type of metrics to use for propogation？ New ones or still the one in RFC 7311 Srihari: For example for BGP-LU based network, there will still be a metric type used in the underlay. Linda: Can I define other metric types? Srihari: Yes it is definable. David Lampater: Evern the metric types in different domains are the same, they may have different decisions in how to implement the metric, then the metric may not be interchangable. Does it require some agreement on the meaning of the metric? Srihari: To have an end-to-end intent path across domains, the translation or normalization of metrics is based on domain or operator's policy. Louis Chan: Suggest to add unusable type of matrics. ### 11. MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement (10 mins) {#11-mp-bgp-extension-and-the-procedures-for-ipv4ipv6-mapping-advertisement--10-mins} draft-xie-idr-mpbgp-extension-4map6-00 [Xing Li] Guozhen Dong: As coauthor of this draft, welcome comments. Jeff Haas: The new path attribute has not only the information of addrss mapping, but also the bgp path attributes of the original BGP message. RFC 6368 provides a feature of carrying tunneled BGP attributes. Suggest to check whether that mechanism can be used for the tunneled attributes. Jeff Haas: https://www.rfc-editor.org/rfc/rfc6368.html - this is the RFC for tunneling path attributes mentioned during the second to last presentation of draft-xie-idr-mpbgp-extension-4map6. ### 12. Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE) (5 mins) {#12-connecting-ipv4-islands-over-ipv6-core-using-ipv4-provider-edge-routers-4pe--5-mins} draft-mishra-idr-v4-islands-v6-core-4pe-03 [Gyan Mishra] Keyur: This is IDR WG (draft asked for WG adoption in BESS). Stephane: These are building blocks which are already defined. How about have a draft more informational on the architecture? For data plane mechanisms in this draft, not sure IDR is the right place. Ben Maddison: We run 6PE in the network. Having such information documented is helpful.