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

[Gyan Mishra]

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) >>> 40cisco@dmarc.ietf.org> 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  on behalf of "Acee Lindem (acee)"
>>>>> 
>>>>>
>>>>>
>>>>> *Date: *Tuesday, March 2, 2021 at 6: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
>>>>>
>>>> --
>>>>
>>>> <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions A**rchitect *
>>>>
>>>> *Email gyan.s.mis...@verizon.com *
>>>>
>>>>
>>>>
>>>> *M 301 502-1347*
>>>>
>>>> ___
>>>> Lsr mailing list
>>>> Lsr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>>
>>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mis...@verizon.com *
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Hi Chongfeng,

From: Chongfeng Xie 
Date: Tuesday, March 30, 2021 at 3:26 AM
To: Acee Lindem , Jie Dong , 
"lsr@ietf.org" 
Subject: Re: 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,
Thank you for your comments. I agree with your consideration about using mature 
and deployed control plane technologies, and this document does not introduce 
any new IS-IS encodings. While the resource-aware segments has the same format 
as the legacy SR segments, the difference is in the semantics. Thus the same 
control plane mechanism in this draft could be used with either the legacy SR 
SIDs or the resource-aware SIDs. Using it with legacy SR SIDs could also help 
to compute SR paths in a VTN taking its topology and resources as constraints. 
When used with the resource-aware SIDs, it can further provide VTNs with 
guaranteed resources. We could add some text about this to the draft if you 
think this is helpful.

Yes – that would be useful.
Thanks,
Acee

Best regards
Chongfeng

发件人： Acee Lindem \(acee\)<mailto:acee=40cisco@dmarc.ietf.org>
发送时间： 2021-03-30 03:32
收件人： Chongfeng Xie<mailto:chongfeng@foxmail.com>; Dongjie 
(Jimmy)<mailto:jie.d...@huawei.com>; Acee Lindem 
(acee)<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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 Chongfeng,

Given that the main argument for using MT to realize VTNs in the control plane 
is that it is a mature and deployed technology, requiring resource-aware 
segments, a new and evolving technology, defeats the purpose.

Thanks,
Acee

From: Chongfeng Xie 
Date: Monday, March 29, 2021 at 8:58 AM
To: Acee Lindem , "chongfeng.xie" , 
Jie Dong , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: Re: 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,
Thanks for your comments. This document can be used with resource-aware 
segments to provide VTNs with guaranteed resources, while I agree it may also 
be used with legacy SR technologies. This could be clarified in next version.

Regards
Chongfeng

发件人： Acee Lindem (acee)<mailto:a...@cisco.com>
发送时间： 2021-03-27 18:31
收件人： Chongfeng Xie<mailto:chongfeng@foxmail.com>; Dongjie 
(Jimmy)<mailto:jie.d...@huawei.com>; Acee Lindem 
(acee)<mailto:acee=40cisco....@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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 member:

Hi Chongfeng,

Another thing, if one is trying to support a VTN with legacy technologies, it 
would be good to decouple it from the SR resource-aware segments.

Thanks,
Acee

From: Chongfeng Xie 
Date: Friday, March 26, 2021 at 11:15 PM
To: Acee Lindem , Jie Dong , 
"chongfeng.xie" , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: Re: 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,

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)<mailto:a...@cisco.com>
发送时间： 2021-03-26 23:30
收件人： Dongjie (Jimmy)<mailto:jie.d...@huawei.com>; Chongfeng 
Xie<mailto:chongfeng@foxmail.com>; Acee Lindem 
(acee)<mailto:acee=40cisco....@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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,

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  on behalf of Jie Dong 
Date: Friday, March 26, 2021 at 10:39 AM

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

[Chongfeng Xie]

Hi, Acee,
Thank you for your comments. I agree with your consideration about using mature 
and deployed control plane technologies, and this document does not introduce 
any new IS-IS encodings. While the resource-aware segments has the same format 
as the legacy SR segments, the difference is in the semantics. Thus the same 
control plane mechanism in this draft could be used with either the legacy SR 
SIDs or the resource-aware SIDs. Using it with legacy SR SIDs could also help 
to compute SR paths in a VTN taking its topology and resources as constraints. 
When used with the resource-aware SIDs, it can further provide VTNs with 
guaranteed resources. We could add some text about this to the draft if you 
think this is helpful.

Best regards
Chongfeng
 
发件人： Acee Lindem \(acee\)
发送时间： 2021-03-30 03:32
收件人： Chongfeng Xie; Dongjie (Jimmy); Acee Lindem (acee); lsr@ietf.org
主题： 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 Chongfeng,
 
Given that the main argument for using MT to realize VTNs in the control plane 
is that it is a mature and deployed technology, requiring resource-aware 
segments, a new and evolving technology, defeats the purpose. 
 
Thanks,
Acee
 
From: Chongfeng Xie 
Date: Monday, March 29, 2021 at 8:58 AM
To: Acee Lindem , "chongfeng.xie" , 
Jie Dong , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: Re: 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,
Thanks for your comments. This document can be used with resource-aware 
segments to provide VTNs with guaranteed resources, while I agree it may also 
be used with legacy SR technologies. This could be clarified in next version.
 
Regards
Chongfeng
 
发件人： Acee Lindem (acee)
发送时间： 2021-03-27 18:31
收件人： Chongfeng Xie; Dongjie (Jimmy); Acee Lindem (acee); lsr@ietf.org
主题： 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 member:
 
Hi Chongfeng, 
 
Another thing, if one is trying to support a VTN with legacy technologies, it 
would be good to decouple it from the SR resource-aware segments. 
 
Thanks,
Acee
 
From: Chongfeng Xie 
Date: Friday, March 26, 2021 at 11:15 PM
To: Acee Lindem , Jie Dong , 
"chongfeng.xie" , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: Re: 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,
 
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); lsr@ietf.org
主题： 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,
 
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  on behalf of Jie Dong 
Date: Friday, March 26, 2021 at 10:39 AM
To: Chongfeng Xie , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
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, 
 
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 dif

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

[Acee Lindem (acee)]

Hi Chongfeng,

Given that the main argument for using MT to realize VTNs in the control plane 
is that it is a mature and deployed technology, requiring resource-aware 
segments, a new and evolving technology, defeats the purpose.

Thanks,
Acee

From: Chongfeng Xie 
Date: Monday, March 29, 2021 at 8:58 AM
To: Acee Lindem , "chongfeng.xie" , 
Jie Dong , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: Re: 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,
Thanks for your comments. This document can be used with resource-aware 
segments to provide VTNs with guaranteed resources, while I agree it may also 
be used with legacy SR technologies. This could be clarified in next version.

Regards
Chongfeng

发件人： Acee Lindem (acee)<mailto:a...@cisco.com>
发送时间： 2021-03-27 18:31
收件人： Chongfeng Xie<mailto:chongfeng@foxmail.com>; Dongjie 
(Jimmy)<mailto:jie.d...@huawei.com>; Acee Lindem 
(acee)<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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 member:

Hi Chongfeng,

Another thing, if one is trying to support a VTN with legacy technologies, it 
would be good to decouple it from the SR resource-aware segments.

Thanks,
Acee

From: Chongfeng Xie 
Date: Friday, March 26, 2021 at 11:15 PM
To: Acee Lindem , Jie Dong , 
"chongfeng.xie" , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: Re: 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,

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)<mailto:a...@cisco.com>
发送时间： 2021-03-26 23:30
收件人： Dongjie (Jimmy)<mailto:jie.d...@huawei.com>; Chongfeng 
Xie<mailto:chongfeng@foxmail.com>; Acee Lindem 
(acee)<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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,

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  on behalf of Jie Dong 
Date: Friday, March 26, 2021 at 10:39 AM
To: Chongfeng Xie , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
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,

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:lsr-boun...@ietf.org] On Behalf Of Chongfeng Xie
Sent: Friday, March 26, 2021 2:14 PM
To: Acee Lindem (acee) ; lsr@ietf.org
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，

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 netw

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

[Chongfeng Xie]

Hi, Acee,
Thanks for your comments. This document can be used with resource-aware 
segments to provide VTNs with guaranteed resources, while I agree it may also 
be used with legacy SR technologies. This could be clarified in next version.

Regards
Chongfeng
 
发件人： Acee Lindem (acee)
发送时间： 2021-03-27 18:31
收件人： Chongfeng Xie; Dongjie (Jimmy); Acee Lindem (acee); lsr@ietf.org
主题： 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 member:
 
Hi Chongfeng, 
 
Another thing, if one is trying to support a VTN with legacy technologies, it 
would be good to decouple it from the SR resource-aware segments. 
 
