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 <[email protected]>
收件人：Dongjie (Jimmy) <[email protected]>;[email protected]
<[email protected]>;lsr <[email protected]>;
日 期 ：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:[email protected]]
> Sent: Friday, March 27, 2020 4:11 PM
> To: Dongjie (Jimmy) <[email protected]>; [email protected]; lsr
> <[email protected]>
> 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
>
> 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:[email protected]]
>> Sent: Thursday, March 26, 2020 7:03 PM
>> To: Dongjie (Jimmy) <[email protected]>; [email protected]; lsr
>> <[email protected]>
>> 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:[email protected]]
>>>> Sent: Thursday, March 26, 2020 5:23 PM
>>>> To: Dongjie (Jimmy) <[email protected]>; [email protected];
>>>> lsr <[email protected]>
>>>> 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
>>>> 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:[email protected]] On Behalf Of Peter Psenak
>>>>>> Sent: Wednesday, March 25, 2020 10:09 PM
>>>>>> To: [email protected]; lsr <[email protected]>
>>>>>> 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, [email protected] 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
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
