Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

["Dongjie (Jimmy)" <[e-mail]>]

Hi Gyan,

Thanks for your further clarification.

My understanding is the IGP Flex-Algo document (draft-ietf-lsr-flex-algo) specifies both the base IGP Flex-Algo mechanisms (the FAD, the constraints and the calculation) and the application of Flex-Algo in SR data plane (which is called SR Flex-Algo). Then draft-ietf-lsr-ip-flexalgo introduces the application of Flex-Algo in native IP data plane (which is called IP Flex-Algo).

Since this document is based on SR data plane, maybe it is more accurate to say it is based on SR Flex-Algo, and reference the Flex-Algo base document (draft-ietf-lsr-flex-algo), as it is where SR Flex-Algo is specified.

The application of IP Flex-Algo to VTN or NRP may be specified in a separate document.

Regarding the 1:1 mapping between VTN or NRP and Flex-Algo, it is agreed that the scalability is limited, and in this document this is considered as a mechanism for network scenarios where a relatively small number of VTNs are needed. The advantage is that we can reuse existing mechanisms with very small extension.

The mechanism John mentioned (allocating per-NRP resource-aware SIDs and let multiple NRPs share the same Flex-Algo) is more scalable, while requires further protocol extensions. This mechanism is specified in another document https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-07. IMO both mechanisms have their targeted scenarios.

Best regards,
Jie