Thanks,
Acee
 
From: Chongfeng Xie 
Date: Friday, March 26, 2021 at 11:15 PM
To: Acee Lindem , Jie Dong , 
"chongfeng.xie" , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: Re: 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,
 
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); lsr@ietf.org
主题： 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,
 
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  on behalf of Jie Dong 
Date: Friday, March 26, 2021 at 10:39 AM
To: Chongfeng Xie , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
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, 
 
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:lsr-boun...@ietf.org] On Behalf Of Chongfeng Xie
Sent: Friday, March 26, 2021 2:14 PM
To: Acee Lindem (acee) ; lsr@ietf.org
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，
 
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
 

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

[Tony Przygienda]

hat 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) >> 40cisco@dmarc.ietf.org> 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  on behalf of "Acee Lindem (acee)"
>>>> 
>>>>
>>>>
>>>> *Date: *Tuesday, March 2, 2021 at 6: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
>>>>
>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>> *Email gyan.s.mis...@verizon.com *
>>>
>>>
>>>
>>> *M 301 502-1347*
>>>
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

sting 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  wrote:
>
>>
>> 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) > 40cisco@dmarc.ietf.org> 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  on behalf of "Acee Lindem (acee)"
>>> 
>>>
>>>
>>> *Date: *Tuesday, March 2, 2021 at 6:28 PM
>>> *To: *"lsr@ietf.org"

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

[Tony Przygienda]

ming 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)  40cisco@dmarc.ietf.org> 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  on behalf of "Acee Lindem (acee)"
>> 
>>
>>
>> *Date: *Tuesday, March 2, 2021 at 6: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
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Speaking as WG member:

Hi Chongfeng,

Another thing, if one is trying to support a VTN with legacy technologies, it 
would be good to decouple it from the SR resource-aware segments.

Thanks,
Acee

From: Chongfeng Xie 
Date: Friday, March 26, 2021 at 11:15 PM
To: Acee Lindem , Jie Dong , 
"chongfeng.xie" , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: Re: 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,

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)<mailto:a...@cisco.com>
发送时间： 2021-03-26 23:30
收件人： Dongjie (Jimmy)<mailto:jie.d...@huawei.com>; Chongfeng 
Xie<mailto:chongfeng@foxmail.com>; Acee Lindem 
(acee)<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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,

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  on behalf of Jie Dong 
Date: Friday, March 26, 2021 at 10:39 AM
To: Chongfeng Xie , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
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,

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:lsr-boun...@ietf.org] On Behalf Of Chongfeng Xie
Sent: Friday, March 26, 2021 2:14 PM
To: Acee Lindem (acee) ; lsr@ietf.org
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，

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\)<mailto:acee=40cisco....@dmarc.ietf.org>
发送时间： 2021-03-26 02:20
收件人： lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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:

There has been considerable support for this document. However, there has 

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

[Gyan Mishra]

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)  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  on behalf of "Acee Lindem (acee)"
> 
>
>
> *Date: *Tuesday, March 2, 2021 at 6: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
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Chongfeng Xie]

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); lsr@ietf.org
主题： 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,
 
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  on behalf of Jie Dong 
Date: Friday, March 26, 2021 at 10:39 AM
To: Chongfeng Xie , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
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, 
 
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:lsr-boun...@ietf.org] On Behalf Of Chongfeng Xie
Sent: Friday, March 26, 2021 2:14 PM
To: Acee Lindem (acee) ; lsr@ietf.org
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，
 
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
收件人： lsr@ietf.org
主题： 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:
 
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  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, March 2, 2021 at 6:28 PM
To: "lsr@ietf.org" 
Subject: [Lsr] WG

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

[Acee Lindem (acee)]

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  on behalf of Jie Dong 
Date: Friday, March 26, 2021 at 10:39 AM
To: Chongfeng Xie , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
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,

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:lsr-boun...@ietf.org] On Behalf Of Chongfeng Xie
Sent: Friday, March 26, 2021 2:14 PM
To: Acee Lindem (acee) ; lsr@ietf.org
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，

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\)<mailto:acee=40cisco@dmarc.ietf.org>
发送时间： 2021-03-26 02:20
收件人： lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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:

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 mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>
Date: Tuesday, March 2, 2021 at 6:28 PM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto: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 we

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

[Dongjie (Jimmy)]

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:lsr-boun...@ietf.org] On Behalf Of Chongfeng Xie
Sent: Friday, March 26, 2021 2:14 PM
To: Acee Lindem (acee) ; lsr@ietf.org
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，

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\)<mailto:acee=40cisco@dmarc.ietf.org>
发送时间： 2021-03-26 02:20
收件人： lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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:

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 mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>
Date: Tuesday, March 2, 2021 at 6:28 PM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto: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

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

[Chongfeng Xie]

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
收件人： lsr@ietf.org
主题： 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:
 
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  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, March 2, 2021 at 6: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

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

[Acee Lindem (acee)]

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  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, March 2, 2021 at 6: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

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

[Takuya Miyasaka]

Hi all,

I support the adoption of this draft.

I reviewed this draft-xie-lsr-isis-sr-vtn-mt-03 and I think this draft 
describes a good use case which realizes VPN+ by using existing IS-IS 
extensions such as Multi-Topology, SR, and TE.


Thanks,
Takuya

On 2021/03/03 8:27, Acee Lindem (acee) wrote:


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

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

[chenha...@outlook.com]

Hi Xuesong,
 
Thanks for your support.
 
Regarding your comment about the overlay and underlay network, in this context 
the overlay refers to the VPN overlays which provide the service connectivity, 
and the underlay refers to the set of network topology and resources provided 
using VTNs. We could add some text in next version to make this clear.

Best regards，
Chenhao


发件人： Gengxuesong (Geng Xuesong)
发送时间： 2021-03-18 16:55
收件人： Acee Lindem (acee); lsr@ietf.org
主题： 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 WG,
 
I support the adoption of this informational document. 
The combination of IS-IS MT with TE extensions allows to build VTNs with 
customized topology and link attributes, and SR SIDs are used to steer traffic 
using the topologies and resources of each VTN.  This mechanism is clear and 
makes sense.
 
A small editor comment:
In section 1 introduction, it is mentioned that “Thus these properties require 
integration between the underlay and the overlay networks.” This sentence has 
some abruptness in the text . Does “underlay  network” mean network resource 
and “network overlay” mean network topology? More descriptions here may help in 
the following version.
 
Best
Xuesong
 
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 7:28 AM
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

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

[Gengxuesong (Geng Xuesong)]

Hi WG,

I support the adoption of this informational document.
The combination of IS-IS MT with TE extensions allows to build VTNs with 
customized topology and link attributes, and SR SIDs are used to steer traffic 
using the topologies and resources of each VTN.  This mechanism is clear and 
makes sense.

A small editor comment:
In section 1 introduction, it is mentioned that “Thus these properties require 
integration between the underlay and the overlay networks.” This sentence has 
some abruptness in the text . Does “underlay  network” mean network resource 
and “network overlay” mean network topology? More descriptions here may help in 
the following version.

Best
Xuesong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 7:28 AM
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

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

[lich...@chinatelecom.cn]

Hi, folks,
In this draft, MT-ID is resued as the control plane ID of VTN and advertise TE 
attrributes for different VTNs. I think it is useful for carrier network, and I 
support it to be adopted.

Best regards
Chen 



李  晨  Li Chen
中国电信研究院  网络规划研究创新中心
电话：010-50902891/18910853955
邮箱：lich...@chinatelecom.cn/18910853...@chinatelecom.cn
只为成功找方法，不为失败找借口
==
Chen  Li
Network Planning Researching and Innovation Center
Email：lich...@chinatelecom.cn /18910853...@chinatelecom.cn
Tel: +86-10-50902891
Mobile: +86-18910853955
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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, all

This document provides useful information about how existing IS-IS TLVs can be 
used together to deliver SR based VTN.
I support its adoption as an informational document.

Best regards,
Pang Ran

