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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Tony Przygienda
Sent: Saturday, March 28, 2020 10:25 AM
To: [e-mail]
Cc: [e-mail]; Dongjie (Jimmy) <[e-mail]>; ppsenak=[e-mail]; [e-mail]
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 ..

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 <[e-mail]<mailto:[e-mail]>> wrote:



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=[e-mail]<mailto:[e-mail]>>
收件人：Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;lsr <[e-mail]<mailto:[e-mail]>>;
日 期 ：2020年03月27日 23:45
主 题 ：Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi Dongjie,

On 27/03/2020 16:32, Dongjie (Jimmy) wrote:
> 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.

I guess it came with RFC 5120.

please see more inline:


>
> And please see some further replies inline about the L2 bundle discussion.
>
> -----Original Message-----
> From: Peter Psenak [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Friday, March 27, 2020 4:11 PM
> To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; lsr <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network
>
> Hi Dongjie,
>
> On 27/03/2020 07:56, Dongjie (Jimmy) wrote:
>> 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 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:
>
> 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>
>
> It says "y" for all TE attributes. What else do you need?
>
>>
>> And please see further replies inline with [Jie]:
>>
>> -----Original Message-----
>> From: Peter Psenak [mailto:[e-mail]<mailto:[e-mail]>]
>> Sent: Thursday, March 26, 2020 7:03 PM
>> To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; lsr
>> <[e-mail]<mailto:[e-mail]>>
>> 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:
>>> Hi Peter,
>>>
>>> Thanks for your comments.
>>>
>>>> -----Original Message-----
>>>> From: Peter Psenak [mailto:[e-mail]<mailto:[e-mail]>]
>>>> Sent: Thursday, March 26, 2020 5:23 PM
>>>> To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
>>>> lsr <[e-mail]<mailto:[e-mail]>>
>>>> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
>>>> Routing based Virtual Transport Network
>>>>
>>>> Hi Dongjie,
>>>>
>>>> On 26/03/2020 07:40, Dongjie (Jimmy) wrote:
>>>>> Hi Peter,
>>>>>
>>>>> As described in the abstract, the purpose of this draft is to
>>>>> define a simplified
>>>> control plane mechanism to build SR based Virtual Transport Network
>>>> (VTN), it is based on the combination of IS-IS Multi-Topology with
>>>> other IS-IS extensions, e.g.. the extensions for TE, SR and L2 bundle.
>>>> In a word, it tries to reuse the existing TLVs as much as possible.
>>>>
>>>> reusing the TLVs is not something that needs a standardization.
>>>>
>>>>>
>>>>> That said, this document introduces the mechanism of specifying
>>>> per-topology TE attributes, which was not covered in the existing
>>>> IS-IS MT (RFC 5120).
>>>>
>>>> I can clearly see that TLVs defined in RFC5120 are listed in the
>>>> registry of sub-TLVs available for TLV 222/223
>>>>
>>>> https://www..iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepo<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepo>
>>>> i
>>>> nts.xhtm
>>>> l#isis-tlv-codepoints-22-23-25-141-222-223
>>>>
>>>> So I'm not sure what you are adding.
>>>
>>> In RFC 5120 section 7, it says that
>>>
>>> “If traffic engineering or some other applications are being applied per topology level later, the new TLVs can automatically inherit the same attributes already defined for the "standard" topology without going through long standard process to redefine them per topology.”
>>>
>>> This indicates that per-topology TE attributes is not a feature specified in RFC5120, although the TLVs can be reused.
>>
>> the text above clearly says there is no standardization required.
>>
>> [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.
>
>>
>>>>> Similarly, it also introduces the mechanism of associating MT-IDs
>>>>> with a
>>>> particular member link of L2 bundle, which was not defined in IS-IS
>>>> L2 Bundle (RFC 8668).
>>>>
>>>> carrying MT-ID in the L2 Bundle TLV is conceptually wrong.
>>>>
>>>> It is the parent L3 link which has the association with the
>>>> particular topology ID, you can not change the topology per L2 link member.
>>>>
>>>> You are trying to overload the MT-ID with the VTN semantics, but you
>>>> can not do it here. If you need a VTN ID for the L2 member link,
>>>> which I'm not sure why, you need to define a a new attribute and not mix it with MT-ID.
>>>
>>> In this document we try to reuse the existing IDs and TLVs to fulfil the functionality required. Since several existing TLVs defined for L3 link have been introduced for the L2 bundle member, we are considering the possibility of also carrying MT-ID as another attribute of the member link. Could you elaborate why it cannot be reused? Of course defining a new VTN-ID is another option. We are open to discussion about this.
>>
>> the reason is simple - the L3 link is already associated with the MT-ID.
>> You can not change the MT-ID of the underlying L2 link.
>>
>> [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.
>
> 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.

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

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

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


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