From: Gyan Mishra [mailto:[e-mail]]
Sent: Thursday, May 19, 2022 12:55 PM
To: Dongjie (Jimmy) <[e-mail]>
Cc: Dongjie (Jimmy) <jie.dong=[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

Hi Jie

Very welcome!

I was actually referring to “SR” Flex Algo not IP Flex Algo comment I made.  This is a bit confusing which is why I brought it up.

Since the original Flex Algo draft is the base draft for Flex Algo it was termed by the authors “IGP Flex Algo” not “SR Flex Algo” as the base has extensibility to other data planes such as RSVP-TE, IP and future data planes.  However today the base only supports SR.

Base Flex Algo = IGP Flex Algo

Only Applies to SR data plane SR-MPLS prefix sid or SRv6 locator but is extensible to other data planes

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-20

Extensible starting with below IP Flex Algo

IP Flex Algo

Only applies to IP data plane destination prefix based algo

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo

So in the draft you mentioned SR Flex Algo so I was just stating based on above to be more accurate per below recommendation.

s/ SR Flex Algo/ IGP Flex Algo

Regarding TEAS terminology VTN versus NRP, as Enhanced VPN / VPN+ aligns with VTN I see your point to keep the VTN terminology in this draft as 5G and VPN+ are mentioned.

https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-10

My thoughts were that as the NRP scalability draft also has references to VPN+ and uses the NRP terminology it seems to make sense for drafts referencing IETF network slice underlay resource  provisioning to refer to NRP for consistency.  I am OK with either direction but I think for the reader consistency is always good as terminology can get confusing.

What are your thoughts on the latter part of the email discussion related to NRP and Flex Algo identifier and instead of the 1 for 1 mapping Flex Algo to NRP does not scale as well for slicing.

What John mentioned was a set of resource SIDs, one per NRP allocated on links that are currently part of the FAD topology algo. So then a label would be allocated by each node to represent [FAD,NRP] tuple.

This idea would be a way to provide better control plane scalability for IETF network slicing using Flex Algo and not be limited to 128 slices.

I had not thought about it but  IP Flex Algo could also be used for IETF network slicing for sure.

Kind Regards

Gyan


On Wed, May 18, 2022 at 11:58 PM Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Gyan,

Thanks for your review and useful comments.

The VTN concept is introduced in VPN+ framework (https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn) in TEAS, and its relationship with NRP is described in that document. VTN can be used to support VPN+ service, which provides a realization of network slice.

This document provides a mechanism to build SR based VTNs using the combination of existing techniques (Flex-Algo, L2 bundle) with minor extensions. Calling it VTN or NRP does not impact the mechanism or the extensions in this document. We prefer to continue to the term VTN to align with VPN+ framework, but we are open to suggestions.

Your comment about the IP Flex-Algo is more interesting. Since the L2 bundle relies on different SR SIDs for traffic steering to different member links, my feeling is it is mostly applicable to SR based data plane. If needed we could have further discussion about whether and how IP Flex-Algo can be used for VTN or NRP.

Best regards,
Jie

From: Gyan Mishra [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, May 18, 2022 12:51 PM
To: Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

Hi Jie

I reviewed the draft as well and it seems to parallel SR VTN MT draft  Enhanced VPN / VPN+  underpinning to IETF slice underlay TEAS NRP  mapped to an ISIS or OSPF MTID control plane instance.

Similarly here with this draft mapping of TEAS NRP to a Flex Algo FAD realizing of IETF network slice and now bundle members with this draft extensions to RFC 8668 ISIS and OSPF draft
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-03 can now be mapped to an NRP.

VTN MT
https://datatracker.ietf.org/doc/html/draft-xie-lsr-isis-sr-vtn-mt

Suggestion for s/VTN/NRP using updated TEAS Network slicing terminology.

This draft updates RFC 8668 for ISIS but should also update the OSPF draft above.

I think Adrian may have mentioned in his review I would refer to Flex Algo as IGP Flex Algo not SR Flex Algo throughout the draft as specified in the IGP Flex Algo draft.

I think it may or may not be the intention but I believe along with realizing an NRP using IGP Flex Algo mapping to L2 bundle member links, this draft also provides the context of realizing an NRP using Flex Algo and using the Flex Algo identifier as a way to reference or index the NRP per statement in section 2.


If each VTN is associated with a unique Flex-Algo, the Flex-Algo identifier could be

reused as the identifier of the VTN in the control plane.

With the 1 to 1 mapping of Flex Algo to NRP you could also use the Flex Algo identifier to correlate the IETF Network slice NRP being instantiated by the NSC and possibly could use the Flex Algo identifier as the NRP ID.

Kind Regards

Gyan

On Tue, May 17, 2022 at 6:01 AM Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>> wrote:
Hi Adrian,

Thanks a lot for your detailed review. All your comments and suggestions look good and we will produce a new revision to incorporate them.

And please see replies to some points inline:

Best regards,
Jie

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Monday, May 16, 2022 7:22 PM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: FW: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04
>
> Hi LSR and draft authors,
>
> I read this draft, and it seems to me that it provides a useful transitional
> mechanism. It can obviously only support a relatively small number of VTNs
> (128 due to the limited number of Flex-Algos the network devices can
> support), but it looks to be a worthwhile first step because it can be achieved
> with a very minor control plane extension.
>
> Perhaps this document is a good first step while we work on a longer term
> and more scalable control plane solution. It would also give us the chance to
> determine the level of interest in VTNs.

Indeed, this is exactly the purpose of this document.

>
> My comments, below, are mainly editorial, but there are a couple of issues
> around the use of the E flag.
>
> Best,
> Adrian
>
> (PS. For those of you saying "What's a VTN?" the "Virtual Transport
> Network"
> is a network construct described in the TEAS WG to support Enhanced VPNs
> (https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/) and network
> slicing
> (https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/)
> where it maps to a "Network Resource Partition".)
>
> ===
>
> As currently defined, I think this document needs to update RFC 8668. This is
> because that RFC says that other flags in the flag field of the Parent L3
> Neighbor Descriptor in the L2 Bundle Member Attributes TLV "MUST be
> ignored".
>
> That's easy enough to handle:
> - You add the "updates 8668" element to the XML
> - You add a final paragraph to the Abstract to say
>     This document updates RFC 8668 by defining a new flag in the Parent
>     L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> - You add a final paragraph to the Introduction to say
>     This document updates [RFC8668] by defining a new flag in the Parent
>     L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
>     [RFC8668] states that all bit fields not defined in that document
>     "MUST be set to zero on transmission and ignored on receipt".
>     Section 3 of this document defines a new flag and specifies both
>     when it is set and how it should be processed.
>
> However, a purist might point out that RFC 8668 should be fixed so that:
>
> - The unused bits are defined as reserved for future use
> - The text should be updated to describe how the bits are set and handled
>   by implementations that don't understand them
> - There should be an IANA registry for the bits
>
> You're not responsible for fixing RFC 8668, but you could if you want to.
>
> Making this document an "update" is also important because of the absence
> of an IANA registry -- it is important to provide a way for people to track the
> bits so that there is no collision when another bit is defined.
>
> You could use definitely use this document to create the necessary IANA
> registry, even if you are not fixing the other parts of 8668.

Thanks for your suggestion, we will make this document an update of RFC 8668 to help track the new flag.


>
> ---
>
> Would be worth expanding "VTN" in the title to read...
>   Using Flex-Algo for Segment Routing based Virtual Transport Networks
>
> ---
>
> Abstract
>
> The first mention of "Flex-Algo" needs to have some explanation of the
> concept. Not many words, but something like...
>
> OLD
>    The topological constraints of a VTN can be defined using Flex-Algo.
> NEW
>    The topological constraints of a VTN can be defined using Flex-Algo,
>    a mechanism to provide distributed constraint-path computation.
> END

We will add some description about Flex-Algo.


> ---
>
> Abstract
>
> "SR" should be spelled out as "Segment Routing (SR)"
>
> ---
>
> Abstract
>
> s/L2 bundle/L2 bundles/
>
> ---
>
> 1.
>
> The word "traditional" has other meanings in American English and we are
> now asked to avoid using it.
>
> OLD
>    than that can be provided with traditional overlay VPNs.
> NEW
>    than that could be provided with existing overlay VPNs techniques.
> END

OK, will make the change accordingly.

>
> ---
>
> 1.
>
> s/resource-aware SIDs/resource-aware segment identifiers (SIDs)/ s/With
> segment routing/With a segment routing/ s/Segment Identifiers (SIDs) can
> be used/SIDs can be used/ s/using control plane/using the control plane/
> s/scalable Segment Routing (SR)/scalable SR/ s/a unique Flex-Algo/a unique
> Flex-Algo [I-D.ietf-lsr-flex-algo]/
>
> ---
>
> Section 1 has just one sentence on the purpose and content of this
> document.
>
>    This document
>    describes a mechanism to build the SR based VTNs using SR Flex-Algo
>    and IGP L2 bundle with minor extensions.
>
> This text is fine, but rather limited.
> I suggest:
> - Make it a separate paragraph so that it stands out.
> - Add at least two more sentences describing what is found in this
>   document. Probably you can just summarise what the mechanism is.
> - Describe the purpose and intended use of the mechanism.
>

We will expand this with a few more sentences.


> ---
>
> 1.1
>
> The boilerplate here is slightly wrong. Should read...
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
> "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in BCP
>    14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.
>
> ---
>
> 3.
>
> s/can be allocated with a set/can be allocated a set/
>
> ---
>
> 3.
>
> OLD
>    In order to perform constraint
>    based path computation for each VTN on network controller and the
>    ingress nodes, the resource attribute of each VTN also needs to be
>    advertised.
> NEW
>    In order for a network controller or the ingress nodes to perform
>    constraint based path computation for each VTN, the resource
>    attributes of each VTN need to be advertised.
> END
>
> ---
>
> 3.
>
> s/resource attribute of the VTN/resource attributes of the VTN/
>
> ---
>
> 3.
>
> OLD
>    The layer-3 link may or may not be a bundle of layer-2 links, as long
>    as it has the capability of partitioning the link resources into
>    different subsets for different VTNs it participates in.
> NEW
>    The layer-3 link must have the capability of partitioning the link
>    resources into different subsets for the different VTNs it
>    participates in.  It may or may not be a bundle of layer-2 links to
>    achieve this.
> END
>
> ---
>
> 3.
>
> s/set of link resource allocated/set of link resources allocated/ s/the Parent
> L3 link are used/the Parent L3 link is used/
>
> ---
>
> 3.
>
> Add to the paragraph that begins "E flag:" ...
>
>    Note that legacy implementations of [RFC8668] will set the E flag to
>    zero (clear) meaning that load balancing among component links is the
>    default behavior. Further, when a legacy implementation receives an
>    E flag that is set, it will ignore the flag and so will assume that
>    load balancing among component links is allowed even when the sender
>    has requested it to not be used.
>
> NOTE WELL! If this is not the behaviour you want to see, you need to do
> something different with the E flag.

Yes, a legacy node will ignore this Flag and perform load balancing among the component links. While since Flex-Algo is used to control the set of nodes involved in a VTN, only the nodes which support the extension will participate in the Flex-Algo for VTN.


>
> ---
>
> 3.
>
>    For each virtual or physical layer-2 member link, the TE attributes
>    defined in [RFC5305] such as the Maximum Link Bandwidth and Admin
>    Groups SHOULD be advertised using the mechanism as defined in
>    [RFC8668].
>
> a. You need to say why an implementation might choose to not do this
>    (to explain your use of SHOULD), what the consequences would be, and
>    what it might do instead.
>
> b. s/[RFC5305]/[RFC5305],/
>
> c. s/Groups/Groups,/

In RFC 8668, the TE attributes of the layer-2 member link are optional attributes. In this VTN scenario, the admin groups (color) is required for the correlation between the Flex-Algo specific forwarding entries and the member link. The bandwidth attribute is optional and may be needed in the constraint based path computation performed by the network controller or the ingress nodes. We will correct the requirement language usage.


>
> ---
>
> 3.
>
>    The SR-MPLS Adj-SIDs or SRv6 End.X SIDs associated with
>    each of the virtual or physical Layer-2 member links SHOULD also be
>    advertised according to [RFC8668] and [I-D.dong-lsr-l2bundle-srv6].
>
> You need to say why an implementation might choose to not do this (to
> explain your use of SHOULD), what the consequences would be, and what it
> might do instead.

The SR SIDs associated with the layer-2 member links are required in the mechanism. We will replace the "SHOULD" with "MUST".


>
> ---
>
> 3.
>
>    In order to correlate the virtual or physical layer-2 member links
>    with the Flex-Algo ID which is used to identify the VTN, each VTN
>    SHOULD be assigned with a unique Admin Group (AG) or Extended Admin
>    Group (EAG), and the virtual or physical layer-2 member links
>    associated with this VTN SHOULD be configured with the AG or EAG
>    assigned to the VTN.  The AG or EAG of the parent layer-3 link SHOULD
>    be set to the union of all the AGs or EAGs of its virtual or physical
>    layer-2 member links.
>
> I think the three instances of "SHOULD" here can be:
> s/SHOULD be/is/
> s/SHOULD be/are/
> s/SHOULD be/is/
>
> ---
>
> 3.
>
> s/VTN, It/VTN, it/
>
> ---
>
> 4.
>
> s/For SR-MPLS data plane/For the SR-MPLS data plane/
>
> ---
>
> 4.
>
>    The Adj-SIDs associated
>    with the virtual or physical member links of a VTN MAY be used with
>    the prefix-SIDs of the same VTN together to build SR-MPLS TE paths
>    with the topological and resource constraints of the VTN.
>
> I recommend s/MAY/can/
>
> Similarly in
>
>    The
>    End.XU SIDs associated with the virtual or physical member links of a
>    VTN MAY be used with the SRv6 Locator prefix of the same VTN together
>    to build SRv6 paths with the topological and resource constraints of
>    the VTN.
>
> ---
>
> 4.
>
> s/For SRv6 data plane/For the SRv6 data plane/
>
> ---
>
> 5.
>
> OLD
>    which is related to the number of Flex-Algos defined NEW
>    which is related to the maximum number of Flex-Algos supported END
>
> OLD
>    described in [I-D.dong-teas-nrp-scalability].
> NEW
>    found in [I-D.dong-teas-nrp-scalability].
> END

Thanks for catching this, we will update the reference in next revision.



_______________________________________________
Lsr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsr
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347