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

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 gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*

On Wed, Jan 10, 2024 at 7:21 PM Les Ginsberg (ginsberg) <ginsberg=
40cisco.com@dmarc.ietf.org> 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 <lsr-bounces@ietf.org> *On Behalf Of * Joel Halpern
> *Sent:* Wednesday, January 10, 2024 3:22 PM
> *To:* Acee Lindem <acee.ietf@gmail.com>; teas@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.ietf@gmail.com> <acee.ietf@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> <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
>
> Teas@ietf.org
>
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>