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

From: "[email-masked]" <[email-masked]>
Date: Wed, 25 Mar 2020 21:44:49 +0800

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Mar 2020 09:52:51 -0400

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, [email-masked] 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.
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 25 Mar 2020 15:08:43 +0100

Hi Chongfeng,

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

thanks,
Peter

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 26 Mar 2020 13:40:19 +0800

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: [email-masked]; 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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 26 Mar 2020 06:40:59 +0000

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:[email-masked]] On Behalf Of Peter Psenak
> Sent: Wednesday, March 25, 2020 10:09 PM
> To: [email-masked]; lsr <[email-masked]>
> > 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

---

From: Peter Psenak <[email-masked]>
Date: Thu, 26 Mar 2020 10:23:23 +0100

Hi Dongjie,

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

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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 26 Mar 2020 10:57:40 +0000

Hi Peter, 

Thanks for your comments.

> From: Peter Psenak [mailto:[email-masked]]
> Sent: Thursday, March 26, 2020 5:23 PM
> To: Dongjie (Jimmy) <[email-masked]>; [email-masked]; lsr
> <[email-masked]>
> > 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).
> 
> 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
> 

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

> >>> It is about Using IS-IS Multi-Topology (MT) for Segment Routing
> >>> based Virtual Transport Network. Enhanced VPN (VPN+) as defined in
> >>> 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
> >>> 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.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 26 Mar 2020 12:02:54 +0100

Hi Dongjie,

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

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Mar 2020 09:35:57 -0400

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, [email-masked] 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 <mailto:[email-masked]>
>     *Date:* 2020-03-25 21:52
>     *To:* [email-masked] <mailto:[email-masked]>; lsr
>     <mailto:[email-masked]>
>     *Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
>     Routing based Virtual Transport Network
>     based
>     stringent
>     overlay
>      > used as the underlay for one or a group of VPN+ services.. This
>     document

---

From: John E Drake <[email-masked]>
Date: Thu, 26 Mar 2020 15:30:52 +0000

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

> From: Lsr <[email-masked]> On Behalf Of Joel M. Halpern
> Sent: Thursday, March 26, 2020 9:36 AM
> [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
> 
> > some new services, and it would require integration between the
> > underlay and the overlay networks.
> >
> > 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.
> >
> > attribute in the underlay in a scalable manner. This is described in
> > the introduction section.
> >
> > Hope this helps.
> >
> >
> > Chongfeng
> >
> >
> >      >   https://urldefense.com/v3/__https://tools.ietf.org/html/draft-xie-lsr-
> isis-sr-vtn-mt-00__;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bsfyXyHvpt8$  .
> >      >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bsfyCiP9TE0$
> >      >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > _;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bs
> > fyCiP9TE0$
> >
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > _;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bs
> > fyCiP9TE0$
> >
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-gk!UC57ahoSTr0MI_h20crJfu--
> 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bsfyCiP9TE0$

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 26 Mar 2020 16:04:53 +0000

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

> From: Lsr <[email-masked]> On Behalf Of Dongjie (Jimmy)
> Sent: Wednesday, March 25, 2020 11:41 PM
> To: Peter Psenak <ppsenak=[email-masked]>;
> [email-masked]; lsr <[email-masked]>
> 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
> > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing
> based
> > Virtual Transport Network
> >
> > Hi Chongfeng,
> >

---

From: Aijun Wang <[email-masked]>
Date: Fri, 27 Mar 2020 09:36:58 +0800

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 <jdrake=[email-masked]> wrote:
> 
> Hi,
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 27 Mar 2020 06:56:40 +0000

Hi Peter, 

You missed some of my comments in previous mail, could you also reply to this?

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

And please see further replies inline with [Jie]:

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Thursday, March 26, 2020 7:03 PM
To: Dongjie (Jimmy) <[email-masked]>; [email-masked]; lsr <[email-masked]>
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

Hi Dongjie,

On 26/03/2020 11:57, Dongjie (Jimmy) wrote:
>> To: Dongjie (Jimmy) <[email-masked]>; [email-masked]; 
>> lsr <[email-masked]>
>> 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.
>>
>> per-topology TE attributes, which was not covered in the existing 
>> IS-IS MT (RFC 5120).
>>

[Jie] My reading of the above text is that RFC 5120 leaves the specification of per-topology TE or other applications to a later document. And it is also related to my below comment which you missed.

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

[Jie] Maybe you could provide some information about the history of this IANA registry? It assumes all the TE attributes can be applied to both TLV 22 and TLV 222, which may not always be the case.

>> particular member link of L2 bundle, which was not defined in IS-IS 
>> L2 Bundle (RFC 8668).
>>
>> 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.
> 

[Jie] In this case, the L3 link is associated with the union of the MT-IDs associated with its L2 member links. 

For example, if a L3 link has three L2 member links, which are associated with MT-x, MT-y and MT-z respectively, then the L3 link is associated with MT-x, MT-y and MT-z.

Best regards,
Jie

thanks,
Peter

>>>>> (VTN) is a virtual network which consists of a subset of the 
>>>>> network toplogy and network resources allocated from the underlay network.
>>>>> This document describes a simplified mechanism to build the SR 
>>>>> based VTNs using IGP

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 27 Mar 2020 08:05:15 +0000

Hi Les, 

Although this draft reuses existing TLVs, we found that some usage may not be fully specified in existing RFCs. Please see my recent reply to Peter about the per-topology TE attributes, and the use of MT-ID in L2 bundle. Currently my preference is standard track, while it is open for discussion with the WG.

I agree this draft is relevant to draft-dong-lsr-sr-enhanced-vpn, and their relationship is described in the abstract of this document:

"I-D.dong-lsr-sr-enhanced-vpn defines the IGP extensions to build a set of Segment Routing (SR) based VTNs.  This document describes a simplified mechanism to build the SR based VTNs using IGP multi- topology together with other well-defined IS-IS extensions."

As this draft itself describes a stand-alone solution, maybe it is more appropriate to keep it as a separate document.

Bet regards,
Jie

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Friday, March 27, 2020 12:05 AM
To: Dongjie (Jimmy) <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; [email-masked]; lsr <[email-masked]>
Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

   Les

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

---

From: Peter Psenak <[email-masked]>
Date: Fri, 27 Mar 2020 09:11:15 +0100

Hi Dongjie,

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

my reading of RFC 5120 and the existing IANA registry is that it is 
legal to advertise TE attributes in MT TLVs:

It says "y" for all TE attributes. What else do you need?

> [Jie] My reading of the above text is that RFC 5120 leaves the specification of per-topology TE or other applications to a later document. And it is also related to my below comment which you misse…

my reading is different.

> [Jie] Maybe you could provide some information about the history of this IANA registry? It assumes all the TE attributes can be applied to both TLV 22 and TLV 222, which may not always be the case.

registry clearly tells.

> For example, if a L3 link has three L2 member links, which are associated with MT-x, MT-y and MT-z respectively, then the L3 link is associated with MT-x, MT-y and MT-z.

I'm going to repeat myself here. You are misusing the MT-ID for 
something you have defined. I don't think it is correct. L2  bundle link 
is NOT a topological entity in ISIS, only the L3 link is. Associating L2 
bundle link with a MT is conceptually wrong.

If you wanted different bundle members to be part of different 
topologies the obvious solution would be to enable L3 directly on the 
individual links rather than combine them into one L3 Bundle interface.

thanks,
Peter

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 27 Mar 2020 17:19:47 +0800

Joel,
Thank you for your comments.
From the pespective of an operator, new services need more support from underlay network, such as network resource and connection support. Considering the limition of MPLS-TE, we think that new mechanisms should be introduced into underlay network to meet the requirements of services.

Best regards
Chongfeng

中国电信股份有限公司研究院 
+86-10-50902116

From: Joel M. Halpern
Date: 2020-03-26 21:35
 
Yours,
Joel

---

From: John E Drake <[email-masked]>
Date: Fri, 27 Mar 2020 14:05:57 +0000

Aijun,

Any network slicing proposal is going to require active management of the underlay network in response to changes in the requirements of the overlay VPNs.  The text you quote is designed to address a different issue which none of the other network slicing proposals address, viz, in a heterogeneous mix of regular and enhanced VPNs, how do you ensure that regular VPNs, that know nothing about the enhanced VPNs, don’t use the resources that are supposed to be used only by enhanced VPNs?  See also:  https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-07.

Yours Irrespectively,

John

Juniper Business Use Only
From: Aijun Wang <[email-masked]>
Sent: Thursday, March 26, 2020 9:37 PM
To: John E Drake <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]; lsr <[email-masked]>
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

