(NOTE: I am replying to Joel’s post rather than the original last call email because I share some of Joel’s concerns – though my opinion on the merits of the draft is very different. Also, I want to be sure the TEAS WG gets to see this email.)
I oppose Last Call for draft-ietf-lsr-isis-sr-vtn-mt. It is certainly true, as Joel points out, that this draft references many drafts which are not yet RFCs – and in some cases are not even WG documents. Therefore, it is definitely premature to last call this draft. I also want to point out that the direction TEAS WG has moved to recommends that routing protocols NOT be used as a means of supporting NRP. https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl states: “…it is desirable for NRPs to have no more than small impact (zero being preferred) on the IGP information that is propagated today, and to not required additional SPF computations beyond those that are already required.” https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl states: “The routing protocols (IGP or BGP) do not need to be involved in any of these points, and it is important to isolate them from these aspects in order that there is no impact on scaling or stability.” Another draft which is referenced is https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ - which is not a WG document and – based on the recommendations in draft-ietf-teas-nrp-scalability – I would argue that the IGPs should NOT be extended as proposed in this draft. So if a WG adoption call were to initiated for draft-dong-lsr-sr-enhanced-vpn, I would oppose it. This then puts draft-ietf-lsr-isis-sr-vtn-mt in the position of publishing information about a solution which the IETF is discouraging. I do not know why the IETF would want to do this. If, despite all of the above, at some point it is judged not premature to publish this draft, I think the draft should at least include statements indicating that this approach is not a recommended deployment solution. Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of Joel Halpern Sent: Wednesday, January 10, 2024 3:22 PM To: Acee Lindem <acee.i...@gmail.com>; t...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 Given that the documents that provide the basic definitions needed for this are still active Internet Drafts, it seems premature to last call this document. As a lesser matter, it seems odd that draft-ietf-teas-ietf-network-slices, which defines the terms needed to understand this draft, is an Informative reference. Yours, Joel PS: I considered not writing this email, as it seems quite reasonable to use MT to support what I expect NRPs to be. So in principle I think the document is a good idea. On 1/10/2024 6:12 PM, Acee Lindem wrote: Note that we are last calling this informational document relating to IS-IS deployment of NRPs using multi-topology. If you have comments, please send them to the LSR list. Thanks, Acee Begin forwarded message: From: Acee Lindem <acee.i...@gmail.com><mailto:acee.i...@gmail.com> Subject: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 Date: January 8, 2024 at 5:50:21 PM EST To: Lsr <lsr@ietf.org><mailto:lsr@ietf.org> This begins a two week LSR Working Group last call for the “Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)”. Please express your support or objection prior to Tuesday, January 23rd, 2024. Thanks, Acee _______________________________________________ Teas mailing list t...@ietf.org<mailto:t...@ietf.org> https://www.ietf.org/mailman/listinfo/teas
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
