I oppose WG adoption for this draft. I note that the authors – following significant comments received on V0 - have removed much of the material that was considered confusing and/or inappropriate – notably discussion of L2 bundle link members. I also note the draft has moved from Standards track to Informational track.
Let’s consider what content remains (ignoring boilerplate sections): Section 2 notes that MT TLVs (RFC 5120) can support: o Topology specific SR-MPLS SIDs (defined in RFC 8667) o Topology specific SRv6 Locators and SIDs (defined in draft-ietf-lsr-isis-srv6-extensions) Section 3 notes that MT TLVs can also support link attribute advertisements (defined in RFC 5305 and RFC 8570) Also note that the IANA registries: https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 and https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237 also clearly document what is discussed in Sections 2 and 3. Section 4 notes that topology specific forwarding entries can be installed in the forwarding plane based on topology specific routing calculations – something which was discussed in RFC 5120. Section 5 notes that two different MTIDs could operate on the same physical topology - something clearly discussed in RFC 5120. All of this adds nothing new to our understanding of the protocol. The only “new” content is the statement that VTNs could map to MTIDs. But the substance of VTN and how it might be used is better discussed in a number of other drafts including: draft-ietf-spring-sr-for-enhanced-vpn draft-ietf-teas-enhanced-vpn draft-dong-lsr-sr-enhanced-vpn The last draft is most notable because it proposes new IGP protocol encodings in support of VTN. Whether the encodings in that draft are accepted as currently defined or evolve to something different – it would be the authoritative draft on VTN IGP extensions. The end result is that there is no meaningful content in draft-xie-lsr-isis-sr-vtn-mt. What it states is either already stated in existing RFCs or will be stated authoritatively in whatever draft-dong-lsr-sr-enhanced-vpn evolves to (if indeed this work on VTNs is adopted by the WG). Let’s please not waste WG time on this draft. Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee) Sent: Tuesday, March 02, 2021 3:28 PM To: lsr@ietf.org Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03 This information draft describes how MT could be used for VTN segmentation. The authors have asked for WG adoption. This begins a three week LSR Working Group Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next week. Please register your support or objection on this list prior to the end of the adoption poll on 3/24/2020. Thanks, Acee
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
