Subject: Re: [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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 25 Mar 2021 18:20:28 +0000

Speaking as WG chair:

There has been considerable support for this document. However, there has also been objections to the document. The objections are either that there is nothing to standardize given that all pieces exist and that the MT isn’t a viable option for VTNs since it isn’t scalable.

Since most of the draft’s support is from “friends and family”, I’d like to know of the WG members who supported it, would you really want to market it as a VTN solution? Those of you who operate networks, would you actually consider deploying it?

In any case, section 5 needs to be expanded on the scalability and where using MTs to support VTNs would make sense and where it wouldn’t.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of "Acee Lindem (acee)" <acee=[email-masked]>
Date: Tuesday, March 2, 2021 at 6:28 PM
To: "[email-masked]" <[email-masked]>
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

---

From: "Chongfeng Xie" <[email-masked]>
Date: Fri, 26 Mar 2021 14:14:12 +0800

Hi，Acee，

Regarding to the issues put forward in your mail, I'd like to provide some comments as below,

Q1：I’d like to know of the WG members who supported it, would you really want to market it as a VTN solution? 

[CF]：VTN is defined in draft-ietf-teas-enhanced-vpn, and also used in other documents. It is a technical term to refer to virtual underlay networks with specific topology and resource attributes. This document provides an MT based mechanism to build VTNs. If for marketing, perhaps it would be better called "network slicing":-)

Q2：Those of you who operate networks, would you actually consider deploying it? 

[CF]：As an operator we will consider the scenarios and the requirements to pick the most suitable solution, IMO this is a good candidate for scenarios where the required number of VTN is not very large, and as it requires no new encodings, it could be ready for shipment soon. we plans to use this approach in some of our network deployment.

Q3：In any case, section 5 needs to be expanded on the scalability and where using MTs to support VTNs would make sense and where it wouldn’t.

[CF]：OK. The current section 5 already has some text to cover this, and it can be expanded further to clarify. 

Best regards
Chongfeng

