Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Les Ginsberg (ginsberg)]

Trying to avoid piling on...but Peter is certainly correct that there is 
nothing in this draft that is normative.

This may provide useful context for the protocol extensions defined in 
https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/. As such the 
content would be better incorporated into that draft.
Whether the WG decides to take on enhanced VPN or not is still TBD, but there 
is no reason I can see for this draft to exist independently.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Dongjie (Jimmy)
> Sent: Wednesday, March 25, 2020 11:41 PM
> To: Peter Psenak ;
> xie...@chinatelecom.cn; lsr 
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
> Virtual Transport Network
> 
> Hi Peter,
> 
> As described in the abstract, the purpose of this draft is to define a 
> simplified
> control plane mechanism to build SR based Virtual Transport Network (VTN),
> it is based on the combination of IS-IS Multi-Topology with other IS-IS
> extensions, e.g. the extensions for TE, SR and L2 bundle. In a word, it tries 
> to
> reuse the existing TLVs as much as possible.
> 
> That said, this document introduces the mechanism of specifying per-
> topology TE attributes, which was not covered in the existing IS-IS MT (RFC
> 5120). Similarly, it also introduces the mechanism of associating MT-IDs with 
> a
> particular member link of L2 bundle, which was not defined in IS-IS L2 Bundle
> (RFC 8668).
> 
> Thus we think it is appropriate to be standard track.
> 
> Best regards,
> Jie
> 
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> > Sent: Wednesday, March 25, 2020 10:09 PM
> > To: xie...@chinatelecom.cn; lsr 
> > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing
> based
> > Virtual Transport Network
> >
> > Hi Chongfeng,
> >
> > what exactly is being standardized in this draft? I don't see anything.
> >
> > thanks,
> > Peter
> >
> >
> > On 25/03/2020 14:44, xie...@chinatelecom.cn wrote:
> > >
> > > Hello, folks,
> > >
> > > we have submitted a new draft of
> > >   https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .
> > >
> > > It is about Using IS-IS Multi-Topology (MT) for Segment Routing based
> > > Virtual Transport Network. Enhanced VPN (VPN+) as defined in
> > > I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
> > > support some applications's needs of enhanced isolation and stringent
> > > performance requirements.  VPN+ requries integration between the
> > > overlay VPN and the underlay network.  A Virtual Transport Network
> > > (VTN) is a virtual network which consists of a subset of the network
> > > toplogy and network resources allocated from the underlay network.  A
> > > VTN could be used as the underlay for one or a group of VPN+ services.
> > > This document describes a simplified mechanism to build the SR based
> > > VTNs using IGP
> > > multi- topology together with other well-defined IS-IS extensions.
> > >
> > > Comments and suggestions are highly appreciated.
> > >
> > > Chongfeng Xie
> > >
> > >
> >
> > ___
> > 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[John E Drake]

Hi,

As Joel notes, it is true that enhanced VPNs require the use of specific 
underlay network resources, either dedicated or shared, but the this needs to 
be done without installing overlay VPN awareness in the P routers, which is 
inherently unscalable and operationally complex.  Also, since VPNs span 
multiple ASes, putting overlay VPN state in an IGP doesn't work. 

