Jie - Once again, inline.
> -----Original Message----- > From: Dongjie (Jimmy) <[email protected]> > Sent: Tuesday, March 31, 2020 8:38 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, > > 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. > [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 > 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