发件人： Acee Lindem (acee)<mailto:acee=40cisco@dmarc.ietf.org>
发送时间： 2021-03-03 07:27
收件人： lsr@ietf.org<mailto:lsr@ietf.org>
主题： [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


如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received 
this email in error please notify us immediately by e-mail. Please reply to 
hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will 
immediately remove your information from send catalogue of our.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[lic...@chinatelecom.cn]

Hi, all

 This draft describes the IGP control plane mechanism with necessary extensions 
to build SR based VTNs. It is useful. I support the adoption of this document.



Best regards，
Cong Li
 
发件人： Acee Lindem (acee)
发送时间： 2021-03-03 07:27
收件人： lsr@ietf.org
主题： [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

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

[peng.shaofu]

Hi Jie and all,






I'm sorry to have digressed in the adoption on this informational 
draft-xie-lsr-isis-sr-vtn-mt-03. However, I think these enhanced-vpn related 
documents are closely related, although they are divided into multiple 
documents. So discussing the main document (draft-dong-lsr-sr-for-enhanced-vpn) 
doesn't conflict with this one.





For VTN-ID, I don't believe it is interpreted by you as for scalability 
purpose, which is very interesting. 

Here are two things:

1) The slice-based ID is introduced into the control plane and the forwarding 
plane, and the SID per slice is assigned and advertised. This is done by 
draft-peng.

2) Optimize scalability issues. For example, the forwarding behavior of 
prefix-SID per slice can be inherited from flex-algo. That is clearly described 
by draft-bestbar.




Please don't confuse the above two things, that is, you can't say that one 
thing becomes another just because we try to optimize one aspect of it.


Once the slice-based ID is introduced, it can be used to distinguish which 
slice the service belongs to, and that is not related with whether different 
slice can or not share the same topology.






Regards,


PSF






原始邮件



发件人：Dongjie(Jimmy)
收件人：彭少富10053815;
抄送人：hayabusa...@gmail.com;rob...@raszuk.net;ts...@juniper.net;chongfeng@foxmail.com;ginsberg=40cisco@dmarc.ietf.org;lsr@ietf.org;a...@cisco.com;tonysi...@gmail.com;
日 期 ：2021年03月09日 19:32
主 题 ：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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

 

Hi,


 


Since this discussion is not related to the adoption poll for 
draft-xie-lsr-isis-sr-vtn-mt, please start a separate mail thread if you want 
to discuss other documents.


 


A brief reply:


 


In the current version or any previous version of 
draft-peng-teas-network-slicing, there is no scalability considerations, nor 
any mechanism to improve the scalability. While the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn was introduced for the scalability purpose 
one year ago. Thus I think your statement is totally wrong.


 


Best regards,


Jie


 




From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of peng.sha...@zte.com.cn
 Sent: Tuesday, March 9, 2021 10:52 AM
 To: Dongjie (Jimmy) 
 Cc: hayabusa...@gmail.com; rob...@raszuk.net; ts...@juniper.net; 
chongfeng@foxmail.com; ginsberg=40cisco@dmarc.ietf.org; lsr@ietf.org; 
a...@cisco.com; tonysi...@gmail.com
 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 Jie,

 

Now that you mention VTN-ID, I have to point out that the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn is actually the AII in 
draft-peng-teas-network-slicing, just a new name. That can be seen from the 
evolution of the historical versions of the these two drafts.

See https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/

 

I'm glad to see that the idea in draft-peng-teas-network-slicing and 
draft-bestbar-spring-scalable-ns have been generously adopted by you.

 

Regards,

PSF


 


原始邮件



发件人：Dongjie(Jimmy)



收件人：Tarek Saad;Gyan Mishra;Tony Przygienda;



抄送人：Les Ginsberg (ginsberg);Chongfeng Xie;Acee Lindem (acee);Robert 
Raszuk;lsr@ietf.org;



日 期 ：2021年03月09日 00:31



主 题 ：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




___
 Lsr mailing list
 Lsr@ietf.org
 https://www.ietf.org/mailman/listinfo/lsr


Hi Tarek,


 


Your understanding about the scalability implication of this MT based VTN 
mechanism is correct, this is also described in section “scalability 
considerations” of this draft. The value of this mechanism is that it reuses 
several existing TLVs together to provide the required function.


 


As for the mechanisms which can provide better scalability, you could refer to 
draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is 
introduced, and multiple VTNs can be associated with the same topology. Further 
discussion about that draft and its relationship with 
draft-bestbar-lsr-spring-sa could happen in a separate thread.


 


Best regards,


Jie


 




From: Tarek Saad [mailto:ts...@juniper.net] 
 Sent: Monday, March 8, 2021 10:44 PM
 To: Dongjie (Jimmy) ; Gyan Mishra 
; Tony Przygienda 
 Cc: Les Ginsberg (ginsberg) ; Chongfeng 
Xie ; Acee Lindem (acee) ; Robert 
Raszuk ; lsr@ietf.org
 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 authors,


 


My understanding is the draft is proposing a separate MT topology

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

[Giuseppe Fioccola]

Hi All,
I support the adoption of this document. It provides an useful mechanism to 
build SR based VTNs using existing IS-IS Multi-Topology instances to provide 
the network resources for each VTN.

Regards,

Giuseppe

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 12:28 AM
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

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

[Dongjie (Jimmy)]

Hi,

Since this discussion is not related to the adoption poll for 
draft-xie-lsr-isis-sr-vtn-mt, please start a separate mail thread if you want 
to discuss other documents.

A brief reply:

In the current version or any previous version of 
draft-peng-teas-network-slicing, there is no scalability considerations, nor 
any mechanism to improve the scalability. While the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn was introduced for the scalability purpose 
one year ago. Thus I think your statement is totally wrong.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Sent: Tuesday, March 9, 2021 10:52 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
ts...@juniper.net<mailto:ts...@juniper.net>; 
chongfeng@foxmail.com<mailto:chongfeng@foxmail.com>; 
ginsberg=40cisco@dmarc.ietf.org<mailto:ginsberg=40cisco@dmarc.ietf.org>;
 lsr@ietf.org<mailto:lsr@ietf.org>; a...@cisco.com<mailto:a...@cisco.com>; 
tonysi...@gmail.com<mailto:tonysi...@gmail.com>
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 Jie,



Now that you mention VTN-ID, I have to point out that the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn is actually the AII in 
draft-peng-teas-network-slicing, just a new name. That can be seen from the 
evolution of the historical versions of the these two drafts.

See https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/



I'm glad to see that the idea in draft-peng-teas-network-slicing and 
draft-bestbar-spring-scalable-ns have been generously adopted by you.



Regards,

PSF


原始邮件
发件人：Dongjie(Jimmy)
收件人：Tarek Saad;Gyan Mishra;Tony Przygienda;
抄送人：Les Ginsberg (ginsberg);Chongfeng Xie;Acee Lindem (acee);Robert 
Raszuk;lsr@ietf.org;
日 期 ：2021年03月09日 00:31
主 题 ：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
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
Hi Tarek,

Your understanding about the scalability implication of this MT based VTN 
mechanism is correct, this is also described in section “scalability 
considerations” of this draft. The value of this mechanism is that it reuses 
several existing TLVs together to provide the required function.

As for the mechanisms which can provide better scalability, you could refer to 
draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is 
introduced, and multiple VTNs can be associated with the same topology. Further 
discussion about that draft and its relationship with 
draft-bestbar-lsr-spring-sa could happen in a separate thread.

Best regards,
Jie
 
From: Tarek Saad [mailto:ts...@juniper.net]
Sent: Monday, March 8, 2021 10:44 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Gyan 
Mishra mailto:hayabusa...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Cc: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Chongfeng Xie mailto:chongfeng@foxmail.com>>; 
Acee Lindem (acee) mailto:a...@cisco.com>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; lsr@ietf.org<mailto:lsr@ietf.org>
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 authors,

My understanding is the draft is proposing a separate MT topology (unique 
MT-ID) to identify a forwarding treatment to be enforced on a shared resource.
While this may work for limited number of MT topologies (i.e. forwarding 
treatments), as described in RF5120 there is overhead with creating/advertising 
and managing and running separate SPF for each of the MT topology. This will 
restrict the scalability of such approach (number of forwarding treatments to 
be realized) using this approach.

In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an independent ID 
(associated with the forwarding treatment) independent of the topology ID. This 
allows the # of forwarding treatmentst to be independent of the # of MT 
topologies that need to be managed by IGP; and hence, allow it to scale. Your 
feedback on this approach is welcome.

Regards,
Tarek


On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" 
mailto:lsr-boun...@ietf.org> on behalf of 
jie.d...@huawei.com<mailto:jie.d...@huawei.com>> wrote:

Hi Gyan,

Thanks for your comments.

As you mentioned, both MT and MI can provide separate topologies and the 
topology based computation, and MI can provide separate LSDBs at some 
addit

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

[peng.shaofu]

Hi Jie,






Now that you mention VTN-ID, I have to point out that the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn is actually the AII in 
draft-peng-teas-network-slicing, just a new name. That can be seen from the 
evolution of the historical versions of the these two drafts.

See https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/





I'm glad to see that the idea in draft-peng-teas-network-slicing and 
draft-bestbar-spring-scalable-ns have been generously adopted by you.