Hi, John:

On Mar 26, 2020, at 23:31, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>> wrote:
Hi,

Yours Irrespectively,

John

-----Original Message-----
From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: Thursday, March 26, 2020 9:36 AM
To: [email-masked]<mailto:[email-masked]>; lsr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based

Yours,
Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 27 Mar 2020 15:32:30 +0000

Hi Peter,

My question actually is: where does the TLV 222 column in the IANA registry come from? As it is not specified in the IANA section of RFC 5120. It would be helpful if you or anyone else could share some more information about this. If normative specification of using TE attributes in TLV 222 could be found in an RFC, we would add a reference to it and remove the editor's note in section 3.1 of this document.

And please see some further replies inline about the L2 bundle discussion.

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Friday, March 27, 2020 4:11 PM
To: Dongjie (Jimmy) <[email-masked]>; [email-masked]; lsr <[email-masked]>
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

Hi Dongjie,

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

my reading of RFC 5120 and the existing IANA registry is that it is legal to advertise TE attributes in MT TLVs:

>>> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepo
>>> i
>>> nts.xhtm

my reading is different.

registry clearly tells.

> For example, if a L3 link has three L2 member links, which are associated with MT-x, MT-y and MT-z respectively, then the L3 link is associated with MT-x, MT-y and MT-z.

I'm going to repeat myself here. You are misusing the MT-ID for something you have defined. I don't think it is correct. L2  bundle link is NOT a topological entity in ISIS, only the L3 link is. Associating L2 bundle link with a MT is conceptually wrong.

If you wanted different bundle members to be part of different topologies the obvious solution would be to enable L3 directly on the individual links rather than combine them into one L3 Bundle interface.

[Jie2] I agree the usage of MT-ID is extended in this case. But if an L3 parent link participates in multiple topologies, this could help to further identify the member link which is only used for traffic belonging to a specific topology. A similar attribute is the admin-group. 

[Jie2] Enabling L3 on each individual link is another option, while it introduces the overhead which the L2 bundle mechanism tries to avoid. 

[Jie2] BTW, in the IANA section of the L2 bundle RFC 8668, it clearly specifies which existing sub-TLVs are allowed in the newly defined TLV 25, and in which existing TLVs the new sub-TLVs can be carried. Something similar documented in an RFC for TLV 222 would be good enough to solve my question in the beginning of this mail.

Best regards,
Jie

thanks,
Peter

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Mar 2020 11:33:40 -0400

Chongfeng, it would be very helpful to see a draft that actually 
described the problems you need addressed.  I believe there are changes 
we need to make to improve things.e  But the current problem statement 
draft is so vague that it does not help me understand what problem you 
actually need to solve.  Which then leaves me unable to match the 
proposals in this draft to any specific needs.

Yours,
Joel

On 3/27/2020 5:19 AM, [email-masked] wrote:
>  From the pespective of an operator, new services need more support from 
> underlay network, such as network resource and connection support. 
> Considering the limition of MPLS-TE, we think that new mechanisms should 
> be introduced into underlay network to meet the requirements of services.
> 
> Best regards
> Chongfeng
> 
> ------------------------------------------------------------------------
> 中国电信股份有限公司研究院
> +86-10-50902116
> 
> 
>     *Date:* 2020-03-26 21:35
>      >      >
>      >      > Hello, folks,
>      >      >
>      >      > we have submitted a new draft of
>      >      > 
>      >      >
>      >      > 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
>      >      > [email-masked]
>      >      > https://www.ietf.org/mailman/listinfo/lsr
>      >      >

---

From: Peter Psenak <[email-masked]>
Date: Fri, 27 Mar 2020 16:44:56 +0100

Hi Dongjie,

> My question actually is: where does the TLV 222 column in the IANA registry come from? As it is not specified in the IANA section of RFC 5120. It would be helpful if you or anyone else could share…

I guess it came with RFC 5120.

> [Jie2] I agree the usage of MT-ID is extended in this case. But if an L3 parent link participates in multiple topologies, this could help to further identify the member link which is only used for…

no, I don't agree. You can only associate MT-ID with a L3 link, not with 
L2 link.

> [Jie2] Enabling L3 on each individual link is another option, while it introduces the overhead which the L2 bundle mechanism tries to avoid.

well, if you want to use L3 constructs like MT-ID, it comes with an 
overhead. I have expressed my concerns of the MT being used for what you 
are trying to use it for in the past - and overhead was the main issue.

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 27 Mar 2020 17:12:22 +0000

Jie -

The registry clearly indicates the set of specifications - and does so on a per sub-TLV basis - though not on a per column basis.
The registry is authoritative.

There is a bit of history here.

Prior to RFC7370 there wasn't a single registry for all the related TLVs. This became awkward to maintain, so RFC7370 combined the per TLV registries into a single registry for the set of Neighbor/Link related TLVs (22, 23, 25, 141, 222, and 223)) and similarly for the set of Prefix related TLVs (135, 235, 236, and 237).
It was because of RFC 7370 that the columns were introduced.

Now, are you claiming the registry is incorrect? If so, please explain why.
Otherwise, it seems to me that you are simply making trouble for yourself. 
Clearly the registry allows TE attribute sub-TLVs to be encoded in MT TLVs - and the text in RFC 5120 supports that. Whether there is a real deployment case for that is another matter.

   Les

> From: Lsr <[email-masked]> On Behalf Of Peter Psenak
> Sent: Friday, March 27, 2020 8:45 AM
> > My question actually is: where does the TLV 222 column in the IANA
> registry come from? As it is not specified in the IANA section of RFC 5120. It
> would be helpful if you or anyone else could share some more information
> about this. If normative specification of using TE attributes in TLV 222 could
> be found in an RFC, we would add a reference to it and remove the editor's
> note in section 3.1 of this document.
> 
> >>> 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.
> >
> > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-
> codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
> >
> lsr
> >>> “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.
> >>
> >> [Jie] My reading of the above text is that RFC 5120 leaves the specification
> of per-topology TE or other applications to a later document. And it is also
> related to my below comment which you missed.
> >
> > my reading is different.
> >
> >>
> >>> 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.
> >>
> >> [Jie] Maybe you could provide some information about the history of this
> IANA registry? It assumes all the TE attributes can be applied to both TLV 22
> and TLV 222, which may not always be the case.
> >
> > registry clearly tells.
> >
> >>
> >>> 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.
> >>
> >> For example, if a L3 link has three L2 member links, which are associated
> with MT-x, MT-y and MT-z respectively, then the L3 link is associated with
> MT-x, MT-y and MT-z.
> >
> > I'm going to repeat myself here. You are misusing the MT-ID for something
> you have defined. I don't think it is correct. L2  bundle link is NOT a topological
> entity in ISIS, only the L3 link is. Associating L2 bundle link with a MT is
> conceptually wrong.
> >
> > If you wanted different bundle members to be part of different topologies
> the obvious solution would be to enable L3 directly on the individual links
> rather than combine them into one L3 Bundle interface.
> >
> > [Jie2] I agree the usage of MT-ID is extended in this case. But if an L3 parent
> link participates in multiple topologies, this could help to further identify the
> member link which is only used for traffic belonging to a specific topology. A
> similar attribute is the admin-group.
> 
> > [Jie2] Enabling L3 on each individual link is another option, while it
> introduces the overhead which the L2 bundle mechanism tries to avoid.
> 
> > [Jie2] BTW, in the IANA section of the L2 bundle RFC 8668, it clearly
> specifies which existing sub-TLVs are allowed in the newly defined TLV 25,
> and in which existing TLVs the new sub-TLVs can be carried. Something
> similar documented in an RFC for TLV 222 would be good enough to solve my
> question in the beginning of this mail.
> >
> > Best regards,
> > Jie
> >
> >
> > thanks,
> > Peter
> >
> >
> >>
> >> Best regards,
> >> Jie
> >>
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Best regards,
> >>> Jie
> >>>
> >>>>
> >>>> thanks,
> >>>> Peter
> >>>>
> >>>>
> >>>>>

---

From: <[email-masked]>
Date: Sat, 28 Mar 2020 12:08:21 +0800 (CST)

Hi Peter, and other folks