发件人： Acee Lindem \(acee\)
发送时间： 2021-03-26 02:20
收件人： [email-masked]
主题： Re: [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
Speaking as WG chair:

 
 
Thanks,
Acee

 
 
Thanks,
Acee

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 26 Mar 2021 14:38:52 +0000

Hi Acee,

I agree with what Chongfeng said about VTN. It refers to a virtual underlay network with specific topology and resource attributes, and the topology of VTNs can be specified using multi-topology. It is important to understand the difference between a VTN and a logical network topology.

As for the deployment choice and scalability, draft-dong-teas-enhanced-vpn-vtn-scalability gives some detailed analysis. In summary, it says in different network scenarios and phases, the required number of VTNs could be different, thus several options may be provided to meet different requirements, with different cost and time to market.

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of Chongfeng Xie
Sent: Friday, March 26, 2021 2:14 PM
To: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]
Subject: Re: [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

Hi，Acee，

Best regards
Chongfeng

发件人： Acee Lindem \(acee\)<mailto:acee=[email-masked]>
发送时间： 2021-03-26 02:20
收件人： [email-masked]<mailto:[email-masked]>
主题： Re: [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
Speaking as WG chair:

Thanks,
Acee

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of "Acee Lindem (acee)" <acee=[email-masked]<mailto:acee=[email-masked]>>
Date: Tuesday, March 2, 2021 at 6:28 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 26 Mar 2021 15:30:30 +0000

Hi Jie, Chongfeng,

I’ve read draft-ietf-teas-enhanced-vpn and I agree that the combination of MT and SR could be used to meet a given SLO. Given that I work with products and customers, I also know there can be a significant time lag for qualification and deployment of a software version. In lieu of resource-aware segments, you could even use an existing technology like VLANs with appropriate QoS guarantees. Hence, I can see the value of using existing technologies. Please go ahead and republish draft-xie-lsr-sr-vtn-mt as draft-ietf-lsr-sr-vtn-mt-00.txt.

Section 5 can be expanded in subsequent revisions with appropriate references to TEAS documents.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Jie Dong <[email-masked]>
Date: Friday, March 26, 2021 at 10:39 AM
To: Chongfeng Xie <[email-masked]>, "Acee Lindem (acee)" <acee=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [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

Hi Acee,

Best regards,
Jie

Hi，Acee，

Best regards
Chongfeng

Thanks,
Acee

Thanks,
Acee

---

From: "Chongfeng Xie" <[email-masked]>
Date: Sat, 27 Mar 2021 11:15:11 +0800

Hi, Acee,

Thanks for your understanding about the deployment considerations and the value of reusing existing technologies when possible.

We have submitted the draft as draft-ietf-lsr-isis-sr-vtn-mt-00 with only the change in the title and date.  And we will expand section 5 and add references to relevant TEAS documents in next revision.

Chongfeng 

发件人： Acee Lindem (acee)
发送时间： 2021-03-26 23:30
收件人： Dongjie (Jimmy); Chongfeng Xie; Acee Lindem (acee); [email-masked]
主题： Re: [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
Hi Jie, Chongfeng,

 
Thanks,
Acee

 
Hi Acee, 

 
Best regards,
Jie

Hi，Acee，

 

 

Best regards
Chongfeng

 

Thanks,
Acee

 
 
Thanks,
Acee

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 26 Mar 2021 23:46:33 -0400

Hi Acee

As an operator, I  support adoption of the draft and would like to provide
answers to your questions.

I would like to start by stating that as this is an informational document,
 as nothing new is proposed other then the recommendation to use MT for VTN
provisioning as a component of the 5G network slicing solutions, the
benefit is that this concept can be used immediately as other NS features
are still being developed.

The solution for network slicing resource isolation is multi faceted
involves Enhanced VPN+ provisioning, resource SIDs for provisioning
underlay resources, SR-TE Per VPN or flow path steering to meet NS SLO
requirements, as well as a method to isolate IGP resources for a VTN.

MT is a component of the entire NS solution so there is really nothing to
market as it’s not the only component used to provision the VTN.

As their is a need for providing a viable means of provisioning IGP
underlay resources VTN network slice and the ability to provide forwarding
plane isolation via topological RIB without consuming tremendous control
plane resources per instance as with MI.

This draft does fill the gap of a means of forwarding plane isolation on
shared infrastructure even though it does have scalability considerations.

As other ideas of IGP forwarding plane isolation come about we are open to
other solutions as well.

As their are scalability concerns in section 5 that should be expanded,
when MT should be used to support VTN and when should not. Agreed.

I would deploy in a limited fashion taking into account the scalability
concerns.

Enhanced VPN  VPN+ scalability issue are described in detail in this draft
below.  Lots of variables related to how many slices based on services
which will eventually scale up but I think MT may suffice well in the
beginning stages.

https://tools.ietf.org/html/draft-dong-teas-enhanced-vpn-vtn-scalability-01

There are many drafts and solutions in the works across many different WGs
that are working on development of solution as to how network slicing and
SLO can be realized  by operators for 5G services.

Of these drafts below there are a number of Enhanced VPN Framework VPN+
 related drafts that are critical to the provisioning of various components
of network slicing.

https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-07

https://datatracker.ietf.org/doc/draft-dong-teas-enhanced-vpn-vtn-scalability/

https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn-06

https://tools.ietf.org/html/draft-ietf-spring-resource-aware-segments-02

Kind Regards

Gyan

On Thu, Mar 25, 2021 at 2:21 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> Speaking as WG chair:
>
>
>
> There has been considerable support for this document. However, there has
> also been objections to the document. The objections are either that there
> is nothing to standardize given that all pieces exist and that the MT isn’t
> a viable option for VTNs since it isn’t scalable.
>
>
>
> Since most of the draft’s support is from “friends and family”, I’d like
> to know of the WG members who supported it, would you really want to market
> it as a VTN solution? Those of you who operate networks, would you actually
> consider deploying it?
>
>
>
> In any case, section 5 needs to be expanded on the scalability and where
> using MTs to support VTNs would make sense and where it wouldn’t.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> *From: *Lsr <[email-masked]> on behalf of "Acee Lindem (acee)"
> <acee=[email-masked]>
>
>
> *Date: *Tuesday, March 2, 2021 at 6:28 PM
> *To: *"[email-masked]" <[email-masked]>
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 27 Mar 2021 11:58:43 +0100

Having had a long history with RFC5120 (and with the concept before IETF
was even afoot really) and their deployment in its time I cannot resist
finally chiming in a bit ;-)

Well, first, it seems there is agreement that the drafts state fairly
straightforward things but as informational probably nothing wrong with
having it captured and I'd agree with that.

Second, as to realities of MT in such architecture some musings based on
experience;

a) MT was best used when faced with the problem of "alien" topologies, e.g.
introduction of v6 into a network when a lot of boxes/links couldn't do v6
yet (there was a good set of discussions in its time around MT strictly per
node or per link being best approach and for many reasons link based
architecture was chosen) or need for drastically different forwarding
decision deviating from simple SPF (RPF problems).
b) using underlay to "slice" is an expensive proposition of course. The
costliest resources in large networks is really ASIC space in the core and
if the MTs are properly separated, that will take ASIC state. in simplest
form e.g. topology being mirrored into per DSCP bits lookup or something
like this. Nothing wrong with that if one has the $ (or CNY ;-) to foot the
bill for that and slicing underlay gives of course the best quality
assurance compared to overlay approaches AFAIS.
c) MT (well, at least in ISIS ;-) has been built to scale ;-), originally 8
bits were suggested and then I asked others "what's the biggest you can
imagine" to which answer was 1024 MT which needed of course a
multiplication by 4 to make sure stuff will still work in 25 years where we
are today ;-)
d) SPF is to an extent only limitation of MT. the tree itself can be
computed very efficiently today (and there are techniques like incremental
SPF which can drastically lessen the cost of a computation and one can go
to the extent of throwing the SPF computations to a beefy side-box even and
most extreme, ASIC [unbelievale or not, this has been done for trees up to
a certain space ;-)]), the limiting factor is more prefix attachement and
prefix download on massive changes (but there is no reason any LFA would
not work with MT BTW, even to the point where an MT can protect another MT
or MT use all links when protecting disregarding MT itself, I'm not aware
of implementations but the theoretical thinking/whiteboarding has been done
here long ago albeit one has to know a fair bit of math [metric sets
largely]) to not blow up on a mine ;-)
e) main limiting factor of MT deployment was IME operational discontinuity
of topologies that happens much more often than one thinks it does. That's
why MT negotiates on every link the topologies so continuity is clearly
provisioned and can be tracked. Tools to visualize, manage all that are
much harder to operate than one would think, I assume because humans
generally have poor intuition concerning topological spaces under different
metrics. Just look how confused we are when we try to strike something in a
glass of water ;-)
b) yes, TE can be advertised in topologies but here is bunch of things that
fall out of it
i) oversubscription is a fact of life in such an architecture and
discussions about this will start quickly
ii) except in case of massive under-subscription (but even then) the
correct scheduling of MTs will become an issue and possibly pre-emption in
HW when the timing becomes tight enough. DetNet is an interesting romping
ground of ideas for that right now
iii) Even with under-subscription interesting problems crop up like parties
that don't need much resources under normal circumstances but in case of
emergencies are willing to pay any amount to allocate resources their need
and pre-empt any other traffic.

