Hi Les, Please see my reply inline:
-----Original Message----- From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Tuesday, March 31, 2020 12:17 AM To: Dongjie (Jimmy) <[email protected]>; Peter Psenak <[email protected]>; [email protected]; lsr <[email protected]> Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network Jie - Inline. > -----Original Message----- > From: Dongjie (Jimmy) <[email protected]> > Sent: Monday, March 30, 2020 3:04 AM > To: Les Ginsberg (ginsberg) <[email protected]>; Peter Psenak > <[email protected]>; [email protected]; lsr > <[email protected]> > Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing > based Virtual Transport Network > > Hi Les, > > Thanks for your review and comments. > > Please see my replies inline with [Jie]: > > -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:[email protected]] > Sent: Monday, March 30, 2020 3:06 PM > To: Dongjie (Jimmy) <[email protected]>; Peter Psenak > <[email protected]>; [email protected]; lsr > <[email protected]> > Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing > based Virtual Transport Network > > 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. > > [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. [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. Note that max-link bandwidth is actually one of the easier attributes to share. [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? > > 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? > > [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. > > In other words, it is clear that you want to advertise different link > attributes for the same link in different MTIDs. > > [Jie] This is one of the objectives of draft-xie-lsr-sr-vtn-mt. > > But do you also want to advertise different link attributes for the > same link/MTID in different VTNs? > > [Jie] This is something we want to achieve with > draft-dong-lsr-sr-enhanced- vpn. > > Best regards, > Jie > > > Les > > > -----Original Message----- > > From: Dongjie (Jimmy) <[email protected]> > > Sent: Sunday, March 29, 2020 9:57 PM > > To: Les Ginsberg (ginsberg) <[email protected]>; Peter Psenak > > <[email protected]>; [email protected]; lsr > > <[email protected]> > > Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment > > Routing based Virtual Transport Network > > > > 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 protected]] > > Sent: Saturday, March 28, 2020 1:12 AM > > To: Peter Psenak <[email protected]>; 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 > > > > 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 > > > > > > > -----Original Message----- > > > From: Lsr <[email protected]> On Behalf Of Peter Psenak > > > Sent: Friday, March 27, 2020 8:45 AM > > > 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 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 > > > >>>> -c > > > >>>> od > > > >>>> epo > > > >>>> 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