This topic is very interesting. it happend that we also consider this topic in draft-peng-lsr-flex-algo-l2bundles-00, and draft-zch-lsr-isis-network-slicing-02.

I totally agree Peter that MT can not be used for L2 members. IMO, both Flex-algo and AII can be extended to address this topic, but MT not.

Thanks,

PSF

原始邮件

发件人：PeterPsenak <ppsenak=[email-masked]>
收件人：Dongjie (Jimmy) <[email-masked]>;[email-masked] <[email-masked]>;lsr <[email-masked]>;
日 期 ：2020年03月27日 23:45
主 题 ：Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

Hi Dongjie,

thanks,
Peter

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 28 Mar 2020 10:24:45 -0700

I'm surprised by where this discussion is heading, what prevents you from
sticking TLV25 into MT TLVs or actually aren't you contradicting existing
standards RFC?

First, an L2 link bundle (I assume we talk about 8668 here) is a L3 concept
in ISIS since you run an adjacency over it and obviously fwd' L3 frames.
MT is nothing else but associating a L3 adjacency with an MT so if you run
a normal adjacency over normal L2 bundle so you can an MT adjacency .

And funny enough rft8668 even says

The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222,
   and 223 has been changed to include sub-TLV 25.

Whether you use that for slicing is a different discussion, you are bound
by 12 bits worth of MTs as first observation. 2nd, it forces you on a very
orthogonal but hence very manageable ;-) architecture where both sides of
the interface must be configured for the things to associate. And you have
to repate prefixes per MT if you wnat them reachabl3e in multiple MTs if
that makes sense (i.e. you don't use MT to disassociate addressing but only
to manage link resources).

"Color";ing on the other hand does not seem to have much of an architecture
AFAIS but is rather like tag'ing keywords in a post, you hope you can make
some kind of algorithm deliver some kind of coherent forwarding behavior
(just like querying for some combinations/substring/presence/absence of
keywords in a query on bunch of "things"). While this is surely more
flexible in case you don't need all the flexiblity the manageability of the
whole things looks to me daunting.

A good analogy is MPLS vs SR here. If you wnat a nailed, guaranteed
end-2-end connectivity with clear OAM/resource allocation/behavior on
failures/topology changes MPLS is your friend, SR gives you arguably more
flexibility but the question where the traffic goes on changes, resource
allocation, stats, behavior on failures/changes is something that is far
more daunting to get a handle on.

my 2c

--  tony

On Fri, Mar 27, 2020 at 9:08 PM <[email-masked]> wrote:

> This topic is very interesting. it happend that we also consider this
> topic in draft-peng-lsr-flex-algo-l2bundles-00, and
> draft-zch-lsr-isis-network-slicing-02.
>
> I totally agree Peter that MT can not be used for L2 members. IMO, both
> Flex-algo and AII can be extended to address this topic, but MT not.
>
>
> Thanks,
>
> PSF
>
>
> 原始邮件
> *发件人：*PeterPsenak <ppsenak=[email-masked]>
> *收件人：*Dongjie (Jimmy) <[email-masked]>;[email-masked] <
> [email-masked]>;lsr <[email-masked]>;
> *日 期 ：*2020年03月27日 23:45
> *主 题 ：**Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing
> basedVirtual Transport Network*
> Hi Dongjie,
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 28 Mar 2020 22:40:20 +0000

Peng –

Thanx for calling attention to your relatively new draft.

The new sub-TLV you propose in https://tools.ietf.org/html/draft-peng-lsr-flex-algo-l2bundles-00#section-5.1 is unnecessary.
You seem to have misunderstood RFC 8668 and believe that it does not allow advertising link attributes which are potentially common to multiple bundle members but in a given deployment are actually unique to each bundle member.
This is incorrect.

Each L2 Bundle Attribute Descriptor defines the set of bundle members to which the following link attributes sub-TLVs apply. That set can be one bundle member – or it can be multiple bundle members.
In the case where you want to advertise unique EAG values for each bundle member you can do so by using L2 Bundle Attribute Descriptors which specify a single bundle member.

You may wish to study the Appendix in RFC 8668 which provides example encodings.

I appreciate that the encoding defined in RFC 8668 is more complex than most TLV encodings. It represents a tradeoff between encoding efficiency and complexity. We tried to reduce the cases where a link attribute common to multiple bundle members had to be advertised multiple times – but this did result in some additional complexity in the structure of the TLV. Given the IS-IS TLV length limitation of 255 octets and the possibility of bundles with a large number of members this was an important consideration.

   Les

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, March 27, 2020 9:08 PM
To: ppsenak=[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

Thanks,

PSF

原始邮件
发件人：PeterPsenak <ppsenak=[email-masked]<mailto:ppsenak=[email-masked]>>
收件人：Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;lsr <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年03月27日 23:45
主 题 ：Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi Dongjie,

please see more inline:

> To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; lsr <[email-masked]<mailto:[email-masked]>>
>> To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; lsr
>> <[email-masked]<mailto:[email-masked]>>
>>>> To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
>>>> lsr <[email-masked]<mailto:[email-masked]>>

thanks,
Peter

>>>>>> On 25/03/2020 14:44, [email-masked]<mailto:[email-masked]> wrote:
>>>>>>>
>>>>>>> Hello, folks,
>>>>>>>
>>>>>> [email-masked]<mailto:[email-masked]>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 28 Mar 2020 23:00:55 +0000

Tony –

There are a few misunderstandings in your post.
Let me try to correct them.

RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of TLVs 22,23,141,222,223.

Conceptually, it could have been defined as a sub-TLV, but because of the limited length of a TLV in IS-IS (255 octets) and the likelihood that advertising L2Bundle member attributes would consume a significant amount of space, we decided to use a new top-level TLV which references the associated L3 adjacency advertised in TLV 22. This means TLV22 advertisements are not impacted by the presence of TLV 25. In particular, the use of TLV 25 does not lead to multiple TLV 22 advertisements for the same adjacency, which we thought was a desirable outcome.

The equivalent OSPF draft (https://tools.ietf.org/html/draft-ketant-lsr-ospf-l2bundles-01 ) takes the sub-TLV approach, but since OSPF has a 16 bit length for TLVs it does not face the same encoding issues.

I fully agree with you that an L2 bundle is a Layer 3 construct – and as such can be associated with any Layer 3 MTID in theory. However, when writing RFC 8668 we did not consider that there was a use case for topology specific link attributes. The current encoding does not support MTID.
At this point, if we needed to extend RFC 8668 to support MTID we would need to allocate an additional TLV code point that included MTID – similar to the distinction between TLV 22 and TLV 222.

HTH

   Les

From: Lsr <[email-masked]> On Behalf Of Tony Przygienda
Sent: Saturday, March 28, 2020 10:25 AM
To: [email-masked]
Cc: [email-masked]; Dongjie (Jimmy) <[email-masked]>; ppsenak=[email-masked]; [email-masked]
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

I'm surprised by where this discussion is heading, what prevents you from sticking TLV25 into MT TLVs or actually aren't you contradicting existing standards RFC?

First, an L2 link bundle (I assume we talk about 8668 here) is a L3 concept in ISIS since you run an adjacency over it and obviously fwd' L3 frames.  MT is nothing else but associating a L3 adjacency with an MT so if you run a normal adjacency over normal L2 bundle so you can an MT adjacency ..

Whether you use that for slicing is a different discussion, you are bound by 12 bits worth of MTs as first observation. 2nd, it forces you on a very orthogonal but hence very manageable ;-) architecture where both sides of the interface must be configured for the things to associate. And you have to repate prefixes per MT if you wnat them reachabl3e in multiple MTs if that makes sense (i.e. you don't use MT to disassociate addressing but only to manage link resources).

"Color";ing on the other hand does not seem to have much of an architecture AFAIS but is rather like tag'ing keywords in a post, you hope you can make some kind of algorithm deliver some kind of coherent forwarding behavior (just like querying for some combinations/substring/presence/absence of keywords in a query on bunch of "things"). While this is surely more flexible in case you don't need all the flexiblity the manageability of the whole things looks to me daunting.

A good analogy is MPLS vs SR here. If you wnat a nailed, guaranteed end-2-end connectivity with clear OAM/resource allocation/behavior on failures/topology changes MPLS is your friend, SR gives you arguably more flexibility but the question where the traffic goes on changes, resource allocation, stats, behavior on failures/changes is something that is far more daunting to get a handle on.

my 2c

--  tony

On Fri, Mar 27, 2020 at 9:08 PM <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

PSF

原始邮件
发件人：PeterPsenak <ppsenak=[email-masked]<mailto:[email-masked]>>
收件人：Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;lsr <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年03月27日 23:45
主 题 ：Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi Dongjie,

please see more inline:

> From: Peter Psenak [mailto:[email-masked]<mailto:[email-masked]>]
> https://www..iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223>
>
>> From: Peter Psenak [mailto:[email-masked]<mailto:[email-masked]>]
>>>> From: Peter Psenak [mailto:[email-masked]<mailto:[email-masked]>]
>>>> other IS-IS extensions, e.g.. the extensions for TE, SR and L2 bundle.
>>>> https://www..iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepo<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepo>
>>>> i
>>>> nts.xhtm

thanks,
Peter

>>>>>> From: Lsr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Peter Psenak

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 28 Mar 2020 17:52:48 -0700

> RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of

ack, forgot how l2-bundle was working in detail and on quick re-reading the
language misled me since it talks about so many tlv & sub-tlv spaces. Ack,
25 is TLV. thanks for correction.

>
> Conceptually, it could have been defined as a sub-TLV, but because of the
> limited length of a TLV in IS-IS (255 octets) and the likelihood that
> advertising L2Bundle member attributes would consume a significant amount
> of space, we decided to use a new top-level TLV which references the
> associated L3 adjacency advertised in TLV 22. This means TLV22
> advertisements are not impacted by the presence of TLV 25. In particular,
> the use of TLV 25 does not lead to multiple TLV 22 advertisements for the
> same adjacency, which we thought was a desirable outcome.
>

ah, ok, now that makes sense, I didn't know the precise history here. To be
orthogonal to previous MT-ID designs we should have a 225 (that's not taken
AFAIR) with MTID just like we have a 222 for 22 ... not a large amount of
work.

>
>
> I fully agree with you that an L2 bundle is a Layer 3 construct – and as
> such can be associated with any Layer 3 MTID in theory. However, when
> writing RFC 8668 we did not consider that there was a use case for topology
> specific link attributes. The current encoding does not support MTID.
>
> At this point, if we needed to extend RFC 8668 to support MTID we would
> need to allocate an additional TLV code point that included MTID – similar
> to the distinction between TLV 22 and TLV 222.
>

ack, as I say 225 seems empty if need arises ;-)

thanks for keeping me honest as usual ;-)

