Hi Peter, Thanks for your reply, please see inline with [Jie 3]:
-----Original Message----- From: Peter Psenak [mailto:[email protected]] Sent: Friday, March 27, 2020 11:45 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 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. [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] 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. [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 > > [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 > >>>>> >>>>>> -----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