Please see:  https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn-02

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Joel M. Halpern
> Sent: Thursday, March 26, 2020 9:36 AM
> To: xie...@chinatelecom.cn; lsr 
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
> Virtual Transport Network
> 
> [External Email. Be cautious of content]
> 
> 
> In once sense, the statement is inherently true.  A VPN technology without
> underlay support would seem to have significant difficulty in consistently
> meeting an SLA.  Having said that much, the rest does not seem to follow.
> 
> Yours,
> Joel
> 
> On 3/26/2020 1:40 AM, xie...@chinatelecom.cn wrote:
> >
> > Hi, Joel,
> >
> > The statement is that pure overlay VPNs cannot meet the requirement of
> > some new services, and it would require integration between the
> > underlay and the overlay networks.
> >
> > As mentioned in this document, there is existing technology in the
> > underlay to support enhanced VPNs , such as using a set of MPLS-TE
> > based resource reserved point-to-point paths, while it scalability is
> > the concern of many operators.
> >
> > Thus VTN is introduced to provide the required topology and resource
> > attribute in the underlay in a scalable manner. This is described in
> > the introduction section.
> >
> > Hope this helps.
> >
> >
> > Chongfeng
> >
> >
> > *From:* Joel M. Halpern 
> > *Date:* 2020-03-25 21:52
> > *To:* xie...@chinatelecom.cn ; lsr
> > 
> > *Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
> > Routing based Virtual Transport Network
> > This drafts starts by asserting that there are limitations on what can
> > be done with the existing technology.  As the description is quite
> > vague, I can not be certain.  But I do not know of any difficulty in
> > providing the described capabilities with current technology, without
> > introducing a new, undescribed, construct called a VTN.
> > Yours,
> > Joel
> > On 3/25/2020 9:44 AM, xie...@chinatelecom.cn wrote:
> >  >
> >  > Hello, folks,
> >  >
> >  > we have submitted a new draft of
> >  >   
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-xie-lsr-
> isis-sr-vtn-mt-00__;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bsfyXyHvpt8$  .
> >  >
> >  > It is about Using IS-IS Multi-Topology (MT) for Segment Routing
> > based
> >  > Virtual Transport Network. Enhanced VPN (VPN+) as defined in
> >  > I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
> >  > support some applications's needs of enhanced isolation and
> > stringent
> >  > performance requirements.  VPN+ requries integration between the
> > overlay
> >  > VPN and the underlay network.  A Virtual Transport Network (VTN)
> > is a
> >  > virtual network which consists of a subset of the network toplogy
> > and
> >  > network resources allocated from the underlay network.  A VTN
> > could be
> >  > used as the underlay for one or a group of VPN+ services.. This
> > document
> >  > describes a simplified mechanism to build the SR based VTNs using
> > IGP
> >  > multi- topology together with other well-defined IS-IS extensions.
> >  >
> >  > Comments and suggestions are highly appreciated.
> >  >
> >  > Chongfeng Xie
> >  >
> >  >
> >  >
> >  > ___
> >  > Lsr mailing list
> >  > Lsr@ietf.org
> >  >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bsfyCiP9TE0$
> >  >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > _;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bs
> > fyCiP9TE0$
> >
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > _;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bs
> > fyCiP9TE0$
> >
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 

[Lsr] Slides for Interim Meeting

[Yingzhen Qu]

Hi presenters,

Please send your slides to lsr-cha...@ietf.org before the end of this month
(3/31).

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

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Peter, 

As described in the abstract, the purpose of this draft is to define a 
simplified control plane mechanism to build SR based Virtual Transport Network 
(VTN), it is based on the combination of IS-IS Multi-Topology with other IS-IS 
extensions, e.g. the extensions for TE, SR and L2 bundle. In a word, it tries 
to reuse the existing TLVs as much as possible.

That said, this document introduces the mechanism of specifying per-topology TE 
attributes, which was not covered in the existing IS-IS MT (RFC 5120). 
Similarly, it also introduces the mechanism of associating MT-IDs with a 
particular member link of L2 bundle, which was not defined in IS-IS L2 Bundle 
(RFC 8668).