--- tony

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 28 Mar 2020 17:56:00 -0700

Still, taht reads utterly inconsistent to me ?

This document adds the following new TLV to the IS-IS "TLV Codepoints
   Registry".

   Value:  25

   Name:  L2 Bundle Member Attributes

   *The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222,
   and 223 has been changed to include sub-TLV 25.*

On Sat, Mar 28, 2020 at 5:52 PM Tony Przygienda <[email-masked]> wrote:

>
>
> On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
>> Tony –
>>
>>
>>
> ack, forgot how l2-bundle was working in detail and on quick re-reading
> the language misled me since it talks about so many tlv & sub-tlv spaces.
> Ack, 25 is TLV. thanks for correction.
>
>
>>
> ah, ok, now that makes sense, I didn't know the precise history here. To
> be orthogonal to previous MT-ID designs we should have a 225 (that's not
> taken AFAIR) with MTID just like we have a 222 for 22 ... not a large
> amount of work.
>
>
>>
>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 29 Mar 2020 06:40:43 +0000

Tony –

By having the new TLV 25 share the same set of sub-TLV codepoints with TLVs 22 etc., we did not have to define new sub-TLVs in order to advertise the link attributes (bandwidth, affinity, etc.) in TLV 25.

The only relationship between TLV 25 and TLV 22 lies in the “Parent L3 Neighbor Descriptor” – which includes the system-id/pseudo-node ID of the neighbor and (in the case of parallel links to the same neighbor) link endpoint identifiers.

   Les

From: Tony Przygienda <[email-masked]>
Sent: Saturday, March 28, 2020 5:56 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked]; Dongjie (Jimmy) <[email-masked]>; ppsenak=[email-masked]; [email-masked]
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

   Registry".

   Value:  25

On Sat, Mar 28, 2020 at 5:52 PM Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Tony –

ack, forgot how l2-bundle was working in detail and on quick re-reading the language misled me since it talks about so many tlv & sub-tlv spaces. Ack, 25 is TLV. thanks for correction.

ah, ok, now that makes sense, I didn't know the precise history here. To be orthogonal to previous MT-ID designs we should have a 225 (that's not taken AFAIR) with MTID just like we have a 222 for 22 ... not a large amount of work.

--- tony

---

From: Peter Psenak <[email-masked]>
Date: Sun, 29 Mar 2020 11:09:49 +0200

Hi Les,