Regards,

PSF









原始邮件



发件人：Dongjie(Jimmy)
收件人：Tarek Saad;Gyan Mishra;Tony Przygienda;
抄送人：Les Ginsberg (ginsberg);Chongfeng Xie;Acee Lindem (acee);Robert 
Raszuk;lsr@ietf.org;
日 期 ：2021年03月09日 00:31
主 题 ：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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

 

Hi Tarek,


 


Your understanding about the scalability implication of this MT based VTN 
mechanism is correct, this is also described in section “scalability 
considerations” of this draft. The value of this mechanism is that it reuses 
several existing TLVs together to provide the required function.


 


As for the mechanisms which can provide better scalability, you could refer to 
draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is 
introduced, and multiple VTNs can be associated with the same topology. Further 
discussion about that draft and its relationship with 
draft-bestbar-lsr-spring-sa could happen in a separate thread.


 


Best regards,


Jie


 




From: Tarek Saad [mailto:ts...@juniper.net] 
 Sent: Monday, March 8, 2021 10:44 PM
 To: Dongjie (Jimmy) ; Gyan Mishra 
; Tony Przygienda 
 Cc: Les Ginsberg (ginsberg) ; Chongfeng 
Xie ; Acee Lindem (acee) ; Robert 
Raszuk ; lsr@ietf.org
 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 authors,


 


My understanding is the draft is proposing a separate MT topology (unique 
MT-ID) to identify a forwarding treatment to be enforced on a shared resource.


While this may work for limited number of MT topologies (i.e. forwarding 
treatments), as described in RF5120 there is overhead with creating/advertising 
and managing and running separate SPF for each of the MT topology. This will 
restrict the scalability of such approach (number of forwarding treatments to 
be realized) using this approach.


 


In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an independent ID 
(associated with the forwarding treatment) independent of the topology ID. This 
allows the # of forwarding treatmentst to be independent of the # of MT 
topologies that need to be managed by IGP; and hence, allow it to scale. Your 
feedback on this approach is welcome.


 


Regards,


Tarek


 


 


On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)"  wrote:




 


Hi Gyan,


 


Thanks for your comments. 


 


As you mentioned, both MT and MI can provide separate topologies and the 
topology based computation, and MI can provide separate LSDBs at some 
additional cost (separate adjacencies, etc.). In this document, the resource of 
VTN mainly refers to the forwarding plane resources, thus MT is chosen as it 
can provide the required functionality with less overhead. 


 


Hope this helps.


 


Best regards,


Jie


 




From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gyan Mishra
 Sent: Monday, March 8, 2021 7:29 AM
 To: Tony Przygienda 
 Cc: Les Ginsberg (ginsberg) ; Chongfeng 
Xie ; Acee Lindem (acee) ; Robert 
Raszuk ; lsr@ietf.org
 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




 


 


Dear Authors 



 


Why was MT chosen and not MI for VTN underlay network slice underpinning.  MT 
instances has separate topology but not separate LSDB where MI Multi instance 
RFC 6822 has a separate LSDB for resources isolation and I think would be a 
better fit for VTN underlay provisioning.



 


MI



https://tools.ietf.org/html/rfc6822



 


Thanks 



 


Gyan



 


On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda  wrote:



 


Robert ruminated: 


 


That said I think perhaps we are indeed missing LROW WG (Local Routing 
Operations WG) where just like in GROW WG where mainly (Global) BGP operational 
aspects are discussed there could be good place to discuss operational aspects 
of link state protocols deployment and use cases. In fact perhaps it would also 
free some LSR bandwidth to really focus on protocol extensions. 



 



 


+1



 


IGPs grew a zoo of horns and bells by now and no'one tells the operators which 
spines are poisonous ;-)






 

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

[Dongjie (Jimmy)]

Hi Tarek,

Your understanding about the scalability implication of this MT based VTN 
mechanism is correct, this is also described in section “scalability 
considerations” of this draft. The value of this mechanism is that it reuses 
several existing TLVs together to provide the required function.

As for the mechanisms which can provide better scalability, you could refer to 
draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is 
introduced, and multiple VTNs can be associated with the same topology. Further 
discussion about that draft and its relationship with 
draft-bestbar-lsr-spring-sa could happen in a separate thread.

Best regards,
Jie

From: Tarek Saad [mailto:ts...@juniper.net]
Sent: Monday, March 8, 2021 10:44 PM
To: Dongjie (Jimmy) ; Gyan Mishra ; 
Tony Przygienda 
Cc: Les Ginsberg (ginsberg) ; Chongfeng 
Xie ; Acee Lindem (acee) ; Robert 
Raszuk ; lsr@ietf.org
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 authors,

My understanding is the draft is proposing a separate MT topology (unique 
MT-ID) to identify a forwarding treatment to be enforced on a shared resource.
While this may work for limited number of MT topologies (i.e. forwarding 
treatments), as described in RF5120 there is overhead with creating/advertising 
and managing and running separate SPF for each of the MT topology. This will 
restrict the scalability of such approach (number of forwarding treatments to 
be realized) using this approach.

In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an independent ID 
(associated with the forwarding treatment) independent of the topology ID. This 
allows the # of forwarding treatmentst to be independent of the # of MT 
topologies that need to be managed by IGP; and hence, allow it to scale. Your 
feedback on this approach is welcome.

Regards,
Tarek


On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" 
mailto:lsr-boun...@ietf.org> on behalf of 
jie.d...@huawei.com<mailto:jie.d...@huawei.com>> wrote:

Hi Gyan,

Thanks for your comments.

As you mentioned, both MT and MI can provide separate topologies and the 
topology based computation, and MI can provide separate LSDBs at some 
additional cost (separate adjacencies, etc.). In this document, the resource of 
VTN mainly refers to the forwarding plane resources, thus MT is chosen as it 
can provide the required functionality with less overhead.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda mailto:tonysi...@gmail.com>>
Cc: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Chongfeng Xie mailto:chongfeng@foxmail.com>>; 
Acee Lindem (acee) mailto:a...@cisco.com>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; lsr@ietf.org<mailto:lsr@ietf.org>
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


Dear Authors

Why was MT chosen and not MI for VTN underlay network slice underpinning.  MT 
instances has separate topology but not separate LSDB where MI Multi instance 
RFC 6822 has a separate LSDB for resources isolation and I think would be a 
better fit for VTN underlay provisioning.

MI
https://tools.ietf.org/html/rfc6822

Thanks

Gyan

On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

Robert ruminated:

That said I think perhaps we are indeed missing LROW WG (Local Routing 
Operations WG) where just like in GROW WG where mainly (Global) BGP operational 
aspects are discussed there could be good place to discuss operational aspects 
of link state protocols deployment and use cases. In fact perhaps it would also 
free some LSR bandwidth to really focus on protocol extensions.


+1

IGPs grew a zoo of horns and bells by now and no'one tells the operators which 
spines are poisonous ;-)

--- tony
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD



Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tarek Saad]

Hi Tony,

Just so we are on same page, I think you are agreeing on the overhead per MT 
(and even MI) that would be incurred using the approach proposed in I-D. 
draft-xie-lsr-isis-sr-vtn-mt to realize a forwarding treatment on a shared 
resource.

To you’re point on flex-algo producing disconnected topologies,  
I-D.draft-bestbar-lsr-spring-sa is NOT adding any **new** considerations or a 
change that would impact the behavior for computing per prefix SID paths as 
described in I-D.draft-ietf-lsr-flex-algo. It is only proposing to associate a 
SID with a forwarding treatment.

Regards,
Tarek


On 3/8/21, 9:54 AM, "Tony Przygienda" 
mailto:tonysi...@gmail.com>> wrote:

[External Email. Be cautious of content]

This argument seems fairly bogus to me. if you use IGP to flood some stuff and 
then want the distributed computation stitch it together based on IGP topology 
to get you a nexthop you end in computation which is something like Bellman or 
Dijkstra or Boruvka. Unless you have some controller distributing next-hops but 
then it's really PCE and not IGP AFAIS.

The difference in MI and MT is that MT carries the topology information 
everywhere (you don't have to compute if you're not part of [simple check on 
adjacencies] it but you still get stuff flooded). Some people like that 
(manageability), some don't. IS does only flood to nodes connected in MI.

Operationally I learned ages ago that topologies disconnecting are some of the 
most vexing scenarios and there MT is @ an advantage since partitioned topology 
can be easily derived (and that's BTW why it's built that way with strict 
adjacency negotiation). Reading the bestbar draft and looking @ e.g. flex algo 
I am waiting to see how the "I cannot get there, why?" problems