Thus we think it is appropriate to be standard track.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Wednesday, March 25, 2020 10:09 PM
> To: xie...@chinatelecom.cn; lsr 
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
> Virtual Transport Network
> 
> Hi Chongfeng,
> 
> what exactly is being standardized in this draft? I don't see anything.
> 
> thanks,
> Peter
> 
> 
> On 25/03/2020 14:44, xie...@chinatelecom.cn wrote:
> >
> > Hello, folks,
> >
> > we have submitted a new draft of
> >   https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .
> >
> > It is about Using IS-IS Multi-Topology (MT) for Segment Routing based
> > Virtual Transport Network. Enhanced VPN (VPN+) as defined in
> > I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
> > support some applications's needs of enhanced isolation and stringent
> > performance requirements.  VPN+ requries integration between the
> > overlay VPN and the underlay network.  A Virtual Transport Network
> > (VTN) is a virtual network which consists of a subset of the network
> > toplogy and network resources allocated from the underlay network.  A
> > VTN could be used as the underlay for one or a group of VPN+ services.
> > This document describes a simplified mechanism to build the SR based
> > VTNs using IGP
> > multi- topology together with other well-defined IS-IS extensions.
> >
> > Comments and suggestions are highly appreciated.
> >
> > Chongfeng Xie
> >
> >
> 
> ___
> 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] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Aijun Wang]

Hi, John:
In your proposal, there is the following text “ the network controller SHOULD 
ensure that the IGP and TE metrics for these resources is higher than the 
metrics for the underlay network resources allocated to non-enhanced VPNs.”
Considering these resources will span across the network and be changed upon 
the slicing requirements , will such arrangement make the metric allocation 
within the network a mess?
If the above statement can’t be met, how you ensure the traffic that pass the P 
router use the dedicated resource(for example, bandwidth)?

Aijun Wang
China Telecom

> On Mar 26, 2020, at 23:31, John E Drake 
>  wrote:
> 
> Hi,
> 
> As Joel notes, it is true that enhanced VPNs require the use of specific 
> underlay network resources, either dedicated or shared, but the this needs to 
> be done without installing overlay VPN awareness in the P routers, which is 
> inherently unscalable and operationally complex.  Also, since VPNs span 
> multiple ASes, putting overlay VPN state in an IGP doesn't work. 
> 
> Please see:  https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn-02
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Joel M. Halpern
>> Sent: Thursday, March 26, 2020 9:36 AM
>> To: xie...@chinatelecom.cn; lsr 
>> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
>> Virtual Transport Network
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> In once sense, the statement is inherently true.  A VPN technology without
>> underlay support would seem to have significant difficulty in consistently
>> meeting an SLA.  Having said that much, the rest does not seem to follow.
>> 
>> Yours,
>> Joel
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Slides for Interim Meeting

[Yingzhen Qu]

Forgot to mention this deadline is for meeting session #1 presenters.

Thanks,
Yingzhen

On Thu, Mar 26, 2020 at 1:39 PM Yingzhen Qu  wrote:

> Hi presenters,
>
> Please send your slides to lsr-cha...@ietf.org before the end of this
> month (3/31).
>
> Thanks,
> Yingzhen
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Peter Psenak]

Hi Dongjie,

On 26/03/2020 07:40, Dongjie (Jimmy) wrote:

Hi Peter,

As described in the abstract, the purpose of this draft is to define a 
simplified control plane mechanism to build SR based Virtual Transport Network 
(VTN), it is based on the combination of IS-IS Multi-Topology with other IS-IS 
extensions, e.g. the extensions for TE, SR and L2 bundle. In a word, it tries 
to reuse the existing TLVs as much as possible.


reusing the TLVs is not something that needs a standardization.



That said, this document introduces the mechanism of specifying per-topology TE attributes, which was not covered in the existing IS-IS MT (RFC 5120). 


I can clearly see that TLVs defined in RFC5120 are listed in the 
registry of sub-TLVs available for TLV 222/223


https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223

So I'm not sure what you are adding.


Similarly, it also introduces the mechanism of associating MT-IDs with a 
particular member link of L2 bundle, which was not defined in IS-IS L2 Bundle 
(RFC 8668).


carrying MT-ID in the L2 Bundle TLV is conceptually wrong.

It is the parent L3 link which has the association with the particular 
topology ID, you can not change the topology per L2 link member.


You are trying to overload the MT-ID with the VTN semantics, but you can 
not do it here. If you need a VTN ID for the L2 member link, which I'm 
not sure why, you need to define a a new attribute and not mix it with 
MT-ID.