On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote:
> Conceptually, it could have been defined as a sub-TLV, but because of 
> the limited length of a TLV in IS-IS (255 octets) and the likelihood 
> that advertising L2Bundle member attributes would consume a significant 
> amount of space, we decided to use a new top-level TLV which references 
> the associated L3 adjacency advertised in TLV 22. This means TLV22 
> advertisements are not impacted by the presence of TLV 25. In 
> particular, the use of TLV 25 does not lead to multiple TLV 22 
> advertisements for the same adjacency, which we thought was a desirable 
> outcome.
> 
> The equivalent OSPF draft 
> (https://tools.ietf.org/html/draft-ketant-lsr-ospf-l2bundles-01 ) takes 
> the sub-TLV approach, but since OSPF has a 16 bit length for TLVs it 
> does not face the same encoding issues.
> 
> writing RFC 8668 we did not consider that there was a use case for 
> topology specific link attributes. The current encoding does not support 
> MTID.

RFC 8668 defines a TLV to advertise attributes of the individual L2 link 
members. While the TLV itself can be considered as L3 construct (and 
have MT associated with it), the individual L2 Bundle Member Links 
inside this TLV are not L3 constructs IMHO and should never have a MTID 
associated with them. The ask here is to advertise different MTID for 
each individual L2 bundle member link.

MTID is used to construct a topology. I do not see how a L2 bundle link 
member would ever become part of the L3 topology.

my 2c,
Peter

> need to allocate an additional TLV code point that included MTID – 
> similar to the distinction between TLV 22 and TLV 222.
> 
> HTH
> 
>     Les
> 
> *From:* Lsr <[email-masked]> *On Behalf Of * Tony Przygienda
> *Sent:* Saturday, March 28, 2020 10:25 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; Dongjie (Jimmy) <[email-masked]>; 
> ppsenak=[email-masked]; [email-masked]
> *Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing 
> basedVirtual Transport Network
> 
> I'm surprised by where this discussion is heading, what prevents you 
> from sticking TLV25 into MT TLVs or actually aren't you contradicting 
> existing standards RFC?
> 
> First, an L2 link bundle (I assume we talk about 8668 here) is a L3 
> concept in ISIS since you run an adjacency over it and obviously fwd' L3 
> frames.  MT is nothing else but associating a L3 adjacency with an MT so 
> if you run a normal adjacency over normal L2 bundle so you can an MT 
> adjacency ..
> 
> Whether you use that for slicing is a different discussion, you are 
> bound by 12 bits worth of MTs as first observation. 2nd, it forces you 
> on a very orthogonal but hence very manageable ;-) architecture where 
> both sides of the interface must be configured for the things to 
> associate. And you have to repate prefixes per MT if you wnat them 
> reachabl3e in multiple MTs if that makes sense (i.e. you don't use MT to 
> disassociate addressing but only to manage link resources).
> 
> "Color";ing on the other hand does not seem to have much of an 
> architecture AFAIS but is rather like tag'ing keywords in a post, you 
> hope you can make some kind of algorithm deliver some kind of coherent 
> forwarding behavior (just like querying for some 
> combinations/substring/presence/absence of keywords in a query on bunch 
> of "things"). While this is surely more flexible in case you don't need 
> all the flexiblity the manageability of the whole things looks to me 
> daunting.
> 
> failures/topology changes MPLS is your friend, SR gives you arguably 
> more flexibility but the question where the traffic goes on changes, 
> resource allocation, stats, behavior on failures/changes is something 
> that is far more daunting to get a handle on.
> 
> my 2c
> 
> --  tony
> 
>     This topic is very interesting. it happend that we also consider
>     this topic in draft-peng-lsr-flex-algo-l2bundles-00, and
>     I totally agree Peter that MT can not be used for L2 members. IMO,
>     both Flex-algo and AII can be extended to address this topic, but MT
>     not.
> 
>     Thanks,
> 
>     PSF
> 
>     原始邮件
> 
>     *发件人：*PeterPsenak <ppsenak=[email-masked]
>     <mailto:[email-masked]>>
> 
>     *收件人：*Dongjie (Jimmy) <[email-masked]
>     <mailto:[email-masked]>>;[email-masked]
>     <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>;lsr <[email-masked]
>     <mailto:[email-masked]>>;
> 
>     *日****期****：*2020年03月27日23:45
> 
>     *主****题****：**Re: [Lsr] Using IS-IS Multi-Topology (MT) for
>     Segment Routing basedVirtual Transport Network*
> 
>     Hi Dongjie,
> 
>      > To: Dongjie (Jimmy) <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; lsr <[email-masked]
>     <mailto:[email-masked]>>
>     https://www..iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
>     <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223>
>      >
>      >> To: Dongjie (Jimmy) <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; lsr
>      >> <[email-masked] <mailto:[email-masked]>>
>      >>>> To: Dongjie (Jimmy) <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>;
>      >>>> lsr <[email-masked] <mailto:[email-masked]>>
>     https://www..iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepo <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepo>
>      >>>> i
>      >>>> nts.xhtm
>      >>>>>> From: Lsr [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Peter Psenak
>      >>>>>> To: [email-masked]
>     <mailto:[email-masked]>; lsr <[email-masked]
>     <mailto:[email-masked]>>
>      >>>>>> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Aijun Wang <[email-masked]>
Date: Sun, 29 Mar 2020 18:46:00 +0800

I have the same consideration as Peter.

Aijun Wang
China Telecom

> On Mar 29, 2020, at 17:10, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Hi Les,
> 
> RFC 8668 defines a TLV to advertise attributes of the individual L2 link members. While the TLV itself can be considered as L3 construct (and have MT associated with it), the individual L2 Bundle Member Links inside this TLV are not L3 constructs IMHO and should never have a MTID associated with them. The ask here is to advertise different MTID for each individual L2 bundle member link.
> 
> MTID is used to construct a topology. I do not see how a L2 bundle link member would ever become part of the L3 topology.
> 
> my 2c,
> Peter
> 
> 
>> *To:* peng.shaofu@

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 29 Mar 2020 15:57:08 +0000

Peter/Aijun -

We are in agreement.
I never said that an L2 Bundle member could/should be associated with a specific MTID.

It is the L3 adjacency that has the MTID association.
If we were going to support MTID in TLV 25 the correct place to put it would be as part of the " Parent L3 Neighbor Descriptor".

   Les

> From: Lsr <[email-masked]> On Behalf Of Aijun Wang
> Sent: Sunday, March 29, 2020 3:46 AM
> To: Peter Psenak <ppsenak=[email-masked]>
> Cc: [email-masked]; Dongjie (Jimmy) <[email-masked]>;
> [email-masked]; Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]>; [email-masked]; Tony Przygienda
> <[email-masked]>
> > On Mar 29, 2020, at 17:10, Peter Psenak
> <ppsenak=[email-masked]> wrote:
> >
> > Hi Les,
> >
> limited length of a TLV in IS-IS (255 octets) and the likelihood that advertising
> L2Bundle member attributes would consume a significant amount of space,
> we decided to use a new top-level TLV which references the associated L3
> adjacency advertised in TLV 22. This means TLV22 advertisements are not
> impacted by the presence of TLV 25. In particular, the use of TLV 25 does not
> lead to multiple TLV 22 advertisements for the same adjacency, which we
> thought was a desirable outcome.
> >> The equivalent OSPF draft (https://tools.ietf.org/html/draft-ketant-lsr-
> ospf-l2bundles-01 ) takes the sub-TLV approach, but since OSPF has a 16 bit
> length for TLVs it does not face the same encoding issues.
> >> I fully agree with you that an L2 bundle is a Layer 3 construct – and as such
> can be associated with any Layer 3 MTID in theory. However, when writing
> RFC 8668 we did not consider that there was a use case for topology specific
> link attributes. The current encoding does not support MTID.
> >
> members. While the TLV itself can be considered as L3 construct (and have
> MT associated with it), the individual L2 Bundle Member Links inside this TLV
> are not L3 constructs IMHO and should never have a MTID associated with
> them. The ask here is to advertise different MTID for each individual L2
> bundle member link.
> >
> need to allocate an additional TLV code point that included MTID – similar to
> the distinction between TLV 22 and TLV 222.
> >> HTH
> >>    Les

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 29 Mar 2020 09:28:46 -0700

As usual +1 Les

Simply think what is the _L3 construct_ ISIS runs over which is easily
identified as the same thing that adjacency runs over. If adjacency runs
over each constituent of L2 bundel we don't have L2, we have L3 with
confused naming. If adjacency runs over the L2 bundle the bundle is an L3
construct and hence MTID applies

again, to keep things orthogonal (mostly on the encoding side but also
underlying architecture)  I would derive 225 the same way we run 222.
Otherwise we end up in funky places like "what happens if this bundle has
more than one MTID and if it runs on no MT and a MTID" as well and what
does it mean if it's missing and what if someone doesn't understand it and
so on and so on. That stuff has been pretty well reviewed and thought out
when it was done and all the tlv/subtlv discussions had then ...

--- tony

On Sun, Mar 29, 2020 at 8:57 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> If we were going to support MTID in TLV 25 the correct place to put it
> would be as part of the " Parent L3 Neighbor Descriptor".
>
>    Les
>
>
> > >> RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic)
> of
> > TLVs 22,23,141,222,223.
> the
> advertising
> > >> The equivalent OSPF draft (
> https://tools.ietf.org/html/draft-ketant-lsr-
> similar to

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 29 Mar 2020 17:13:11 -0400

Hi Chongfeng & Jie

I read through this draft which is referenced in the MT draft which is a
good to read first to provide context as to what you are trying to
accomplish with VPN+ idea.

https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05

In reading both documents the basic concept at a high level is that you are
trying to provide a means of pinning overlay vpn service to underlay
transport providing a form of isolation abstraction.

>From a Spring Source routing standpoint source routing provided by segment
routing flavors SR-MPLS and SRv6 provides the same vpn coloring and source
routed traffic engineering via SR-TE for SR-MPLS and SRv6 native L3 vpn
coloring with SRH traffic steering.

So that coupling for IP SLA requirement of underlay pinning to overlay vpn
via traffic steering coloring via candidate ERO paths to me seems to be
satisfied by Segment Routing flavors.

Am I missing something?

Kind regards

Gyan

https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05

On Sun, Mar 29, 2020 at 12:30 PM Tony Przygienda <[email-masked]>
wrote:

> On Sun, Mar 29, 2020 at 8:57 AM Les Ginsberg (ginsberg) <
>> > Cc: [email-masked]; Dongjie (Jimmy) <[email-masked]
>> <jie.dong@huawei..com>>;
>> > >> RFC 8668 defines a new top-level TLV (25). This is NOT a
>> sub-TLV(sic) of
>> > TLVs 22,23,141,222,223.
>> have
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 29 Mar 2020 21:00:38 -0400

Hi Chongfeng & Jie

Have you looked at the preferred path routing draft by Uma Chunduri.  This
is also Isis extensions for IP based SR source routing.

Maybe something that can be leveraged for VPN+

https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00

Also this TEAS draft related to using the RSVP extensions for IP based
source routing for SR.

This may help in having to develop new extensions for VPN+

https://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00

Kind regards

Gyan

On Sun, Mar 29, 2020 at 5:13 PM Gyan Mishra <[email-masked]> wrote:

> In reading both documents the basic concept at a high level is that you
> are trying to provide a means of pinning overlay vpn service to underlay

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: <[email-masked]>
Date: Mon, 30 Mar 2020 10:17:28 +0800 (CST)

Hi Les,

Thanks for your reply and detailed explanation. 

Yes, I really misunderstood the l2bundles encoding rules. Appendix A is very clear to answer my questions. : )

So, for slicing requirements, I think existing flex-algo using EAG for isolation can support the case where multiple hard isolated L2 Flex-E members join to the same L3 parrent adjacency, and each L2 member can belongs to differnet Flex-algo plane.

Thanks,

PSF

原始邮件

