Hi Acee As an operator, I support adoption of the draft and would like to provide answers to your questions.
I would like to start by stating that as this is an informational document, as nothing new is proposed other then the recommendation to use MT for VTN provisioning as a component of the 5G network slicing solutions, the benefit is that this concept can be used immediately as other NS features are still being developed. The solution for network slicing resource isolation is multi faceted involves Enhanced VPN+ provisioning, resource SIDs for provisioning underlay resources, SR-TE Per VPN or flow path steering to meet NS SLO requirements, as well as a method to isolate IGP resources for a VTN. MT is a component of the entire NS solution so there is really nothing to market as it’s not the only component used to provision the VTN. As their is a need for providing a viable means of provisioning IGP underlay resources VTN network slice and the ability to provide forwarding plane isolation via topological RIB without consuming tremendous control plane resources per instance as with MI. This draft does fill the gap of a means of forwarding plane isolation on shared infrastructure even though it does have scalability considerations. As other ideas of IGP forwarding plane isolation come about we are open to other solutions as well. As their are scalability concerns in section 5 that should be expanded, when MT should be used to support VTN and when should not. Agreed. I would deploy in a limited fashion taking into account the scalability concerns. Enhanced VPN VPN+ scalability issue are described in detail in this draft below. Lots of variables related to how many slices based on services which will eventually scale up but I think MT may suffice well in the beginning stages. https://tools.ietf.org/html/draft-dong-teas-enhanced-vpn-vtn-scalability-01 There are many drafts and solutions in the works across many different WGs that are working on development of solution as to how network slicing and SLO can be realized by operators for 5G services. Of these drafts below there are a number of Enhanced VPN Framework VPN+ related drafts that are critical to the provisioning of various components of network slicing. https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-07 https://datatracker.ietf.org/doc/draft-dong-teas-enhanced-vpn-vtn-scalability/ https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn-06 https://tools.ietf.org/html/draft-ietf-spring-resource-aware-segments-02 Kind Regards Gyan On Thu, Mar 25, 2021 at 2:21 PM Acee Lindem (acee) <acee= [email protected]> wrote: > Speaking as WG chair: > > > > There has been considerable support for this document. However, there has > also been objections to the document. The objections are either that there > is nothing to standardize given that all pieces exist and that the MT isn’t > a viable option for VTNs since it isn’t scalable. > > > > Since most of the draft’s support is from “friends and family”, I’d like > to know of the WG members who supported it, would you really want to market > it as a VTN solution? Those of you who operate networks, would you actually > consider deploying it? > > > > In any case, section 5 needs to be expanded on the scalability and where > using MTs to support VTNs would make sense and where it wouldn’t. > > > > Thanks, > Acee > > > > > > *From: *Lsr <[email protected]> on behalf of "Acee Lindem (acee)" > <[email protected]> > > > *Date: *Tuesday, March 2, 2021 at 6:28 PM > *To: *"[email protected]" <[email protected]> > *Subject: *[Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) > for Segment Routing based Virtual Transport Network” - > draft-xie-lsr-isis-sr-vtn-mt-03 > > > > This information draft describes how MT could be used for VTN > segmentation. The authors have asked for WG adoption. > > > > This begins a three week LSR Working Group Adoption Poll for “Using IS-IS > Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - > draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF > next week. Please register your support or objection on this list prior to > the end of the adoption poll on 3/24/2020. > > > > Thanks, > > Acee > > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