thanks,
Peter




Thus we think it is appropriate to be standard track.

Best regards,
Jie


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Wednesday, March 25, 2020 10:09 PM
To: xie...@chinatelecom.cn; lsr 
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
Virtual Transport Network

Hi Chongfeng,

what exactly is being standardized in this draft? I don't see anything.

thanks,
Peter


On 25/03/2020 14:44, xie...@chinatelecom.cn wrote:


Hello, folks,

we have submitted a new draft of
   https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .

It is about Using IS-IS Multi-Topology (MT) for Segment Routing based
Virtual Transport Network. Enhanced VPN (VPN+) as defined in
I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
support some applications's needs of enhanced isolation and stringent
performance requirements.  VPN+ requries integration between the
overlay VPN and the underlay network.  A Virtual Transport Network
(VTN) is a virtual network which consists of a subset of the network
toplogy and network resources allocated from the underlay network.  A
VTN could be used as the underlay for one or a group of VPN+ services.
This document describes a simplified mechanism to build the SR based
VTNs using IGP
multi- topology together with other well-defined IS-IS extensions.

Comments and suggestions are highly appreciated.

Chongfeng Xie




___
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] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Peter, 

Thanks for your comments.

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, March 26, 2020 5:23 PM
> To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr
> 
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
> Virtual Transport Network
> 
> Hi Dongjie,
> 
> On 26/03/2020 07:40, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > As described in the abstract, the purpose of this draft is to define a 
> > simplified
> control plane mechanism to build SR based Virtual Transport Network (VTN), it
> is based on the combination of IS-IS Multi-Topology with other IS-IS 
> extensions,
> e.g. the extensions for TE, SR and L2 bundle. In a word, it tries to reuse the
> existing TLVs as much as possible.
> 
> reusing the TLVs is not something that needs a standardization.
> 
> >
> > That said, this document introduces the mechanism of specifying
> per-topology TE attributes, which was not covered in the existing IS-IS MT 
> (RFC
> 5120).
> 
> I can clearly see that TLVs defined in RFC5120 are listed in the registry of
> sub-TLVs available for TLV 222/223
> 
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtm
> l#isis-tlv-codepoints-22-23-25-141-222-223
> 
> So I'm not sure what you are adding.

In RFC 5120 section 7, it says that 

“If traffic engineering or some other applications are being applied per 
topology level later, the new TLVs can automatically inherit the same 
attributes already defined for the "standard" topology without going through 
long standard process to redefine them per topology.”

This indicates that per-topology TE attributes is not a feature specified in 
RFC5120, although the TLVs can be reused.

Although the IANA registry shows that all the TE attributes could be used in 
TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm aware of), 
could you help to provide the reference to such IANA specification? In 
addition, it seems not all of the TE attributes are suitable to be carried at 
per-topology level. Thus the IANA registry may need to be updated.

> >Similarly, it also introduces the mechanism of associating MT-IDs with a
> particular member link of L2 bundle, which was not defined in IS-IS L2 Bundle
> (RFC 8668).
> 
> carrying MT-ID in the L2 Bundle TLV is conceptually wrong.
> 
> It is the parent L3 link which has the association with the particular 
> topology
> ID, you can not change the topology per L2 link member.
> 
> You are trying to overload the MT-ID with the VTN semantics, but you can not
> do it here. If you need a VTN ID for the L2 member link, which I'm not sure
> why, you need to define a a new attribute and not mix it with MT-ID.

In this document we try to reuse the existing IDs and TLVs to fulfil the 
functionality required. Since several existing TLVs defined for L3 link have 
been introduced for the L2 bundle member, we are considering the possibility of 
also carrying MT-ID as another attribute of the member link. Could you 
elaborate why it cannot be reused? Of course defining a new VTN-ID is another 
option. We are open to discussion about this.

Best regards,
Jie

