Re: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022

Hi，folks，
I support the adoption of this draft as the author.
Generally, our network services provide not only 5G-based wireless mobile data, but  also wireline sevice for enterprise services, this poses wide variety of requirements to the underlying transport network, this draft illustrates how to management virtual transport networks (VTNs) which are resource-aware and  resources-isolated among each over the common transport network. Obviously, this is valuable for operators.
As mentioned several times in the mailist, this draft does not intend to design new ID or bop extension  it mainly discusses how to use mt-id and provide slicing service rapidly in operator networks. Global VTN-ID can be discussed in the future in other drafts or in other WGs.

Best regards!
Chongfeng

> 2021年12月28日 下午3:59，Lizhenbin <lizhenbin=40huawei.com@dmarc.ietf.org> 写道：
> 
> Hi All,
> I support the adoption of the draft.

> 
> My answers to the questions is as follows:
> 1) Yes.
> 2) Global VTN-ID is not required in this document. The work of the Global VTN ID can be discussed separately and should be discussed firstly in the TEAS WG.
>  
>  
> Best Regards,
> Zhenbin (Robin)
>  
>  
>  
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
> Sent: Sunday, December 19, 2021 12:33 AM
> To: idr@ietf.org
> Subject: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022
>  
> This begins a WG Adoption call for draft-xie-idr-bgpls-sr-vtn-mt-03.txt from 12/18 2021 to 1/7/2022.  The longer period is due to the Holiday/New Year time period.
>  
> The draft can be found at: 
> https://datatracker.ietf.org/doc/draft-xie-idr-bgpls-sr-vtn-mt/ <https://datatracker.ietf.org/doc/draft-xie-idr-bgpls-sr-vtn-mt/>
>  
> While reviewing the document consider the following questions:
>  
> 1)  Does this informational draft aid operation of 5G networks for new applications?
>  
> New 5G services require stringent  performance requirements for applications.  This information draft describes how to use existing segment routing (SR)
> mechanisms to allow a centralized control to allocate a set of  virtual transport networks (VTNs) which are resource aware.  Isolation between resources for multi-AS transport may be necessary to protect the application.
>  
> Intra-domain:  
> a) Uses MT-ID which identifies 1 or more ISIS/OSPF topologies.
> [drafts referenced:  draft-ietf-idr-rfc7752bis, draft-ietf-idr-bgp-ls-segment-routing-ext,  draft-ietf-idr-bgpls-srv6-ext]
> b) New VTN-ID which specifies resources associated with each VTN
> [draft referenced: draft-ietf-lsr-isis-sr-vtn-mt]
>  
> Inter-Domain mechanisms used include: 
> a) Isolation of certain VTNs to specific inter-domain links or BGP peers,  
> b) consistent use of MT-ID across multiple domains or use of VTN-ID TLV
>  
> VTN-ID TLV is a bgp-ls TLV that specifies unique set of resources per VTN. 
>  
> [existing WG drafts referenced: draft-ietf-idr-bgpls-segment-routing-epe, draft-ietf-idr-bgpls-srv6-ext, draft-ietf-idr-rfc7752bis]
> New drafts referenced: draft-dong-idr-bgpls-sr-enhanced-vpn-03.txt]
>  
> 2) Should IDR recommend the global VTN-ID?
>  
> The MT-ID is not an IANA registered named space.  VTN-ID is proposed as a global name space, but does not have any proposed IANA registry text.  Should VTN-ID become a register global name space that identifies a set of MT-IDs and other resources?  
>  
> Cheers, Sue 
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr