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

Hi All,

I think the draft is valuable, so I support the adoption of this draft.
Regarding Sue's questions:

1) I see it applicable to general situations as well, not only for 5G
scenarios (in fact talking of 5G scenarios where in some specific cases
there could be very stringent requirements - e.g., latency or jitter - is
something that could require further assessment).

2) The draft mentions that " (Abstract) The association between the network
topology, the network resource attributes and the SR SIDs may need to be
distributed to a centralized network controller." and then "(Section 2.2)
In network scenarios where consistent usage of MT-ID among multiple domains
can not be expected, a global-significant VTN-ID needs to be introduced to
define the inter-domain topologies." So it is not clear to me if some
additional signaling between controllers in different domains could map the
MT-IDs in each particular domain instead of going for a global VTN-ID
(which anyway should require some agreement between controllers as well). I
think this part requires more elaboration (could it even deserve a separate
document for that?).

Best regards

Luis

El sáb, 18 dic 2021 a las 17:33, Susan Hares (<shares@ndzh.com>) escribió:

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

-- 
___________________________________________
Luis M. Contreras
contreras.ietf@gmail.com
luismiguel.contrerasmurillo@telefonica.com
Global CTIO unit / Telefonica