Hi Jie
Responses in-line.
On Thu, May 19, 2022 at 10:34 PM Dongjie (Jimmy) <jie.d...@huawei.com>
wrote:
> 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).
>
Gyan> Agreed
> Then draft-ietf-lsr-ip-flexalgo introduces the application of Flex-Algo in
> native IP data plane (which is called IP Flex-Algo).
>
> Gyan> Agreed
>
> 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.
>
> Gyan> Makes sense. Agreed.
>
> The application of IP Flex-Algo to VTN or NRP may be specified in a
> separate document.
>
> Gyan> Good idea. I would be happy to collaborate.
>
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.
>
> Gyan> Understood. Makes sense for the smaller Network slicing use cases.
>
> 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.
>
> Gyan> Understood. Perfect.
>
Kind Regards
Gyan
> Best regards,
>
> Jie
>
>
>
> *From:* Gyan Mishra [mailto:hayabusa...@gmail.com]
> *Sent:* Thursday, May 19, 2022 12:55 PM
> *To:* Dongjie (Jimmy) <jie.d...@huawei.com>
> *Cc:* Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org>;
> adr...@olddog.co.uk; draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org;
> lsr@ietf.org
> *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) <jie.d...@huawei.com>
> 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:hayabusa...@gmail.com]
> *Sent:* Wednesday, May 18, 2022 12:51 PM
> *To:* Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org>
> *Cc:* adr...@olddog.co.uk; draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org;
> lsr@ietf.org
>
> *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=
> 40huawei....@dmarc.ietf.org> 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:adr...@olddog.co.uk]
> > Sent: Monday, May 16, 2022 7:22 PM
> > To: lsr@ietf.org
> > Cc: draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org
> > 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> [image: 图像已被发件人删除。] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: 图像已被发件人删除。] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>*
>
> *M 301 502-1347*
>
>
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>*
*M 301 502-1347*
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