> 
> thanks,
> Peter
> 
> 
> >
> > Thus we think it is appropriate to be standard track.
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Wednesday, March 25, 2020 10:09 PM
> >> To: xie...@chinatelecom.cn; lsr 
> >> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
> >> Routing based Virtual Transport Network
> >>
> >> Hi Chongfeng,
> >>
> >> what exactly is being standardized in this draft? I don't see anything.
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >> On 25/03/2020 14:44, xie...@chinatelecom.cn wrote:
> >>>
> >>> Hello, folks,
> >>>
> >>> we have submitted a new draft of
> >>>    https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .
> >>>
> >>> It is about Using IS-IS Multi-Topology (MT) for Segment Routing
> >>> based Virtual Transport Network. Enhanced VPN (VPN+) as defined in
> >>> I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
> >>> support some applications's needs of enhanced isolation and
> >>> stringent performance requirements.  VPN+ requries integration
> >>> between the overlay VPN and the underlay network.  A Virtual
> >>> Transport Network
> >>> (VTN) is a virtual network which consists of a subset of the network
> >>> toplogy and network resources allocated from the underlay network.
> >>> A VTN could be used as the underlay for one or a group of VPN+ services.
> >>> This document describes a simplified mechanism to build the SR based
> >>> VTNs using IGP
> >>> multi- topology together with other well-defined IS-IS extensions.
> >>>
> >>> Comments and suggestions are highly appreciated.
> >>>
> >>> Chongfeng Xie
> >>>
> >>>
> >>
> >> ___
> >> Lsr mailing list
> >> Lsr@ietf.org
> >> 

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Peter Psenak]

Hi Dongjie,

On 26/03/2020 11:57, Dongjie (Jimmy) wrote:

Hi Peter,

Thanks for your comments.


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Thursday, March 26, 2020 5:23 PM
To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr

Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
Virtual Transport Network

Hi Dongjie,

On 26/03/2020 07:40, Dongjie (Jimmy) wrote:

Hi Peter,

As described in the abstract, the purpose of this draft is to define a 
simplified

control plane mechanism to build SR based Virtual Transport Network (VTN), it
is based on the combination of IS-IS Multi-Topology with other IS-IS extensions,
e.g. the extensions for TE, SR and L2 bundle. In a word, it tries to reuse the
existing TLVs as much as possible.

reusing the TLVs is not something that needs a standardization.



That said, this document introduces the mechanism of specifying

per-topology TE attributes, which was not covered in the existing IS-IS MT (RFC
5120).

I can clearly see that TLVs defined in RFC5120 are listed in the registry of
sub-TLVs available for TLV 222/223

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtm
l#isis-tlv-codepoints-22-23-25-141-222-223

So I'm not sure what you are adding.


In RFC 5120 section 7, it says that

“If traffic engineering or some other applications are being applied per topology level 
later, the new TLVs can automatically inherit the same attributes already defined for the 
"standard" topology without going through long standard process to redefine 
them per topology.”

This indicates that per-topology TE attributes is not a feature specified in 
RFC5120, although the TLVs can be reused.


the text above clearly says there is no standardization required.



Although the IANA registry shows that all the TE attributes could be used in 
TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm aware of), 
could you help to provide the reference to such IANA specification? In 
addition, it seems not all of the TE attributes are suitable to be carried at 
per-topology level. Thus the IANA registry may need to be updated.


Similarly, it also introduces the mechanism of associating MT-IDs with a

particular member link of L2 bundle, which was not defined in IS-IS L2 Bundle
(RFC 8668).

carrying MT-ID in the L2 Bundle TLV is conceptually wrong.

It is the parent L3 link which has the association with the particular topology
ID, you can not change the topology per L2 link member.

You are trying to overload the MT-ID with the VTN semantics, but you can not
do it here. If you need a VTN ID for the L2 member link, which I'm not sure
why, you need to define a a new attribute and not mix it with MT-ID.