--- tony

On Sat, Mar 27, 2021 at 4:47 AM Gyan Mishra <[email-masked]> wrote:

> I would like to start by stating that as this is an informational
> document,  as nothing new is proposed other then the recommendation to use
> MT for VTN provisioning as a component of the 5G network slicing solutions,
> the benefit is that this concept can be used immediately as other NS
> features are still being developed.
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Mar 2021 01:07:08 -0400

Hi  Tony

One of the main concerns for operators as you have elaborated is the real
world operators experiences aside from what you mentioned common use case
of IPv6 as the first non zero MT, and vendor feedback on scalability and
resource issues using many MT IPv4 and IPv6 separate instance and how well
it scales or not and operational impacts with troubleshooting multiple RIB
instances with common LSDB with discrete SPF instance per topology and
control plane scale issues as the number of instances grows.

Also complexity related to NOC troubleshooting and MTTR when you have let’s
say 10 to 100 network slices for example, how complex do things get and is
it manageable or not.

As you have 12 bits of MT ID, 4096 instances is quite a lot.  Could you
really ever scale to 4096 MT instances, probably not.

What is a real world practical hard limit from your experiences of number
of prefixes per MT RIB and maximum number of MT RIB instances.

Also a cross comparison of MI non zero instance IID/ITID comparing 100 ITID
sub topologies to 100 MT RIB topologies and which scales better.

Much appreciated your MT & MI experiences  and real world feedback.

Kind Regards

Gyan