发件人：LesGinsberg(ginsberg) <[email-masked]>
收件人：彭少富10053815;ppsenak=[email-masked] <ppsenak=[email-masked]>;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年03月29日 06:40
主 题 ：RE: [Lsr]  Using IS-IS Multi-Topology (MT) for Segment RoutingbasedVirtual Transport Network

Peng –

 

This is incorrect.

 

 

I appreciate that the encoding defined in RFC 8668 is more complex than most TLV encodings. It represents a tradeoff between encoding efficiency and complexity. We tried to reduce the cases where a link attribute common to multiple bundle
 members had to be advertised multiple times – but this did result in some additional complexity in the structure of the TLV. Given the IS-IS TLV length limitation of 255 octets and the possibility of bundles with a large number of members this was an important
 consideration.

   Les

 

Thanks,

PSF

原始邮件

收件人：Dongjie (Jimmy) <[email-masked]>;[email-masked]
 <[email-masked]>;lsr <[email-masked]>;

日期：2020年03月27日
 23:45

主题：Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

Hi Dongjie,

thanks,
Peter

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 30 Mar 2020 03:13:51 +0000

Hi Peter, 

Thanks for your reply, please see inline with [Jie 3]:

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Friday, March 27, 2020 11:45 PM
To: Dongjie (Jimmy) <[email-masked]>; [email-masked]; lsr <[email-masked]>
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Jie 3]: Thanks, I saw Les provides some background about this. I will reply to his mail about this part.

Some previous discussion are trimmed off...

[Jie 3]: The MT-IDs are still associated with the L3 link, the purpose here is to further associate each topology with a subset of resource of the L3 link. IGP L2bundle is something near to what we need, the bundle member link could be used to represent a subset of the resource of the L3 link. This may require some extension or generalization to L2bundle, which is described in draft-dong-lsr-sr-enhanced-vpn-03 and draft-zhu-lsr-sr-vtn-flexalgo.

> [Jie2] Enabling L3 on each individual link is another option, while it introduces the overhead which the L2 bundle mechanism tries to avoid.

well, if you want to use L3 constructs like MT-ID, it comes with an overhead. I have expressed my concerns of the MT being used for what you are trying to use it for in the past - and overhead was the main issue.

[Jie 3]: Since multiple topologies can be enabled on the same L3 link, it is possible to reduce the overhead of multiple L3 connections. Following this, what we need IMO is to find a suitable approach to advertise topology-specific TE attributes for such a link.

Best regards,
Jie

thanks,
Peter

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 30 Mar 2020 04:57:07 +0000

Hi Les, 

Many thanks for providing the history about this IANA registry. The approach in RFC 7370 is reasonable, while in general it would be more useful if a reference is also provided for each column, so as to indicate in which document the allowed combination of the sub-TLVs and each TLV is specified. As some sub-TLVs may be defined earlier than a relatively new TLV, the reference to a sub-TLV does not really cover their combination.

I agree that the registry shows the TE attribute sub-TLVs are allowed in MT-ISN TLV 222, this is good. Then the question left is: is there a need to specify how to advertise topology-specific TE attributes, especially when one link participates in multiple topologies? AFAIK this is not described in RFC 5120, nor RFC 5305. 

Best regards,
Jie

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Saturday, March 28, 2020 1:12 AM
To: Peter Psenak <ppsenak=[email-masked]>; Dongjie (Jimmy) <[email-masked]>; [email-masked]; lsr <[email-masked]>
Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

Jie -

   Les

> registry come from? As it is not specified in the IANA section of RFC 
> 5120. It would be helpful if you or anyone else could share some more 
> information about this. If normative specification of using TE 
> attributes in TLV 222 could be found in an RFC, we would add a 
> reference to it and remove the editor's note in section 3.1 of this document.
> 
> >> You missed some of my comments in previous mail, could you also 
> >> reply
> to this?
> >>
> 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.
> >
> >>>> 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.
> attributes already defined for the "standard" topology without going 
> through long standard process to redefine them per topology.”
> >>>
> of per-topology TE or other applications to a later document. And it 
> is also related to my below comment which you missed.
> >
> > my reading is different.
> >
> >>
> 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.
> >>
> IANA registry? It assumes all the TE attributes can be applied to both 
> TLV 22 and TLV 222, which may not always be the case.
> >
> > registry clearly tells.
> >
> >>
> >>>> 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.
> >>>
> 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.
> >>
> >> [Jie] In this case, the L3 link is associated with the union of the 
> >> MT-IDs
> associated with its L2 member links.
> >>
> with MT-x, MT-y and MT-z respectively, then the L3 link is associated 
> with MT-x, MT-y and MT-z.
> >
> > something
> you have defined. I don't think it is correct. L2  bundle link is NOT 
> a topological entity in ISIS, only the L3 link is. Associating L2 
> > topologies
> the obvious solution would be to enable L3 directly on the individual 
> links rather than combine them into one L3 Bundle interface.
> >
> link participates in multiple topologies, this could help to further 
> identify the member link which is only used for traffic belonging to a 
> specific topology. A similar attribute is the admin-group.
> 
> overhead. I have expressed my concerns of the MT being used for what 
> you are trying to use it for in the past - and overhead was the main issue.
> 
> thanks,
> Peter
> 
> >
> specifies which existing sub-TLVs are allowed in the newly defined TLV 
> 25, and in which existing TLVs the new sub-TLVs can be carried. 
> Something similar documented in an RFC for TLV 222 would be good 
> enough to solve my question in the beginning of this mail.
> >
> > Best regards,
> > Jie
> >
> >
> > thanks,
> > Peter
> >
> >
> >>
> >> Best regards,
> >> Jie
> >>
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Best regards,
> >>> Jie
> >>>
> >>>>
> >>>> thanks,
> >>>> Peter
> >>>>
> >>>>
> >>>>>
> >>>>>>> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 30 Mar 2020 07:05:33 +0000

Jie -

The format of the TE-attribute sub-TLVs is defined and does not change based upon the TLV in which it is advertised. So I do not see that any additional specification is required.

In rereading draft-dong-lsr-sr-enhanced-vpn, I am wondering what is the scope you desire for link attributes?

You have defined that a given "L2 virtual link" can be associated with:

a)Multiple topologies
b)Multiple VTNs
c)Each VTN can be associated with a different Flex-algorithm

Is the scope of the link attribute advertisement per topology?
Or per topology+(set of) VTNs?

In other words, it is clear that you want to advertise different link attributes for the same link in different MTIDs.
But do you also want to advertise different link attributes for the same link/MTID in different VTNs?

   Les

> From: Dongjie (Jimmy) <[email-masked]>
> Sent: Sunday, March 29, 2020 9:57 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>; Peter Psenak
> <ppsenak=[email-masked]>; [email-masked]; lsr
> <[email-masked]>
> Many thanks for providing the history about this IANA registry. The approach
> in RFC 7370 is reasonable, while in general it would be more useful if a
> reference is also provided for each column, so as to indicate in which
> document the allowed combination of the sub-TLVs and each TLV is
> specified. As some sub-TLVs may be defined earlier than a relatively new
> TLV, the reference to a sub-TLV does not really cover their combination.
> 
> I agree that the registry shows the TE attribute sub-TLVs are allowed in MT-
> ISN TLV 222, this is good. Then the question left is: is there a need to specify
> how to advertise topology-specific TE attributes, especially when one link
> participates in multiple topologies? AFAIK this is not described in RFC 5120,
> nor RFC 5305.
> 
> Best regards,
> Jie
> 
> 
> To: Peter Psenak <ppsenak=[email-masked]>; Dongjie (Jimmy)
> <[email-masked]>; [email-masked]; lsr <[email-masked]>
> The registry clearly indicates the set of specifications - and does so on a per
> sub-TLV basis - though not on a per column basis.
> Prior to RFC7370 there wasn't a single registry for all the related TLVs. This
> became awkward to maintain, so RFC7370 combined the per TLV registries
> into a single registry for the set of Neighbor/Link related TLVs (22, 23, 25, 141,
> 222, and 223)) and similarly for the set of Prefix related TLVs (135, 235, 236,
> and 237).
> Clearly the registry allows TE attribute sub-TLVs to be encoded in MT TLVs -
> and the text in RFC 5120 supports that. Whether there is a real deployment
> case for that is another matter.
> 
>    Les
> 
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 30 Mar 2020 10:43:17 +0200

Hi Les,

> I never said that an L2 Bundle member could/should be associated with a specific MTID.