In this document we try to reuse the existing IDs and TLVs to fulfil the 
functionality required. Since several existing TLVs defined for L3 link have 
been introduced for the L2 bundle member, we are considering the possibility of 
also carrying MT-ID as another attribute of the member link. Could you 
elaborate why it cannot be reused? Of course defining a new VTN-ID is another 
option. We are open to discussion about this.


the reason is simple - the L3 link is already associated with the MT-ID. 
You can not change the MT-ID of the underlying L2 link.


thanks,
Peter



Best regards,
Jie



thanks,
Peter




Thus we think it is appropriate to be standard track.

Best regards,
Jie


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Wednesday, March 25, 2020 10:09 PM
To: xie...@chinatelecom.cn; lsr 
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
Routing based Virtual Transport Network

Hi Chongfeng,

what exactly is being standardized in this draft? I don't see anything.

thanks,
Peter


On 25/03/2020 14:44, xie...@chinatelecom.cn wrote:


Hello, folks,

we have submitted a new draft of
    https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .

It is about Using IS-IS Multi-Topology (MT) for Segment Routing
based Virtual Transport Network. Enhanced VPN (VPN+) as defined in
I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
support some applications's needs of enhanced isolation and
stringent performance requirements.  VPN+ requries integration
between the overlay VPN and the underlay network.  A Virtual
Transport Network
(VTN) is a virtual network which consists of a subset of the network
toplogy and network resources allocated from the underlay network.
A VTN could be used as the underlay for one or a group of VPN+ services.
This document describes a simplified mechanism to build the SR based
VTNs using IGP
multi- topology together with other well-defined IS-IS extensions.

Comments and suggestions are highly appreciated.

Chongfeng Xie




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









___

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Joel M. Halpern]

In once sense, the statement is inherently true.  A VPN technology 
without underlay support would seem to have significant difficulty in 
consistently meeting an SLA.  Having said that much, the rest does not 
seem to follow.


Yours,
Joel

On 3/26/2020 1:40 AM, xie...@chinatelecom.cn wrote:


Hi, Joel,

The statement is that pure overlay VPNs cannot meet the requirement of 
some new services, and it would require integration between the underlay 
and the overlay networks.


As mentioned in this document, there is existing technology in the 
underlay to support enhanced VPNs , such as using a set of MPLS-TE based 
resource reserved point-to-point paths, while it scalability is the 
concern of many operators.


Thus VTN is introduced to provide the required topology and resource 
attribute in the underlay in a scalable manner. This is described in the 
introduction section.


Hope this helps.


Chongfeng


*From:* Joel M. Halpern 
*Date:* 2020-03-25 21:52
*To:* xie...@chinatelecom.cn ; lsr

*Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
Routing based Virtual Transport Network
This drafts starts by asserting that there are limitations on what can
be done with the existing technology.  As the description is quite
vague, I can not be certain.  But I do not know of any difficulty in
providing the described capabilities with current technology, without
introducing a new, undescribed, construct called a VTN.
Yours,
Joel
On 3/25/2020 9:44 AM, xie...@chinatelecom.cn wrote:
 >
 > Hello, folks,
 >
 > we have submitted a new draft of
 >   https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .
 >
 > It is about Using IS-IS Multi-Topology (MT) for Segment Routing
based
 > Virtual Transport Network. Enhanced VPN (VPN+) as defined in
 > I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
 > support some applications's needs of enhanced isolation and
stringent
 > performance requirements.  VPN+ requries integration between the
overlay
 > VPN and the underlay network.  A Virtual Transport Network (VTN)
is a
 > virtual network which consists of a subset of the network toplogy
and
 > network resources allocated from the underlay network.  A VTN
could be
 > used as the underlay for one or a group of VPN+ services.. This
document
 > describes a simplified mechanism to build the SR based VTNs using
IGP
 > multi- topology together with other well-defined IS-IS extensions.
 >
 > Comments and suggestions are highly appreciated.
 >
 > Chongfeng Xie
 >
 >
 >
 > ___
 > 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


___
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