On Sat, Mar 27, 2021 at 6:59 AM Tony Przygienda <[email-masked]> wrote:

> a) MT was best used when faced with the problem of "alien" topologies,
> e.g. introduction of v6 into a network when a lot of boxes/links couldn't
> do v6 yet (there was a good set of discussions in its time around MT
> strictly per node or per link being best approach and for many reasons link
> based architecture was chosen) or need for drastically different forwarding
> c) MT (well, at least in ISIS ;-) has been built to scale ;-), originally
> 8 bits were suggested and then I asked others "what's the biggest you can
> b) yes, TE can be advertised in topologies but here is bunch of things
> that fall out of it
> iii) Even with under-subscription interesting problems crop up like
> parties that don't need much resources under normal circumstances but in
> case of emergencies are willing to pay any amount to allocate resources
> their need and pre-empt any other traffic.
>
> --- tony
>
>
>
>
>
>
>> As an operator, I  support adoption of the draft and would like to
>> provide answers to your questions.
>>
>> As other ideas of IGP forwarding plane isolation come about we are open
>> to other solutions as well.
>>
>> Enhanced VPN  VPN+ scalability issue are described in detail in this
>> draft below.  Lots of variables related to how many slices based on
>> services which will eventually scale up but I think MT may suffice well in
>> the beginning stages.
>>
>>
>> There are many drafts and solutions in the works across many different
>> WGs that are working on development of solution as to how network slicing
>> and SLO can be realized  by operators for 5G services.
>>
>>> There has been considerable support for this document. However, there
>>> has also been objections to the document. The objections are either that
>>> there is nothing to standardize given that all pieces exist and that the MT
>>> isn’t a viable option for VTNs since it isn’t scalable.
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 29 Mar 2021 08:59:13 +0200

I never saw more than 3-4 MT "slices" deployed, Gyan. Operational
complexity basically. Usual Ks or 10Ks prefixes in main instance and not
more than maybe 1K in others.

So practically speaking I would worry about operational procedures of such
a deployment first (OAM, connected topologies, provisioning [since both
sides of MT need matching configuration, as I said, on purpose from
experience operating such things then], validation). A controller makes a
lot sense here, not even necessarily as provisioning tool first but
visualization, OAM, operational analytics. Think basically that you're
getting yourself from "normal IGP" experience into something that will
resemble L3VPN more and you know the problems there pretty well ;-)

Also, planning of fast reroute strategy is good, what links/mix of
topologies you want to protect others and will you have enough capacity
once FRR kicks in. There are commercial tools available to "simulate" that
kind of stuff and AFAIR decent amount of theoretical work done on necessary
algorithms (and since the solution space starts to become real large real
fast something like an A/B test with ML could deliver good results [weighed
decision trees or something like this]. The difficult thing being of course
to establish a cost function as in "is one topology down due to overload &
e'one protected without loss better than e'one losing some packets better
or worse").

--- tony

On Mon, Mar 29, 2021 at 7:07 AM Gyan Mishra <[email-masked]> wrote:

> Also complexity related to NOC troubleshooting and MTTR when you have
> let’s say 10 to 100 network slices for example, how complex do things get
> and is it manageable or not.
>
> Also a cross comparison of MI non zero instance IID/ITID comparing 100
> ITID sub topologies to 100 MT RIB topologies and which scales better.
>
>> e) main limiting factor of MT deployment was IME operational
>> discontinuity of topologies that happens much more often than one thinks it
>> does. That's why MT negotiates on every link the topologies so continuity
>> is clearly provisioned and can be tracked. Tools to visualize, manage all
>> that are much harder to operate than one would think, I assume because
>> humans generally have poor intuition concerning topological spaces under
>> different metrics. Just look how confused we are when we try to strike
>> something in a glass of water ;-)
>>> MT is a component of the entire NS solution so there is really nothing
>>> to market as it’s not the only component used to provision the VTN.
>>>
>>>> Since most of the draft’s support is from “friends and family”, I’d
>>>> like to know of the WG members who supported it, would you really want to
>>>> market it as a VTN solution? Those of you who operate networks, would you
>>>> actually consider deploying it?
>>>>
>>>>
>>>>
>>>> In any case, section 5 needs to be expanded on the scalability and
>>>> where using MTs to support VTNs would make sense and where it wouldn’t.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>>
>>>>
>>>>
>>>>