ok, but that is what the authors of the draft-xie-lsr-isis-sr-vtn-mt are 
proposing. That's the reason why I was opposing that idea.
> If we were going to support MTID in TLV 25 the correct place to put it would be as part of the " Parent L3 Neighbor Descriptor".

sure, although it looks redundant to me, given that the same L3 link is 
already advertised in other TLV which can have MTID in it.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Mon, 30 Mar 2020 11:05:27 +0200

Hi Dongjie,

> [Jie 3]: The MT-IDs are still associated with the L3 link, the purpose here is to further associate each topology with a subset of resource of the L3 link. IGP L2bundle is something near to what we…

sure, but MT is not the right mechanism.

> [Jie 3]: Since multiple topologies can be enabled on the same L3 link, it is possible to reduce the overhead of multiple L3 connections. Following this, what we need IMO is to find a suitable appro…

as has been said multiple times, you can advertise TE attributes with L2 
bundle member and no specification is required for that.

thanks,
Peter

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 30 Mar 2020 10:04:10 +0000

Hi Les,

Thanks for your review and comments.

Please see my replies inline with [Jie]:

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Monday, March 30, 2020 3:06 PM
To: Dongjie (Jimmy) <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; [email-masked]; lsr <[email-masked]>
Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

Jie -

[Jie] I agree that the format of the TLVs could be reused. While some explanation about the meaning of topology-specific attributes may need to be added. 

[Jie] For example, if one 10G link participates in 3 topologies, how should the per-topology max-link-bandwidth be advertised? One option is to advertise 10G for each topology, another option is to advertise 2G, 3G, 5G for the three topologies respectively. Both options may be allowed depending on the use cases. The consideration for other TE attributes may be similar or different.

a)Multiple topologies
b)Multiple VTNs

[Jie] In draft-dong-lsr-sr-enhanced-vpn, as it introduces the VTN-ID TLV, each "L2 virtual link" is associated with one or multiple VTNs using the VTN-ID TLV, and MT-ID is not used for the virtual member link association.

[Jie] This is one of the objectives of draft-xie-lsr-sr-vtn-mt.

[Jie] This is something we want to achieve with draft-dong-lsr-sr-enhanced-vpn.

Best regards,
Jie

   Les

> Many thanks for providing the history about this IANA registry. The 
> approach in RFC 7370 is reasonable, while in general it would be more 
> useful if a reference is also provided for each column, so as to 
> indicate in which document the allowed combination of the sub-TLVs and 
> each TLV is specified. As some sub-TLVs may be defined earlier than a 
> relatively new TLV, the reference to a sub-TLV does not really cover their combination.
> 
> I agree that the registry shows the TE attribute sub-TLVs are allowed 
> in MT- ISN TLV 222, this is good. Then the question left is: is there 
> a need to specify how to advertise topology-specific TE attributes, 
> especially when one link participates in multiple topologies? AFAIK 
> this is not described in RFC 5120, nor RFC 5305.
> 
> Best regards,
> Jie
> 
> 
> The registry clearly indicates the set of specifications - and does so 
> on a per sub-TLV basis - though not on a per column basis.
> Prior to RFC7370 there wasn't a single registry for all the related 
> TLVs. This became awkward to maintain, so RFC7370 combined the per TLV 
> registries into a single registry for the set of Neighbor/Link related 
> TLVs (22, 23, 25, 141, 222, and 223)) and similarly for the set of 
> Prefix related TLVs (135, 235, 236, and 237).
> Clearly the registry allows TE attribute sub-TLVs to be encoded in MT 
> TLVs - and the text in RFC 5120 supports that. Whether there is a real 
> deployment case for that is another matter.
> 
>    Les
> 
> 
> > registry come from? As it is not specified in the IANA section of 
> > RFC 5120. It would be helpful if you or anyone else could share some 
> > more information about this. If normative specification of using TE 
> > 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.
> > >
> > > my reading of RFC 5120 and the existing IANA registry is that it 
> > > is legal to
> > advertise TE attributes in MT TLVs:
> > >
> > >>>> Multi-Topology with other IS-IS extensions, e.g. the extensions 
> > >>>> for
> TE, SR and L2 bundle.
> > >>>> 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-c
> > >>>> od
> > >>>> epo
> > >>>> i
> > >>>> nts.xhtm
> > 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.”
> > >>>
> > 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.
> > >>
> > IANA registry? It assumes all the TE attributes can be applied to 
> > both TLV 22 and TLV 222, which may not always be the case.
> > >
> > > registry clearly tells.
> > >
> > >>
> > >>>> 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.
> > >>>
> > 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.
> > >> [Jie] In this case, the L3 link is associated with the union of 
> > >> the MT-IDs
> > with MT-x, MT-y and MT-z respectively, then the L3 link is 
> > associated with MT-x, MT-y and MT-z.
> > >
> > you have defined. I don't think it is correct. L2  bundle link is 
> > NOT a topological entity in ISIS, only the L3 link is. Associating 
> > L2 bundle link with a MT is conceptually wrong.
> > >
> > the obvious solution would be to enable L3 directly on the 
> > identify the member link which is only used for traffic belonging to 
> > a specific topology. A similar attribute is the admin-group.
> >
> > specifies which existing sub-TLVs are allowed in the newly defined 
> > TLV 25, and in which existing TLVs the new sub-TLVs can be carried.
> > >>>>>> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for 
> > >>>>>> Segment Routing based Virtual Transport Network
> > >>>>>>
> > >>>>>> Hi Chongfeng,
> > >>>>>>
> > >>>>>>> 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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 30 Mar 2020 10:08:51 +0000

Hi Tony,

My current understanding is TLV 25 could reference the associated L3 link advertised in either TLV 22 or 222.

With your proposal of keeping things orthogonal, does it mean that TLV 25 would only be used to advertise the member link attributes of the associated L3 link in TLV 22, and a new TLV 225 needs to be defined for advertising member link attributes of the associated L3 link in corresponding TLV 222?  Then if an L3 link is advertised with multiple TLV 222 for different topologies, does its member link attributes also need be advertised multiple times in multiple TLV 225?

Best regards,
Jie

From: Tony Przygienda [mailto:[email-masked]]
Sent: Monday, March 30, 2020 12:29 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; [email-masked]; Dongjie (Jimmy) <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

As usual +1 Les

Simply think what is the _L3 construct_ ISIS runs over which is easily identified as the same thing that adjacency runs over. If adjacency runs over each constituent of L2 bundel we don't have L2, we have L3 with confused naming. If adjacency runs over the L2 bundle the bundle is an L3 construct and hence MTID applies

again, to keep things orthogonal (mostly on the encoding side but also underlying architecture)  I would derive 225 the same way we run 222. Otherwise we end up in funky places like "what happens if this bundle has more than one MTID and if it runs on no MT and a MTID" as well and what does it mean if it's missing and what if someone doesn't understand it and so on and so on. That stuff has been pretty well reviewed and thought out when it was done and all the tlv/subtlv discussions had then ...

--- tony

On Sun, Mar 29, 2020 at 8:57 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Peter/Aijun -

We are in agreement.

   Les

> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Aijun Wang
> To: Peter Psenak <ppsenak=[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tony Przygienda
> <[email-masked]<mailto:[email-masked]>>
> <ppsenak=[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi Les,
> >
> >> *From:* Lsr <[email-masked]<mailto:[email-masked]>> *On Behalf Of * Tony Przygienda
> >> *To:* peng.shaofu@<mailto:peng.shaofu@>
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Mar 2020 12:20:43 +0200

Hi,

Out of pure curiosity here - how are you going to stop any other traffic
(SR or non SR) to take as much as it likes of any link being part of the
default topology ?

Thx,
R.

---

From: <[email-masked]>
Date: Mon, 30 Mar 2020 20:55:09 +0800 (CST)

Hi Tony,

Thank you for sharing your opinion.

I found there are so many discussion later, so I think in fact our opinion are consistent. : )

What I wanted to say before is that L2-member can not configure MT-ID, not say L2-bundle (it is a L3 interface) itself. 

According to Les pointing out, I think that unique EAG for each bundle member let Flex-algo already fulfill this requirements. However, if we can accept to introduce Slice-ID to underlay network, maybe the solution described in https://datatracker.ietf.org/doc/draft-zch-lsr-isis-network-slicing/ is another method.

Thanks,

PSF

原始邮件

发件人：TonyPrzygienda <[email-masked]>
收件人：彭少富10053815;
抄送人：ppsenak=[email-masked] <ppsenak=[email-masked]>;[email-masked] <[email-masked]>;Dongjie (Jimmy) <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年03月29日 01:26
主 题 ：Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment RoutingbasedVirtual Transport Network

First, an L2 link bundle (I assume we talk about 8668 here) is a L3 concept in ISIS since you run an adjacency over it and obviously fwd' L3 frames.  MT is nothing else but associating a L3 adjacency with an MT so if you run a normal adjacency over normal L2 bundle so you can an MT adjacency .

my 2c

--  tony 

Thanks,

PSF

原始邮件

Hi Dongjie,

thanks,
Peter

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 30 Mar 2020 16:02:56 +0000

Hi Robert,

Good question. In short you may need some mechanism in the forwarding plane to isolate the traffic in the default topology from the traffic in other topologies. Some of the candidate technologies are described in draft-ietf-teas-enhanced-vpn.

Best regards,
Jie

From: Robert Raszuk [mailto:[email-masked]]
Sent: Monday, March 30, 2020 6:21 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: [email-masked]; Aijun Wang <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

Hi,

Out of pure curiosity here - how are you going to stop any other traffic (SR or non SR) to take as much as it likes of any link being part of the default topology ?

Thx,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 30 Mar 2020 16:16:37 +0000

Jie -

Inline.

> Sent: Monday, March 30, 2020 3:04 AM
> To: Dongjie (Jimmy) <[email-masked]>; Peter Psenak
> The format of the TE-attribute sub-TLVs is defined and does not change
> based upon the TLV in which it is advertised. So I do not see that any
> additional specification is required.
> 
> [Jie] I agree that the format of the TLVs could be reused. While some
> explanation about the meaning of topology-specific attributes may need to
> be added.
> 
> [Jie] For example, if one 10G link participates in 3 topologies, how should the
> per-topology max-link-bandwidth be advertised? One option is to advertise
> 10G for each topology, another option is to advertise 2G, 3G, 5G for the
> three topologies respectively. Both options may be allowed depending on
> the use cases. The consideration for other TE attributes may be similar or
> different.
> 
[Les:] Well, this has nothing to do with the encoding. This has to do with use case - which is what you are defining.
So this is actually your responsibility to specify since you are proposing to advertise topology specific link attributes.

Note that max-link bandwidth is actually one of the easier attributes to share.

😊

   Les

> [Jie] In draft-dong-lsr-sr-enhanced-vpn, as it introduces the VTN-ID TLV, each
> "L2 virtual link" is associated with one or multiple VTNs using the VTN-ID TLV,
> and MT-ID is not used for the virtual member link association.
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 31 Mar 2020 15:38:27 +0000

Hi Les,

Please see my reply inline:

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Tuesday, March 31, 2020 12:17 AM
To: Dongjie (Jimmy) <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; [email-masked]; lsr <[email-masked]>
Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

Jie -

Inline.

> explanation about the meaning of topology-specific attributes may need 
> to be added.
> 
> [Jie] For example, if one 10G link participates in 3 topologies, how 
> should the per-topology max-link-bandwidth be advertised? One option 
> is to advertise 10G for each topology, another option is to advertise 
> 2G, 3G, 5G for the three topologies respectively. Both options may be 
> allowed depending on the use cases. The consideration for other TE 
> attributes may be similar or different.
> 

[Jie] I agree that the encoding could be reused, it seems you also agree that the usage of existing TLVs for topology-specific link attributes in specific use case needs to be specified.

[Jie] Yes, thus IMO the usage of TE attributes in MT related scenarios may need to be specified case by case.

Best regards,
Jie

😊

   Les

> In rereading draft-dong-lsr-sr-enhanced-vpn, I am wondering what is 
> the scope you desire for link attributes?
> 
> "L2 virtual link" is associated with one or multiple VTNs using the 
> VTN-ID TLV, and MT-ID is not used for the virtual member link association.
> 
> In other words, it is clear that you want to advertise different link 
> attributes for the same link in different MTIDs.
> 
> [Jie] This is something we want to achieve with 
> draft-dong-lsr-sr-enhanced- vpn.
> 
> Best regards,
> Jie
> 
> 
>    Les
> 
> > approach in RFC 7370 is reasonable, while in general it would be 
> > more useful if a reference is also provided for each column, so as 
> > to indicate in which document the allowed combination of the 
> > sub-TLVs and each TLV is specified. As some sub-TLVs may be defined 
> > earlier than a relatively new TLV, the reference to a sub-TLV does 
> > not really cover their
> combination.
> >
> > I agree that the registry shows the TE attribute sub-TLVs are 
> > allowed in MT- ISN TLV 222, this is good. Then the question left is: 
> > is there a need to specify how to advertise topology-specific TE 
> > attributes, especially when one link participates in multiple 
> > topologies? AFAIK this is not described in RFC 5120, nor RFC 5305.
> >
> > Best regards,
> > Jie
> >
> >
> > The registry clearly indicates the set of specifications - and does 
> > so on a per sub-TLV basis - though not on a per column basis.
> > TLVs. This became awkward to maintain, so RFC7370 combined the per 
> > TLV registries into a single registry for the set of Neighbor/Link 
> > related TLVs (22, 23, 25, 141, 222, and 223)) and similarly for the 
> > set of Prefix related TLVs (135, 235, 236, and 237).
> > Clearly the registry allows TE attribute sub-TLVs to be encoded in 
> > MT TLVs - and the text in RFC 5120 supports that. Whether there is a 
> > real deployment case for that is another matter.
> >
> >    Les
> >
> >
> > > RFC 5120. It would be helpful if you or anyone else could share 
> > > some more information about this. If normative specification of 
> > > using TE attributes in TLV 222 could be found in an RFC, we would 
> > > add a reference to it and remove the editor's note in section 3.1 
> > > of this
> > document.
> > >
> > > 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.
> > > >
> > > >>>> Multi-Topology with other IS-IS extensions, e.g. the 
> > > >>>> extensions for
> > TE, SR and L2 bundle.
> > > same attributes already defined for the "standard" topology 
> > > without going through long standard process to redefine them per topology.”
> > > >>>
> > > of per-topology TE or other applications to a later document. And 
> > > it is also related to my below comment which you missed.
> > > >
> > > > my reading is different.
> > > >
> > > >>
> > > 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.
> > > >>
> > > >>>> particular topology ID, you can not change the topology per 
> > > >>>> L2 link
> > > member.
> > > >>>>
> > > >>>> member link, which I'm not sure why, you need to define a a 
> > > >>>> new attribute and not
> > > mix it with MT-ID.
> > > >>>
> > > link participates in multiple topologies, this could help to 
> > > further identify the member link which is only used for traffic 
> > > belonging to a specific topology. A similar attribute is the admin-group.
> > >
> > > well, if you want to use L3 constructs like MT-ID, it comes with 
> > > an overhead. I have expressed my concerns of the MT being used for 
> > > what you are trying to use it for in the past - and overhead was the main issue.
> > >
> > > thanks,
> > > Peter
> > >
> > > >
> > > >>>>>> what exactly is being standardized in this draft? I don't 
> > > >>>>>> see
> > anything.
> > > >>>>>>
> > > >>>>>> thanks,
> > > >>>>>> Peter
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> enhanced VPN service to support some applications's needs 
> > > >>>>>>> of enhanced isolation and stringent performance requirements.
> > > >>>>>>> (VTN) is a virtual network which consists of a subset of 
> > > >>>>>>> the network toplogy and network resources allocated from 
> > > >>>>>>> the
> > > underlay network.
> > > >>>>>>> This document describes a simplified mechanism to build 
> > > >>>>>>> the SR based VTNs using IGP

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 1 Apr 2020 02:17:30 +0000

Jie -

Once again, inline.

> Sent: Tuesday, March 31, 2020 8:38 AM
> So this is actually your responsibility to specify since you are proposing to
> advertise topology specific link attributes.
> 
> [Jie] I agree that the encoding could be reused, it seems you also agree that
> the usage of existing TLVs for topology-specific link attributes in specific use
> case needs to be specified.
> 

[Les2:] Yes - but as your draft is proposing the use case it is also the responsibility of this draft to address how link attributes can meaningfully be associated with specific topologies and VTNs .
It is legal - based on existing protocol specifications - for topology specific advertisement of link attributes to be carried by the protocol. But how you intend to share bandwidth (as one example) in your topology specific advertisements is something your draft needs to address.
In this matter I am looking to you to explain.

   Les