Hi Les The TEAS network slicing draft is the architectural framework draft for IETF Network slicing.
What is meant by “IETF Network Slicing” is that any IETF technology such as IGP MT or Flex Algo can be used to build a IETF Network slice Network Resource partition (NRP). https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-25 Jie & myself are Co-authors of this draft and maybe we can both try to explain what this is saying and why it does not preclude use of ISIS MT or even Flex Algo for IETF network slicing. https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl “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. Furthermore, the complexity of SPF in the control plan is unaffected by this.” So this section 3 is talking about NRP scalability design principles which are listed and is talking about NRP scalability which is data plane scalability for the underlying underlay resource NRP. So the NRP is independent of the routing control plane which MT is common control plane and separate data plane which allows for more scalability of network slicing as compared to MI Multi Instance which has separation of control plane and data plane. So what the text is talking about is the data plane aspects of the control plane function is what is related to NRP and not the routing control plane itself. Kind Regards <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347* On Wed, Jan 10, 2024 at 7:21 PM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > (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 <[email protected]> *On Behalf Of * Joel Halpern > *Sent:* Wednesday, January 10, 2024 3:22 PM > *To:* Acee Lindem <[email protected]>; [email protected]; [email protected] > *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 <[email protected]> <[email protected]> > > *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 <[email protected]> <[email protected]> > > > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/teas >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