On Mon, Mar 8, 2021 at 3:43 PM Tarek Saad 
mailto:ts...@juniper.net>> wrote:
Hi authors,

My understanding is the draft is proposing a separate MT topology (unique 
MT-ID) to identify a forwarding treatment to be enforced on a shared resource.
While this may work for limited number of MT topologies (i.e. forwarding 
treatments), as described in RF5120 there is overhead with creating/advertising 
and managing and running separate SPF for each of the MT topology. This will 
restrict the scalability of such approach (number of forwarding treatments to 
be realized) using this approach.

In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an independent ID 
(associated with the forwarding treatment) independent of the topology ID. This 
allows the # of forwarding treatmentst to be independent of the # of MT 
topologies that need to be managed by IGP; and hence, allow it to scale. Your 
feedback on this approach is welcome.

Regards,
Tarek


On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" 
mailto:lsr-boun...@ietf.org> on behalf of 
jie.d...@huawei.com<mailto:jie.d...@huawei.com>> wrote:

Hi Gyan,

Thanks for your comments.

As you mentioned, both MT and MI can provide separate topologies and the 
topology based computation, and MI can provide separate LSDBs at some 
additional cost (separate adjacencies, etc.). In this document, the resource of 
VTN mainly refers to the forwarding plane resources, thus MT is chosen as it 
can provide the required functionality with less overhead.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf 
Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda mailto:tonysi...@gmail.com>>
Cc: Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; 
Chongfeng Xie mailto:chongfeng@foxmail.com>>; 
Acee Lindem (acee) mailto:a...@cisco.com>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; lsr@ietf.org<mailto:lsr@ietf.org>
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


Dear Authors

Why was MT chosen and not MI for VTN underlay network slice underpinning.  MT 
instances has separate topology but not separate LSDB where MI Multi instance 
RFC 6822 has a separate LSDB for resources isolation and I think would be a 
better fit for VTN underlay provisioning.

MI
https://tools.ietf.org/html/rfc6822<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc6822__;!!NEt6yMaO-gk!W0I8TTnvfmnvtp4AbIlYuPMM8_M1XF91FAbQTNSjvXvd9Qq8qoW8C7H7OSh6fw$>

Thanks

Gyan

On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

Robert ruminated:

That said I think perhaps we are indeed missing LROW WG (Local Routing 
Operations WG) where just like in GROW WG where mainly (Global) BGP operational 
aspects are discussed there could be good place to discuss operational aspects 
of link state protocols deployment and use cases. In fact perhaps it would also 
free some LSR bandwidth to really focus on protocol extensions.


+1

IGPs g

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

[Tony Przygienda]

This argument seems fairly bogus to me. if you use IGP to flood some stuff
and then want the distributed computation stitch it together based on IGP
topology to get you a nexthop you end in computation which is something
like Bellman or Dijkstra or Boruvka. Unless you have some controller
distributing next-hops but then it's really PCE and not IGP AFAIS.

The difference in MI and MT is that MT carries the topology information
everywhere (you don't have to compute if you're not part of [simple check
on adjacencies] it but you still get stuff flooded). Some people like that
(manageability), some don't. IS does only flood to nodes connected in MI.

Operationally I learned ages ago that topologies disconnecting are some of
the most vexing scenarios and there MT is @ an advantage since partitioned
topology can be easily derived (and that's BTW why it's built that way with
strict adjacency negotiation). Reading the bestbar draft and looking @ e.g.
flex algo I am waiting to see how the "I cannot get there, why?" problems

On Mon, Mar 8, 2021 at 3:43 PM Tarek Saad  wrote:

> Hi authors,
>
>
>
> My understanding is the draft is proposing a separate MT topology (unique
> MT-ID) to identify a forwarding treatment to be enforced on a shared
> resource.
>
> While this may work for limited number of MT topologies (i.e. forwarding
> treatments), as described in RF5120 there is overhead with
> creating/advertising and managing and running separate SPF for each of the
> MT topology. This will restrict the scalability of such approach (number of
> forwarding treatments to be realized) using this approach.
>
>
>
> In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an
> independent ID (associated with the forwarding treatment) independent of
> the topology ID. This allows the # of forwarding treatmentst to be
> independent of the # of MT topologies that need to be managed by IGP; and
> hence, allow it to scale. Your feedback on this approach is welcome.
>
>
>
> Regards,
>
> Tarek
>
>
>
>
>
> On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" <
> lsr-boun...@ietf.org on behalf of jie.d...@huawei.com> wrote:
>
>
>
> Hi Gyan,
>
>
>
> Thanks for your comments.
>
>
>
> As you mentioned, both MT and MI can provide separate topologies and the
> topology based computation, and MI can provide separate LSDBs at some
> additional cost (separate adjacencies, etc.). In this document, the
> resource of VTN mainly refers to the forwarding plane resources, thus MT is
> chosen as it can provide the required functionality with less overhead.
>
>
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan Mishra
> *Sent:* Monday, March 8, 2021 7:29 AM
> *To:* Tony Przygienda 
> *Cc:* Les Ginsberg (ginsberg) ;
> Chongfeng Xie ; Acee Lindem (acee) <
> a...@cisco.com>; Robert Raszuk ; lsr@ietf.org
> *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
>
>
>
>
>
> Dear Authors
>
>
>
> Why was MT chosen and not MI for VTN underlay network slice underpinning.
> MT instances has separate topology but not separate LSDB where MI Multi
> instance RFC 6822 has a separate LSDB for resources isolation and I think
> would be a better fit for VTN underlay provisioning.
>
>
>
> MI
>
> https://tools.ietf.org/html/rfc6822
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda 
> wrote:
>
>
>
> Robert ruminated:
>
>
>
> That said I think perhaps we are indeed missing LROW WG (Local Routing
> Operations WG) where just like in GROW WG where mainly (Global) BGP
> operational aspects are discussed there could be good place to discuss
> operational aspects of link state protocols deployment and use cases. In
> fact perhaps it would also free some LSR bandwidth to really focus on
> protocol extensions.
>
>
>
>
>
> +1
>
>
>
> IGPs grew a zoo of horns and bells by now and no'one tells the operators
> which spines are poisonous ;-)
>
>
>
> --- tony
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> [image: 图像已被发件人删除。] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
> Juniper Business Use Only
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Hi Jie

Response in-line

Thank you

Gyan

On Mon, Mar 8, 2021 at 9:11 AM Dongjie (Jimmy)  wrote:

> Hi Gyan,
>
>
>
> Thanks for your comments.
>
>
>
> As you mentioned, both MT and MI can provide separate topologies and the
> topology based computation, and MI can provide separate LSDBs at some
> additional cost (separate adjacencies, etc.). In this document, the
> resource of VTN mainly refers to the forwarding plane resources, thus MT is
> chosen as it can provide the required functionality with less overhead.
>
> Gyan> Makes sense.  As their are many ways to provide resource isolation a
> key point that this draft solution that it provides is an optimal resource
> isolation as that relates to forwarding plane isolation of resources thus
> from a TEAS Network slice perspective, MT was chosen purposely as the
> requirement is exclusively for forwarding plane FIB programming isolation
> and not both forwarding and control plane isolation super set provided by
> MI.  This maybe a good point to note as to why MT was chosen.  Also from an
> IGP perspective why ISIS is chosen over OSPF for VTN underlay resource
> provisioning as OSPF does not have a MT concept.
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan Mishra
> *Sent:* Monday, March 8, 2021 7:29 AM
> *To:* Tony Przygienda 
> *Cc:* Les Ginsberg (ginsberg) ;
> Chongfeng Xie ; Acee Lindem (acee) <
> a...@cisco.com>; Robert Raszuk ; lsr@ietf.org
> *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
>
>
>
>
>
> Dear Authors
>
>
>
> Why was MT chosen and not MI for VTN underlay network slice underpinning.
> MT instances has separate topology but not separate LSDB where MI Multi
> instance RFC 6822 has a separate LSDB for resources isolation and I think
> would be a better fit for VTN underlay provisioning.
>
>
>
> MI
>
> https://tools.ietf.org/html/rfc6822
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda 
> wrote:
>
>
>
> Robert ruminated:
>
>
>
> That said I think perhaps we are indeed missing LROW WG (Local Routing
> Operations WG) where just like in GROW WG where mainly (Global) BGP
> operational aspects are discussed there could be good place to discuss
> operational aspects of link state protocols deployment and use cases. In
> fact perhaps it would also free some LSR bandwidth to really focus on
> protocol extensions.
>
>
>
>
>
> +1
>
>
>
> IGPs grew a zoo of horns and bells by now and no'one tells the operators
> which spines are poisonous ;-)
>
>
>
> --- tony
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> [image: 图像已被发件人删除。] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail=g>
> *Silver Spring, MD
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tarek Saad]

