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-codepoints.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. 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. > >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. 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
