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

["Wanghaibo (Rainsword)" <[e-mail]>]

Hi Sue,
I support the adoption of this document. It provides a practical solution to build multiple SR based VTNs with existing BGP-LS MT and SR mechanisms.

Regards,
Haibo

From: Idr [mailto:[e-mail]] On Behalf Of Dongjie (Jimmy)
Sent: Monday, December 20, 2021 3:58 PM
To: Susan Hares <[e-mail]>; [e-mail]
Subject: Re: [Idr] draft-xie-idr-bgpls-sr-vtn-mt-03.txt - Call for WG adoption: 12/18/2021 to 1/7/2022

Hi Sue,

I support the adoption of this document as coauthor. Please find my replies to the questions inline:

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Sunday, December 19, 2021 12:33 AM
To: [e-mail]<mailto:[e-mail]>
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/

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.

[Jie] Yes.

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]

[Jie] One clarification: for the mechanism in this document, new VTN-ID is not needed, as the MT-ID is reused in draft-ietf-lsr-isis-sr-vtn-mt and this document. The mechanism with new control plane VTN-ID is another solution as described in draft-dong-lsr-sr-enhanced-vpn for better scalability.

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.

[Jie] Similar clarification: for the mechanism in this document, new VTN-ID is not needed, as the MT-ID can also be used for the inter-domain links. The mechanism with new control plane VTN-ID is another solution as described in draft-dong-idr-bgpls-sr-enhanced-vpn.

[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?

[Jie] Since this document simply proposes to reuse MT-ID to identify the VTNs in control plane, my suggestion is that we may discuss the range of MT-IDs which could be used for VTN in the IANA registry. The global name space for VTN-ID is not required by this document.

Best regards,
Jie


Cheers, Sue