Hi authors,

My understanding is the draft is proposing a separate MT topology (unique 
MT-ID) to identify a forwarding treatment to be enforced on a shared resource.
While this may work for limited number of MT topologies (i.e. forwarding 
treatments), as described in RF5120 there is overhead with creating/advertising 
and managing and running separate SPF for each of the MT topology. This will 
restrict the scalability of such approach (number of forwarding treatments to 
be realized) using this approach.

In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an independent ID 
(associated with the forwarding treatment) independent of the topology ID. This 
allows the # of forwarding treatmentst to be independent of the # of MT 
topologies that need to be managed by IGP; and hence, allow it to scale. Your 
feedback on this approach is welcome.

Regards,
Tarek


On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" 
mailto:lsr-boun...@ietf.org> on behalf of 
jie.d...@huawei.com<mailto:jie.d...@huawei.com>> wrote:

Hi Gyan,

Thanks for your comments.

As you mentioned, both MT and MI can provide separate topologies and the 
topology based computation, and MI can provide separate LSDBs at some 
additional cost (separate adjacencies, etc.). In this document, the resource of 
VTN mainly refers to the forwarding plane resources, thus MT is chosen as it 
can provide the required functionality with less overhead.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda 
Cc: Les Ginsberg (ginsberg) ; Chongfeng 
Xie ; Acee Lindem (acee) ; Robert 
Raszuk ; lsr@ietf.org
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


Dear Authors

Why was MT chosen and not MI for VTN underlay network slice underpinning.  MT 
instances has separate topology but not separate LSDB where MI Multi instance 
RFC 6822 has a separate LSDB for resources isolation and I think would be a 
better fit for VTN underlay provisioning.

MI
https://tools.ietf.org/html/rfc6822

Thanks

Gyan

On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

Robert ruminated:

That said I think perhaps we are indeed missing LROW WG (Local Routing 
Operations WG) where just like in GROW WG where mainly (Global) BGP operational 
aspects are discussed there could be good place to discuss operational aspects 
of link state protocols deployment and use cases. In fact perhaps it would also 
free some LSR bandwidth to really focus on protocol extensions.


+1

IGPs grew a zoo of horns and bells by now and no'one tells the operators which 
spines are poisonous ;-)

--- tony
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD



Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Dongjie (Jimmy)]

Hi Gyan,

Thanks for your comments.

As you mentioned, both MT and MI can provide separate topologies and the 
topology based computation, and MI can provide separate LSDBs at some 
additional cost (separate adjacencies, etc.). In this document, the resource of 
VTN mainly refers to the forwarding plane resources, thus MT is chosen as it 
can provide the required functionality with less overhead.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda 
Cc: Les Ginsberg (ginsberg) ; Chongfeng 
Xie ; Acee Lindem (acee) ; Robert 
Raszuk ; lsr@ietf.org
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


Dear Authors

Why was MT chosen and not MI for VTN underlay network slice underpinning.  MT 
instances has separate topology but not separate LSDB where MI Multi instance 
RFC 6822 has a separate LSDB for resources isolation and I think would be a 
better fit for VTN underlay provisioning.

MI
https://tools.ietf.org/html/rfc6822

Thanks

Gyan

On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

Robert ruminated:

That said I think perhaps we are indeed missing LROW WG (Local Routing 
Operations WG) where just like in GROW WG where mainly (Global) BGP operational 
aspects are discussed there could be good place to discuss operational aspects 
of link state protocols deployment and use cases. In fact perhaps it would also 
free some LSR bandwidth to really focus on protocol extensions.


+1

IGPs grew a zoo of horns and bells by now and no'one tells the operators which 
spines are poisonous ;-)

--- tony
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Dear Authors

Why was MT chosen and not MI for VTN underlay network slice underpinning.
MT instances has separate topology but not separate LSDB where MI Multi
instance RFC 6822 has a separate LSDB for resources isolation and I think
would be a better fit for VTN underlay provisioning.

MI
https://tools.ietf.org/html/rfc6822

Thanks

Gyan

On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda  wrote:

>
> Robert ruminated:
>
>>
>> That said I think perhaps we are indeed missing LROW WG (Local Routing
>> Operations WG) where just like in GROW WG where mainly (Global) BGP
>> operational aspects are discussed there could be good place to discuss
>> operational aspects of link state protocols deployment and use cases. In
>> fact perhaps it would also free some LSR bandwidth to really focus on
>> protocol extensions.
>>
>>
> +1
>
> IGPs grew a zoo of horns and bells by now and no'one tells the operators
> which spines are poisonous ;-)
>
> --- tony
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tony Przygienda]

Robert ruminated:

>
> That said I think perhaps we are indeed missing LROW WG (Local Routing
> Operations WG) where just like in GROW WG where mainly (Global) BGP
> operational aspects are discussed there could be good place to discuss
> operational aspects of link state protocols deployment and use cases. In
> fact perhaps it would also free some LSR bandwidth to really focus on
> protocol extensions.
>
>
+1

IGPs grew a zoo of horns and bells by now and no'one tells the operators
which spines are poisonous ;-)

--- tony
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Lizhenbin]

Hi All,
I support the adoption as the co-author. I believe MT can play an important 
role to build SR-based VTN and the current RFCs does not cover the topic. The 
draft will be an useful informational document.


Best Regards,
Zhenbin (Robin)



--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com<mailto:lizhen...@huawei.com>
发件人：Acee Lindem (acee) 
收件人：lsr 
时 间：2021-03-03 07:28:17
主 题：[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

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

[Mach Chen]

Hi,

I have read the draft, it describes how to leverage existing TLVs to implement 
SR VTN, it can be an useful informational document. Hence, I support the 
adoption.

Best regards,
Mach

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 7:28 AM
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

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

[Dongjie (Jimmy)]

Hi Robert,

In my interpretation, you also think this document is useful to the operators.

This document does not introduce new encodings to IS-IS, while it provides 
information which was not covered explicitly in the specifications of the 
protocol encodings. For example, with the VTN mechanism, how traffic in 
different topologies are forwarded on a shared outgoing interface. There are 
also other points as mentioned in Chongfeng’s mail. Thus IMO it has its value 
as an informational LSR document.

A WG on IGP operation may be helpful. Before that happens, all the IGP stuff 
belongs to LSR:)

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Saturday, March 6, 2021 7:10 PM
To: Les Ginsberg (ginsberg) ; Chongfeng 
Xie 
Cc: lsr@ietf.org; Acee Lindem (acee) 
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


Hello,

I agree with Les that this draft may not be a fit for LSR WG.

Typically this type of effort (essentially describing use cases) is much better 
to be put in slides and present on various operators forums.

That said I think perhaps we are indeed missing LROW WG (Local Routing 
Operations WG) where just like in GROW WG where mainly (Global) BGP operational 
aspects are discussed there could be good place to discuss operational aspects 
of link state protocols deployment and use cases. In fact perhaps it would also 
free some LSR bandwidth to really focus on protocol extensions.

Thx,
R.



On Thu, Mar 4, 2021 at 5:18 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Chongfeng –

Just to clarify my position…

IMO there is no substantive content in this draft that warrants it becoming an 
RFC – Informational track or otherwise. It is simply a set of pointers to other 
documents/registries.

If the authors find the content in some way helpful, I think the more suitable 
path for you is to publish a white paper and post it on whatever web site seems 
appropriate to you.
I just do not see any content in the draft that warrants a standards body like 
IETF producing a new document.

Thanx.

   Les


From: Chongfeng Xie 
mailto:chongfeng@foxmail.com>>
Sent: Thursday, March 04, 2021 5:04 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Acee Lindem (acee) mailto:a...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: 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， Les,

Thanks for the review of this document.

As the current document type is informational, it does not introduce new TLV to 
IS-IS. While it describes the mechanisms of using existing TLVs to distribute 
the information of SR based VTNs, which can have customized topology and a set 
of dedicated network resources. It also describes the forwarding behaviors 
based on the SIDs and the resources allocated to each VTN.

IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple 
logical topologies and perform independent path computation for each topology. 
RFC 5120 mentions that the TE attributes TLVs can be inherited by the MT TLVs 
“if traffic engineering or some other applications are being applied per 
topology level later”. While it does not specify what the topology-specific TE 
attributes mean, and how traffic in different topologies are forwarded on a 
shared outgoing interface. These are described in section 3 and section 4 of 
this document.

RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR 
SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs and 
Locators are not specified, especially when the SIDs are associated with 
different set of network resources.

Section 5 gives the analysis about the scalability of this mechanism, and talks 
about a case where two VTNs have the same logical topology, but with different 
set of resources.

IMO the value of this document is that it provides an option to build SR VTNs 
with no IS-IS protocol extensions, which could be useful for some network 
scenarios.

Best regards,
Chongfeng


chongfeng@foxmail.com<mailto:chongfeng@foxmail.com>

发件人： Les Ginsberg \(ginsberg\)<mailto:ginsberg=40cisco@dmarc.ietf.org>
发送时间： 2021-03-04 11:52
收件人： Acee Lindem (acee)<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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
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

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

[Robert Raszuk]

Hello,

I agree with Les that this draft may not be a fit for LSR WG.

Typically this type of effort (essentially describing use cases) is much
better to be put in slides and present on various operators forums.

That said I think perhaps we are indeed missing LROW WG (Local Routing
Operations WG) where just like in GROW WG where mainly (Global) BGP
operational aspects are discussed there could be good place to discuss
operational aspects of link state protocols deployment and use cases. In
fact perhaps it would also free some LSR bandwidth to really focus on
protocol extensions.

Thx,
R.



On Thu, Mar 4, 2021 at 5:18 PM Les Ginsberg (ginsberg)  wrote:

> Chongfeng –
>
>
>
> Just to clarify my position…
>
>
>
> IMO there is no substantive content in this draft that warrants it
> becoming an RFC – Informational track or otherwise. It is simply a set of
> pointers to other documents/registries.
>
>
>
> If the authors find the content in some way helpful, I think the more
> suitable path for you is to publish a white paper and post it on whatever
> web site seems appropriate to you.
>
> I just do not see any content in the draft that warrants a standards body
> like IETF producing a new document.
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
>
>
> *From:* Chongfeng Xie 
> *Sent:* Thursday, March 04, 2021 5:04 AM
> *To:* Les Ginsberg (ginsberg) ; Acee Lindem (acee) <
> a...@cisco.com>; lsr@ietf.org
> *Subject:* Re: 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， Les,
>
>
>
> Thanks for the review of this document.
>
>
>
> As the current document type is informational, it does not introduce new
> TLV to IS-IS. While it describes the mechanisms of using existing TLVs to
> distribute the information of SR based VTNs, which can have customized
> topology and a set of dedicated network resources. It also describes the
> forwarding behaviors based on the SIDs and the resources allocated to each
> VTN.
>
>
>
> IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple
> logical topologies and perform independent path computation for each
> topology. RFC 5120 mentions that the TE attributes TLVs can be inherited by
> the MT TLVs “if traffic engineering or some other applications are being
> applied per topology level later”. While it does not specify what the
> topology-specific TE attributes mean, and how traffic in different
> topologies are forwarded on a shared outgoing interface. These are
> described in section 3 and section 4 of this document.
>
>
>
> RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR
> SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs
> and Locators are not specified, especially when the SIDs are associated
> with different set of network resources.
>
>
>
> Section 5 gives the analysis about the scalability of this mechanism, and
> talks about a case where two VTNs have the same logical topology, but with
> different set of resources.
>
>
>
> IMO the value of this document is that it provides an option to build SR
> VTNs with no IS-IS protocol extensions, which could be useful for some
> network scenarios.
>
>
>
> Best regards,
>
> Chongfeng
>
>
> ------------------
>
> chongfeng@foxmail.com
>
>
>
> *发件人：* Les Ginsberg \(ginsberg\) 
>
> *发送时间：* 2021-03-04 11:52
>
> *收件人：* Acee Lindem (acee) ; lsr@ietf.org
>
> *主题：* 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
>
> 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

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

[Davey Song]

 +1 support. It is a good piece of work.

Davey

*发件人：* Acee Lindem \(acee\) 
*发送时间：* 2021-03-03 07:27
*收件人：* lsr@ietf.org
*主题：* [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

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

[Gyan Mishra]

I support WG adoption of this document by LSR.

In the context of TEAS NS definition and VTN underlay provisioning of
network slice resources underpinning to Enhanced VPN + overlay, I believe
this draft provides and important solution as to the resource isolation and
provisioning of a network slice using existing ISIS MT instances to provide
the resource isolation framework for each discrete VTN.

I believe this same VTN provisioning could be done as well using ISIS
instances RFC 6822 or a combination of MT and ISIS instances.

With OSPFv3 as well multiple processes would have to be provisioned as the
concept of MT is MI does not exist for OSPF thus ISIS is the desired
protocol for network slicing.

https://tools.ietf.org/html/rfc6822

Kind Regards

Gyan

On Thu, Mar 4, 2021 at 11:18 AM Les Ginsberg (ginsberg)  wrote:

> Chongfeng –
>
>
>
> Just to clarify my position…
>
>
>
> IMO there is no substantive content in this draft that warrants it
> becoming an RFC – Informational track or otherwise. It is simply a set of
> pointers to other documents/registries.
>
>
>
> If the authors find the content in some way helpful, I think the more
> suitable path for you is to publish a white paper and post it on whatever
> web site seems appropriate to you.
>
> I just do not see any content in the draft that warrants a standards body
> like IETF producing a new document.
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
>
>
> *From:* Chongfeng Xie 
> *Sent:* Thursday, March 04, 2021 5:04 AM
> *To:* Les Ginsberg (ginsberg) ; Acee Lindem (acee) <
> a...@cisco.com>; lsr@ietf.org
> *Subject:* Re: 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， Les,
>
>
>
> Thanks for the review of this document.
>
>
>
> As the current document type is informational, it does not introduce new
> TLV to IS-IS. While it describes the mechanisms of using existing TLVs to
> distribute the information of SR based VTNs, which can have customized
> topology and a set of dedicated network resources. It also describes the
> forwarding behaviors based on the SIDs and the resources allocated to each
> VTN.
>
>
>
> IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple
> logical topologies and perform independent path computation for each
> topology. RFC 5120 mentions that the TE attributes TLVs can be inherited by
> the MT TLVs “if traffic engineering or some other applications are being
> applied per topology level later”. While it does not specify what the
> topology-specific TE attributes mean, and how traffic in different
> topologies are forwarded on a shared outgoing interface. These are
> described in section 3 and section 4 of this document.
>
>
>
> RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR
> SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs
> and Locators are not specified, especially when the SIDs are associated
> with different set of network resources.
>
>
>
> Section 5 gives the analysis about the scalability of this mechanism, and
> talks about a case where two VTNs have the same logical topology, but with
> different set of resources.
>
>
>
> IMO the value of this document is that it provides an option to build SR
> VTNs with no IS-IS protocol extensions, which could be useful for some
> network scenarios.
>
>
>
> Best regards,
>
> Chongfeng
>
>
> ------------------
>
> chongfeng@foxmail.com
>
>
>
> *发件人：* Les Ginsberg \(ginsberg\) 
>
> *发送时间：* 2021-03-04 11:52
>
> *收件人：* Acee Lindem (acee) ; lsr@ietf.org
>
> *主题：* 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
>
> 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

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

[Les Ginsberg (ginsberg)]

Chongfeng –

Just to clarify my position…

IMO there is no substantive content in this draft that warrants it becoming an 
RFC – Informational track or otherwise. It is simply a set of pointers to other 
documents/registries.

If the authors find the content in some way helpful, I think the more suitable 
path for you is to publish a white paper and post it on whatever web site seems 
appropriate to you.
I just do not see any content in the draft that warrants a standards body like 
IETF producing a new document.

Thanx.

   Les


From: Chongfeng Xie 
Sent: Thursday, March 04, 2021 5:04 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: 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， Les,

Thanks for the review of this document.

As the current document type is informational, it does not introduce new TLV to 
IS-IS. While it describes the mechanisms of using existing TLVs to distribute 
the information of SR based VTNs, which can have customized topology and a set 
of dedicated network resources. It also describes the forwarding behaviors 
based on the SIDs and the resources allocated to each VTN.

IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple 
logical topologies and perform independent path computation for each topology. 
RFC 5120 mentions that the TE attributes TLVs can be inherited by the MT TLVs 
“if traffic engineering or some other applications are being applied per 
topology level later”. While it does not specify what the topology-specific TE 
attributes mean, and how traffic in different topologies are forwarded on a 
shared outgoing interface. These are described in section 3 and section 4 of 
this document.

RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR 
SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs and 
Locators are not specified, especially when the SIDs are associated with 
different set of network resources.

Section 5 gives the analysis about the scalability of this mechanism, and talks 
about a case where two VTNs have the same logical topology, but with different 
set of resources.

IMO the value of this document is that it provides an option to build SR VTNs 
with no IS-IS protocol extensions, which could be useful for some network 
scenarios.

Best regards,
Chongfeng


chongfeng@foxmail.com<mailto:chongfeng@foxmail.com>

发件人： Les Ginsberg \(ginsberg\)<mailto:ginsberg=40cisco@dmarc.ietf.org>
发送时间： 2021-03-04 11:52
收件人： Acee Lindem (acee)<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题： 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
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-

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

[Aijun Wang]

Hi,Les:

My understanding is that 
https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ proposed the 
necessary IGP extensions to accomplish more abundant VTN function, while this 
adopting draft described how to utilize the existing MT mechanism to achieve 
the basic VTN function.
And based on the above differences, the corresponding part of 
https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-05#section-3.1
 should be removed and kept only in the current information draft because it 
doesn’t need protocol extension.

Adopting this document can certainly accelerate the deployment of MT/SR based 
VTN, using the existing tools invented by IETF. 

This document just tell the reader how to achieve the above goal.
Then I support its adoption.


Aijun Wang
China Telecom

> On Mar 4, 2021, at 21:04, Chongfeng Xie  wrote:
> 
> 
> 
> Hi， Les,
>  
> Thanks for the review of this document.
>  
> As the current document type is informational, it does not introduce new TLV 
> to IS-IS. While it describes the mechanisms of using existing TLVs to 
> distribute the information of SR based VTNs, which can have customized 
> topology and a set of dedicated network resources. It also describes the 
> forwarding behaviors based on the SIDs and the resources allocated to each 
> VTN.
>  
> IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple 
> logical topologies and perform independent path computation for each 
> topology. RFC 5120 mentions that the TE attributes TLVs can be inherited by 
> the MT TLVs “if traffic engineering or some other applications are being 
> applied per topology level later”. While it does not specify what the 
> topology-specific TE attributes mean, and how traffic in different topologies 
> are forwarded on a shared outgoing interface. These are described in section 
> 3 and section 4 of this document.
>  
> RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR 
> SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs 
> and Locators are not specified, especially when the SIDs are associated with 
> different set of network resources.
>  
> Section 5 gives the analysis about the scalability of this mechanism, and 
> talks about a case where two VTNs have the same logical topology, but with 
> different set of resources.
>  
> IMO the value of this document is that it provides an option to build SR VTNs 
> with no IS-IS protocol extensions, which could be useful for some network 
> scenarios.
>  
> Best regards,
> Chongfeng
> 
> chongfeng@foxmail.com
>  
> 发件人： Les Ginsberg \(ginsberg\)
> 发送时间： 2021-03-04 11:52
> 收件人： Acee Lindem (acee); lsr@ietf.org
> 主题： 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
> 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 mo

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

[Chongfeng Xie]

Hi， Les,
 
Thanks for the review of this document.
 
As the current document type is informational, it does not introduce new TLV to 
IS-IS. While it describes the mechanisms of using existing TLVs to distribute 
the information of SR based VTNs, which can have customized topology and a set 
of dedicated network resources. It also describes the forwarding behaviors 
based on the SIDs and the resources allocated to each VTN.
 
IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple 
logical topologies and perform independent path computation for each topology. 
RFC 5120 mentions that the TE attributes TLVs can be inherited by the MT TLVs 
“if traffic engineering or some other applications are being applied per 
topology level later”. While it does not specify what the topology-specific TE 
attributes mean, and how traffic in different topologies are forwarded on a 
shared outgoing interface. These are described in section 3 and section 4 of 
this document.
 
RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR 
SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs and 
Locators are not specified, especially when the SIDs are associated with 
different set of network resources.
 
Section 5 gives the analysis about the scalability of this mechanism, and talks 
about a case where two VTNs have the same logical topology, but with different 
set of resources.
 
IMO the value of this document is that it provides an option to build SR VTNs 
with no IS-IS protocol extensions, which could be useful for some network 
scenarios.
 
Best regards,
Chongfeng



chongfeng@foxmail.com
 
发件人： Les Ginsberg \(ginsberg\)
发送时间： 2021-03-04 11:52
收件人： Acee Lindem (acee); lsr@ietf.org
主题： 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
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  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

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

[Les Ginsberg (ginsberg)]

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  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

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

[Chongfeng Xie]

Hi, Qin,
 
Thanks a lot for your support. Please see some replies inline:

Chongfeng 



chongfeng@foxmail.com
 
发件人： Qin Wu
发送时间： 2021-03-03 14:50
收件人： Acee Lindem (acee); lsr@ietf.org
主题： 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,
I have read this draft and It is well written and I support adoption of this 
work.
Here are a few comments and suggestions:
1.   What is VTN resource, how do we define network resource, is the 
resource a.   the label that is switched on the path of the LSP, b.   
is the resource physical resource assigned to LSP?c.   Is the resource a 
measure of the capacity of a link that is dedicated for use by the traffic on 
the LSP.d.   Is the resource referred to node or link in the network 
topology?Would it be great to provide VTN resource definition in the 
terminology section,[Chongfeng] The resource in this context is the forwarding 
resources (e.g. bandwidth and the associated buffer/queuing and scheduling 
resources). For detailed description about the resources allocated to VTN, 
please refer to draft-ietf-spring-resource-aware-segments and 
draft-ietf-spring-sr-for-enhanced-vpn.
In addition, I also recommend you to reference RFC8413 for resource definition. 
[Chongfeng] Thanks for the pointer, we will take a look at it.2.   Section 
2 said:“The MT-specific Link or Prefix TLVs are defined by adding additional 
two bytes, which includes 12-bit MT-ID field in  front of the ISN TLV and IP or 
IPv6 Reachability TLVs.”
Does this require protocol extension? Are these two bytes reserved fields?  
Where MT-ID is defined? In which RFC? Also ISN TLV, IP/Ipv6 Reachablity TLV, 
where these TLVS are defined? Please provide references.

[Chongfeng] As this is an informational draft, there is no new TLV defined. The 
MT-ID based TLVs are defined in RFC 5120. The ISN TLV and the IP Reachablity 
TLV is defined in RFC 5305, are the IPv6  Reachablity is defined in RFC 5308. 
We could add some references and pointers to make it clearer. 
 
-Qin Wu
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2021年3月3日 7:28
收件人: lsr@ietf.org
主题: [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

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

[Linda Dunbar]

I support the WG Adoption of this draft.
This information draft describes how RFC5305, RFC8570 are used to advertise 
topology specific TE attributes, and SR VTN resource attribute. it is useful.


Linda Dunbar
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, March 2, 2021 5: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

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

[Huaimo Chen]

Hi Everyone,

I read through the document and support its adoption.

Best Regards,
Huaimo

From: Lsr  on behalf of Acee Lindem (acee) 

Sent: Tuesday, March 2, 2021 6:27 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

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

[duzongp...@foxmail.com]

Hi, all

I support the adoption of this document. It is straightforward and reasonable 
to use MT to build VTNs with customized topology and attributes, and the 
document is well written. 

Best Regards
Zongpeng Du



duzongp...@foxmail.com & duzongp...@chinamobile.com
 
发件人： Acee Lindem \(acee\)
发送时间： 2021-03-03 07:27
收件人： lsr@ietf.org
主题： [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

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

[Huzhibo]

Support the adoption.

Zhibo Hu

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 7:28 AM
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

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

[Dongjie (Jimmy)]

Hi,

Support the adoption as a coauthor.

This document describes a practical mechanism to use MT together with segment 
routing to build SR based VTNs.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 7:28 AM
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

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

[Qin Wu]

Hi,
I have read this draft and It is well written and I support adoption of this 
work.
Here are a few comments and suggestions:

1.   What is VTN resource, how do we define network resource, is the 
resource

a.   the label that is switched on the path of the LSP,

b.   is the resource physical resource assigned to LSP?

c.   Is the resource a measure of the capacity of a link that is dedicated 
for use by the traffic on the LSP.

d.   Is the resource referred to node or link in the network topology?

Would it be great to provide VTN resource definition in the terminology section,

In addition, I also recommend you to reference RFC8413 for resource definition.



2.   Section 2 said:

“

The MT-specific Link or Prefix TLVs are defined by

   adding additional two bytes, which includes 12-bit MT-ID field in

   front of the ISN TLV and IP or IPv6 Reachability TLVs.

”
Does this require protocol extension? Are these two bytes reserved fields?  
Where MT-ID is defined? In which RFC?
Also ISN TLV, IP/Ipv6 Reachablity TLV, where these TLVS are defined? Please 
provide references.


-Qin Wu
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2021年3月3日 7:28
收件人: lsr@ietf.org
主题: [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

[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

[Acee Lindem (acee)]

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