[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04
From: Gyan Mishra <hayabusagsm () gmail ! com>
Date: 2022-05-20 4:03:34
Message-ID: CABNhwV2J24uHLAe0B1XXrV=NXtnwkov_9x0YGAV4-fxKzVuYgg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/related)]
[Attachment #4 (multipart/alternative)]
Hi Jie
Responses in-line.
On Thu, May 19, 2022 at 10:34 PM Dongjie (Jimmy) <jie.dong@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:hayabusagsm@gmail.com]
> *Sent:* Thursday, May 19, 2022 12:55 PM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org>;
> adrian@olddog.co.uk; draft-zhu-lsr-isis-sr-vtn-flexalgo@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.dong@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:hayabusagsm@gmail.com]
> *Sent:* Wednesday, May 18, 2022 12:51 PM
> *To:* Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org>
> *Cc:* adrian@olddog.co.uk; draft-zhu-lsr-isis-sr-vtn-flexalgo@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.com@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:adrian@olddog.co.uk]
> > Sent: Monday, May 16, 2022 7:22 PM
> > To: lsr@ietf.org
> > Cc: draft-zhu-lsr-isis-sr-vtn-flexalgo@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.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: 图像已被发件人 除。] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
*M 301 502-1347*
[Attachment #7 (text/html)]
<div dir="auto">Hi Jie </div><div dir="auto"><br></div><div dir="auto">Responses \
in-line.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Thu, May 19, 2022 at 10:34 PM Dongjie (Jimmy) <<a \
href="mailto:jie.dong@huawei.com">jie.dong@huawei.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="ZH-CN" link="blue" vlink="purple">
<div class="m_-3946755470801799060WordSection1">
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">Hi \
Gyan,<u></u><u></u></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> \
<u></u></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">Thanks \
for your further clarification. <u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> \
<u></u></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">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). \
</span></p></div></div></blockquote><div dir="auto"> Gyan> \
Agreed</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div lang="ZH-CN" link="blue" vlink="purple"><div \
class="m_-3946755470801799060WordSection1"><p class="MsoNormal" dir="auto"><span \
lang="EN-US" style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">Then \
draft-ietf-lsr-ip-flexalgo introduces the application of Flex-Algo in native IP data \
plane (which is called IP Flex-Algo). <u></u><u></u></span></p>
<p class="MsoNormal" dir="auto"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> \
Gyan> Agreed <u></u></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">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. \
<u></u><u></u></span></p> <p class="MsoNormal" dir="auto"><font color="#1f497d" \
face="Calibri, sans-serif"><span style="font-size:14px">Gyan> Makes sense. \
Agreed.</span></font></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">The \
application of IP Flex-Algo to VTN or NRP may be specified in a separate \
document.<u></u><u></u></span></p> <p class="MsoNormal" dir="auto"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> \
Gyan> Good idea. I </span><span \
style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:10.5pt">would be \
happy to collaborate.</span></p></div></div></blockquote><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div lang="ZH-CN" link="blue" vlink="purple"><div \
class="m_-3946755470801799060WordSection1"> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p> \
<p class="MsoNormal" dir="auto"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> \
Gyan> Understood. Makes sense for the smaller Network slicing use \
cases.<u></u></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">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 <a \
href="https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-07" \
target="_blank"> https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-07</a>. \
IMO both mechanisms have their targeted scenarios. \
<u></u><u></u></span></p></div></div><div lang="ZH-CN" link="blue" \
vlink="purple"><div class="m_-3946755470801799060WordSection1"> <p class="MsoNormal" \
dir="auto"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u>Gyan> \
Understood. Perfect.</span></p></div></div></blockquote><div dir="auto"> Kind \
Regards</div><div dir="auto"><br></div><div dir="auto"> Gyan</div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div lang="ZH-CN" link="blue" vlink="purple"><div \
class="m_-3946755470801799060WordSection1"><p class="MsoNormal" dir="auto"><span \
lang="EN-US" style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">Best \
regards,<u></u><u></u></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">Jie<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> \
<u></u></span></p> <div style="border:none;border-left:solid blue 1.5pt;padding:0cm \
0cm 0cm 4.0pt"> <div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" \
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span \
lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> \
Gyan Mishra [mailto:<a href="mailto:hayabusagsm@gmail.com" \
target="_blank">hayabusagsm@gmail.com</a>] <br>
<b>Sent:</b> Thursday, May 19, 2022 12:55 PM<br>
<b>To:</b> Dongjie (Jimmy) <<a href="mailto:jie.dong@huawei.com" \
target="_blank">jie.dong@huawei.com</a>><br> <b>Cc:</b> Dongjie (Jimmy) \
<jie.dong=<a href="mailto:40huawei.com@dmarc.ietf.org" \
target="_blank">40huawei.com@dmarc.ietf.org</a>>; <a \
href="mailto:adrian@olddog.co.uk" target="_blank">adrian@olddog.co.uk</a>; <a \
href="mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo@ietf.org" \
target="_blank">draft-zhu-lsr-isis-sr-vtn-flexalgo@ietf.org</a>; <a \
href="mailto:lsr@ietf.org" target="_blank">lsr@ietf.org</a><br> <b>Subject:</b> Re: \
[Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04<u></u><u></u></span></p> \
</div> </div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi Jie <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Very welcome!<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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. <u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Base Flex Algo = IGP Flex Algo \
<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Only Applies to SR data plane SR-MPLS prefix \
sid or SRv6 locator but is extensible to other data planes<u></u><u></u></span></p> \
</div> <div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><a \
href="https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-20" \
target="_blank">https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-20</a><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Extensible starting with below IP Flex Algo \
<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">IP Flex Algo <u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Only applies to IP data plane destination \
prefix based algo<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><a \
href="https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo" \
target="_blank">https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo</a><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">So in the draft you mentioned SR Flex Algo so \
I was just stating based on above to be more accurate per below \
recommendation.<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">s/ SR Flex Algo/ IGP Flex \
Algo<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p> </div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><a \
href="https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-10" \
target="_blank">https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-10</a><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p> \
</div> <div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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. \
<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">I had not thought about it but IP Flex Algo \
could also be used for IETF network slicing for sure. <u></u><u></u></span></p> \
</div> <div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Kind Regards <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Gyan<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">On Wed, May 18, 2022 at 11:58 PM Dongjie \
(Jimmy) <<a href="mailto:jie.dong@huawei.com" \
target="_blank">jie.dong@huawei.com</a>> wrote:<u></u><u></u></span></p> </div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm \
6.0pt;margin-left:4.8pt;margin-right:0cm"> <div>
<div>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">Hi \
Gyan,</span><span lang="EN-US"><u></u><u></u></span></p> <p class="MsoNormal"><span \
lang="EN-US" style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"> \
</span><span lang="EN-US"><u></u><u></u></span></p> <p class="MsoNormal"><span \
lang="EN-US" style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">Thanks \
for your review and useful comments. </span><span \
lang="EN-US"><u></u><u></u></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"> \
</span><span lang="EN-US"><u></u><u></u></span></p> <p class="MsoNormal"><span \
lang="EN-US" style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">The \
VTN concept is introduced in VPN+ framework (<a \
href="https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn" \
target="_blank">https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn</a>) \
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.</span><span \
lang="EN-US"><u></u><u></u></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"> \
</span><span lang="EN-US"><u></u><u></u></span></p> <p class="MsoNormal"><span \
lang="EN-US" style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">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. </span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"> \
</span><span lang="EN-US"><u></u><u></u></span></p> <p class="MsoNormal"><span \
lang="EN-US" style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">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. </span><span \
lang="EN-US"><u></u><u></u></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"> \
</span><span lang="EN-US"><u></u><u></u></span></p> <p class="MsoNormal"><span \
lang="EN-US" style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">Best \
regards,</span><span lang="EN-US"><u></u><u></u></span></p> <p \
class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d">Jie</span><span \
lang="EN-US"><u></u><u></u></span></p> <p class="MsoNormal"><span lang="EN-US" \
style="font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1f497d"> \
</span><span lang="EN-US"><u></u><u></u></span></p> <div \
style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"> <div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" \
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span \
lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> \
Gyan Mishra [mailto:<a href="mailto:hayabusagsm@gmail.com" \
target="_blank">hayabusagsm@gmail.com</a>] <br>
<b>Sent:</b> Wednesday, May 18, 2022 12:51 PM<br>
<b>To:</b> Dongjie (Jimmy) <jie.dong=<a href="mailto:40huawei.com@dmarc.ietf.org" \
target="_blank">40huawei.com@dmarc.ietf.org</a>><br> <b>Cc:</b> <a \
href="mailto:adrian@olddog.co.uk" target="_blank">adrian@olddog.co.uk</a>; <a \
href="mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo@ietf.org" \
target="_blank">draft-zhu-lsr-isis-sr-vtn-flexalgo@ietf.org</a>; <a \
href="mailto:lsr@ietf.org" target="_blank">lsr@ietf.org</a></span><span \
lang="EN-US"><u></u><u></u></span></p> </div>
</div>
</div>
</div>
</div>
<div>
<div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" \
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Subject:</span></b><span \
lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> \
Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04</span><span \
lang="EN-US"><u></u><u></u></span></p> </div>
</div>
</div>
</div>
</div>
<div>
<div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi Jie <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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. \
<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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<u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><a \
href="https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-03" \
target="_blank">https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-03</a> \
can now be mapped to an NRP.<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">VTN MT<u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><a \
href="https://datatracker.ietf.org/doc/html/draft-xie-lsr-isis-sr-vtn-mt" \
target="_blank">https://datatracker.ietf.org/doc/html/draft-xie-lsr-isis-sr-vtn-mt</a><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Suggestion for s/VTN/NRP using updated TEAS \
Network slicing terminology.<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">This draft updates RFC 8668 for ISIS but \
should also update the OSPF draft above.<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<pre style="break-before:page"><span lang="EN-US" style="font-family:"Courier \
New"">If each VTN is associated with a unique Flex-Algo, the Flex-Algo \
identifier could be<u></u><u></u></span></pre> <pre><span lang="EN-US" \
style="font-family:"Courier New"">reused as the identifier of the VTN in \
the control plane.<u></u><u></u></span></pre> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Kind Regards <u></u><u></u></span></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Gyan<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">On Tue, May 17, 2022 at 6:01 AM Dongjie \
(Jimmy) <jie.dong=<a href="mailto:40huawei.com@dmarc.ietf.org" \
target="_blank">40huawei.com@dmarc.ietf.org</a>> wrote:<u></u><u></u></span></p> \
</div> <blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm \
0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt"> \
<p class="MsoNormal"><span lang="EN-US">Hi Adrian, <br>
<br>
Thanks a lot for your detailed review. All your comments and suggestions look good \
and we will produce a new revision to incorporate them. <br>
<br>
And please see replies to some points inline:<br>
<br>
Best regards,<br>
Jie<br>
<br>
> -----Original Message-----<br>
> From: Adrian Farrel [mailto:<a href="mailto:adrian@olddog.co.uk" \
target="_blank">adrian@olddog.co.uk</a>]<br> > Sent: Monday, May 16, 2022 7:22 \
PM<br> > To: <a href="mailto:lsr@ietf.org" target="_blank">lsr@ietf.org</a><br>
> Cc: <a href="mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo@ietf.org" \
target="_blank"> draft-zhu-lsr-isis-sr-vtn-flexalgo@ietf.org</a><br>
> Subject: FW: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04<br>
> <br>
> Hi LSR and draft authors,<br>
> <br>
> I read this draft, and it seems to me that it provides a useful transitional<br>
> mechanism. It can obviously only support a relatively small number of VTNs<br>
> (128 due to the limited number of Flex-Algos the network devices can<br>
> support), but it looks to be a worthwhile first step because it can be \
achieved<br> > with a very minor control plane extension.<br>
> <br>
> Perhaps this document is a good first step while we work on a longer term<br>
> and more scalable control plane solution. It would also give us the chance \
to<br> > determine the level of interest in VTNs.<br>
<br>
Indeed, this is exactly the purpose of this document.<br>
<br>
> <br>
> My comments, below, are mainly editorial, but there are a couple of issues<br>
> around the use of the E flag.<br>
> <br>
> Best,<br>
> Adrian<br>
> <br>
> (PS. For those of you saying "What's a VTN?" the "Virtual \
Transport<br> > Network"<br>
> is a network construct described in the TEAS WG to support Enhanced VPNs<br>
> (<a href="https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/" \
target="_blank">https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/</a>) \
and network<br> > slicing<br>
> (<a href="https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/" \
target="_blank">https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/</a>)<br>
> where it maps to a "Network Resource Partition".)<br>
> <br>
> ===<br>
> <br>
> As currently defined, I think this document needs to update RFC 8668. This \
is<br> > because that RFC says that other flags in the flag field of the Parent \
L3<br> > Neighbor Descriptor in the L2 Bundle Member Attributes TLV "MUST \
be<br> > ignored".<br>
> <br>
> That's easy enough to handle:<br>
> - You add the "updates 8668" element to the XML<br>
> - You add a final paragraph to the Abstract to say<br>
> This document updates RFC 8668 by defining a new flag in the Parent<br>
> L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.<br>
> - You add a final paragraph to the Introduction to say<br>
> This document updates [RFC8668] by defining a new flag in the Parent<br>
> L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.<br>
> [RFC8668] states that all bit fields not defined in that document<br>
> "MUST be set to zero on transmission and ignored on \
receipt".<br> > Section 3 of this document defines a new flag and \
specifies both<br> > when it is set and how it should be processed.<br>
> <br>
> However, a purist might point out that RFC 8668 should be fixed so that:<br>
> <br>
> - The unused bits are defined as reserved for future use<br>
> - The text should be updated to describe how the bits are set and handled<br>
> by implementations that don't understand them<br>
> - There should be an IANA registry for the bits<br>
> <br>
> You're not responsible for fixing RFC 8668, but you could if you want \
to.<br> > <br>
> Making this document an "update" is also important because of the \
absence<br> > of an IANA registry -- it is important to provide a way for people \
to track the<br> > bits so that there is no collision when another bit is \
defined.<br> > <br>
> You could use definitely use this document to create the necessary IANA<br>
> registry, even if you are not fixing the other parts of 8668.<br>
<br>
Thanks for your suggestion, we will make this document an update of RFC 8668 to help \
track the new flag.<br> <br>
<br>
> <br>
> ---<br>
> <br>
> Would be worth expanding "VTN" in the title to read...<br>
> Using Flex-Algo for Segment Routing based Virtual Transport Networks<br>
> <br>
> ---<br>
> <br>
> Abstract<br>
> <br>
> The first mention of "Flex-Algo" needs to have some explanation of \
the<br> > concept. Not many words, but something like...<br>
> <br>
> OLD<br>
> The topological constraints of a VTN can be defined using Flex-Algo.<br>
> NEW<br>
> The topological constraints of a VTN can be defined using Flex-Algo,<br>
> a mechanism to provide distributed constraint-path computation.<br>
> END<br>
<br>
We will add some description about Flex-Algo. <br>
<br>
<br>
> ---<br>
> <br>
> Abstract<br>
> <br>
> "SR" should be spelled out as "Segment Routing (SR)"<br>
> <br>
> ---<br>
> <br>
> Abstract<br>
> <br>
> s/L2 bundle/L2 bundles/<br>
> <br>
> ---<br>
> <br>
> 1.<br>
> <br>
> The word "traditional" has other meanings in American English and we \
are<br> > now asked to avoid using it.<br>
> <br>
> OLD<br>
> than that can be provided with traditional overlay VPNs.<br>
> NEW<br>
> than that could be provided with existing overlay VPNs techniques.<br>
> END<br>
<br>
OK, will make the change accordingly.<br>
<br>
> <br>
> ---<br>
> <br>
> 1.<br>
> <br>
> s/resource-aware SIDs/resource-aware segment identifiers (SIDs)/ s/With<br>
> segment routing/With a segment routing/ s/Segment Identifiers (SIDs) can<br>
> be used/SIDs can be used/ s/using control plane/using the control plane/<br>
> s/scalable Segment Routing (SR)/scalable SR/ s/a unique Flex-Algo/a unique<br>
> Flex-Algo [I-D.ietf-lsr-flex-algo]/<br>
> <br>
> ---<br>
> <br>
> Section 1 has just one sentence on the purpose and content of this<br>
> document.<br>
> <br>
> This document<br>
> describes a mechanism to build the SR based VTNs using SR Flex-Algo<br>
> and IGP L2 bundle with minor extensions.<br>
> <br>
> This text is fine, but rather limited.<br>
> I suggest:<br>
> - Make it a separate paragraph so that it stands out.<br>
> - Add at least two more sentences describing what is found in this<br>
> document. Probably you can just summarise what the mechanism is.<br>
> - Describe the purpose and intended use of the mechanism.<br>
> <br>
<br>
We will expand this with a few more sentences.<br>
<br>
<br>
> ---<br>
> <br>
> 1.1<br>
> <br>
> The boilerplate here is slightly wrong. Should read...<br>
> <br>
> The key words "MUST", "MUST NOT", "REQUIRED", \
"SHALL", "SHALL<br> > NOT",<br>
> "SHOULD", "SHOULD NOT", "RECOMMENDED", \
"NOT RECOMMENDED",<br> > "MAY", and<br>
> "OPTIONAL" in this document are to be interpreted as described in \
BCP<br> > 14 [RFC2119] [RFC8174] when, and only when, they appear in all<br>
> capitals, as shown here.<br>
> <br>
> ---<br>
> <br>
> 3.<br>
> <br>
> s/can be allocated with a set/can be allocated a set/<br>
> <br>
> ---<br>
> <br>
> 3.<br>
> <br>
> OLD<br>
> In order to perform constraint<br>
> based path computation for each VTN on network controller and the<br>
> ingress nodes, the resource attribute of each VTN also needs to be<br>
> advertised.<br>
> NEW<br>
> In order for a network controller or the ingress nodes to perform<br>
> constraint based path computation for each VTN, the resource<br>
> attributes of each VTN need to be advertised.<br>
> END<br>
> <br>
> ---<br>
> <br>
> 3.<br>
> <br>
> s/resource attribute of the VTN/resource attributes of the VTN/<br>
> <br>
> ---<br>
> <br>
> 3.<br>
> <br>
> OLD<br>
> The layer-3 link may or may not be a bundle of layer-2 links, as long<br>
> as it has the capability of partitioning the link resources into<br>
> different subsets for different VTNs it participates in.<br>
> NEW<br>
> The layer-3 link must have the capability of partitioning the link<br>
> resources into different subsets for the different VTNs it<br>
> participates in. It may or may not be a bundle of layer-2 links to<br>
> achieve this.<br>
> END<br>
> <br>
> ---<br>
> <br>
> 3.<br>
> <br>
> s/set of link resource allocated/set of link resources allocated/ s/the \
Parent<br> > L3 link are used/the Parent L3 link is used/<br>
> <br>
> ---<br>
> <br>
> 3.<br>
> <br>
> Add to the paragraph that begins "E flag:" ...<br>
> <br>
> Note that legacy implementations of [RFC8668] will set the E flag to<br>
> zero (clear) meaning that load balancing among component links is the<br>
> default behavior. Further, when a legacy implementation receives an<br>
> E flag that is set, it will ignore the flag and so will assume that<br>
> load balancing among component links is allowed even when the sender<br>
> has requested it to not be used.<br>
> <br>
> NOTE WELL! If this is not the behaviour you want to see, you need to do<br>
> something different with the E flag.<br>
<br>
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.<br> <br>
<br>
> <br>
> ---<br>
> <br>
> 3.<br>
> <br>
> For each virtual or physical layer-2 member link, the TE attributes<br>
> defined in [RFC5305] such as the Maximum Link Bandwidth and Admin<br>
> Groups SHOULD be advertised using the mechanism as defined in<br>
> [RFC8668].<br>
> <br>
> a. You need to say why an implementation might choose to not do this<br>
> (to explain your use of SHOULD), what the consequences would be, and<br>
> what it might do instead.<br>
> <br>
> b. s/[RFC5305]/[RFC5305],/<br>
> <br>
> c. s/Groups/Groups,/<br>
<br>
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. <br>
<br>
<br>
> <br>
> ---<br>
> <br>
> 3.<br>
> <br>
> The SR-MPLS Adj-SIDs or SRv6 End.X SIDs associated with<br>
> each of the virtual or physical Layer-2 member links SHOULD also be<br>
> advertised according to [RFC8668] and [I-D.dong-lsr-l2bundle-srv6].<br>
> <br>
> You need to say why an implementation might choose to not do this (to<br>
> explain your use of SHOULD), what the consequences would be, and what it<br>
> might do instead.<br>
<br>
The SR SIDs associated with the layer-2 member links are required in the mechanism. \
We will replace the "SHOULD" with "MUST". <br>
<br>
<br>
> <br>
> ---<br>
> <br>
> 3.<br>
> <br>
> In order to correlate the virtual or physical layer-2 member links<br>
> with the Flex-Algo ID which is used to identify the VTN, each VTN<br>
> SHOULD be assigned with a unique Admin Group (AG) or Extended Admin<br>
> Group (EAG), and the virtual or physical layer-2 member links<br>
> associated with this VTN SHOULD be configured with the AG or EAG<br>
> assigned to the VTN. The AG or EAG of the parent layer-3 link SHOULD<br>
> be set to the union of all the AGs or EAGs of its virtual or physical<br>
> layer-2 member links.<br>
> <br>
> I think the three instances of "SHOULD" here can be:<br>
> s/SHOULD be/is/<br>
> s/SHOULD be/are/<br>
> s/SHOULD be/is/<br>
> <br>
> ---<br>
> <br>
> 3.<br>
> <br>
> s/VTN, It/VTN, it/<br>
> <br>
> ---<br>
> <br>
> 4.<br>
> <br>
> s/For SR-MPLS data plane/For the SR-MPLS data plane/<br>
> <br>
> ---<br>
> <br>
> 4.<br>
> <br>
> The Adj-SIDs associated<br>
> with the virtual or physical member links of a VTN MAY be used with<br>
> the prefix-SIDs of the same VTN together to build SR-MPLS TE paths<br>
> with the topological and resource constraints of the VTN.<br>
> <br>
> I recommend s/MAY/can/<br>
> <br>
> Similarly in<br>
> <br>
> The<br>
> End.XU SIDs associated with the virtual or physical member links of a<br>
> VTN MAY be used with the SRv6 Locator prefix of the same VTN together<br>
> to build SRv6 paths with the topological and resource constraints of<br>
> the VTN.<br>
> <br>
> ---<br>
> <br>
> 4.<br>
> <br>
> s/For SRv6 data plane/For the SRv6 data plane/<br>
> <br>
> ---<br>
> <br>
> 5.<br>
> <br>
> OLD<br>
> which is related to the number of Flex-Algos defined NEW<br>
> which is related to the maximum number of Flex-Algos supported END<br>
> <br>
> OLD<br>
> described in [I-D.dong-teas-nrp-scalability].<br>
> NEW<br>
> found in [I-D.dong-teas-nrp-scalability].<br>
> END<br>
<br>
Thanks for catching this, we will update the reference in next revision.<br>
<br>
<br>
<br>
_______________________________________________<br>
Lsr mailing list<br>
<a href="mailto:Lsr@ietf.org" target="_blank">Lsr@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/lsr" \
target="_blank">https://www.ietf.org/mailman/listinfo/lsr</a><u></u><u></u></span></p>
</blockquote>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US">--
<u></u><u></u></span></p>
</div>
</div>
</div>
<div>
<div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p><span lang="EN-US" style="color:#222222"><a href="http://www.verizon.com/" \
target="_blank"><span style="color:#1155cc;border:solid windowtext \
1.0pt;padding:0cm;text-decoration:none"><img border="0" \
src="cid:180df97a8c34cd34f0f1" alt="图像已被发件人 除。" \
style="width:81px;max-width:100%"></span></a></span><span \
lang="EN-US"><u></u><u></u></span></p> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p style="margin:0cm;margin-bottom:.0001pt"><b><span lang="EN-US" \
style="font-family:"Arial",sans-serif;color:black">Gyan \
Mishra</span></b><span lang="EN-US"><u></u><u></u></span></p> <p \
style="margin:0cm;margin-bottom:.0001pt"><i><span lang="EN-US" \
style="font-family:"Georgia",serif;color:black">Network Solutions Architect \
</span></i><span lang="EN-US"><u></u><u></u></span></p> <p \
style="margin:0cm;margin-bottom:.0001pt"><i><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Georgia",serif;color:black">Email <a \
href="mailto:gyan.s.mishra@verizon.com" \
target="_blank">gyan.s.mishra@verizon.com</a></span></i><span \
lang="EN-US"><u></u><u></u></span></p> <p style="margin-bottom:12.0pt"><i><span \
lang="EN-US" style="font-family:"Georgia",serif;color:black">M 301 \
502-1347</span></i><span lang="EN-US"><u></u><u></u></span></p> </div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US">-- <u></u><u></u></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p><span lang="EN-US" style="color:#222222"><a href="http://www.verizon.com/" \
target="_blank"><span style="color:#1155cc;border:solid windowtext \
1.0pt;padding:0cm;text-decoration:none"><img border="0" \
src="cid:180df97a8c3b11963102" alt="图像已被发件人 除。" \
style="width:81px;max-width:100%"></span></a><u></u><u></u></span></p> <p \
style="margin:0cm;margin-bottom:.0001pt"><b><span lang="EN-US" \
style="font-family:"Arial",sans-serif;color:black">Gyan \
Mishra</span></b><span lang="EN-US" \
style="font-family:"Arial",sans-serif;color:black"><u></u><u></u></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><i><span lang="EN-US" \
style="font-family:"Georgia",serif;color:black">Network Solutions Architect \
</span></i><span lang="EN-US" style="color:#222222"><u></u><u></u></span></p> <p \
style="margin:0cm;margin-bottom:.0001pt"><i><span lang="EN-US" \
style="font-size:10.0pt;font-family:"Georgia",serif;color:black">Email <a \
href="mailto:gyan.s.mishra@verizon.com" \
target="_blank">gyan.s.mishra@verizon.com</a></span></i><span lang="EN-US" \
style="color:#222222"><u></u><u></u></span></p> <p \
style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm"> <i><span lang="EN-US" \
style="font-family:"Georgia",serif;color:black">M 301 \
502-1347</span></i><span lang="EN-US" style="color:black"><u></u><u></u></span></p> \
</div> <div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" \
data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><p \
style="color:rgb(34,34,34)"><a href="http://www.verizon.com/" \
style="color:rgb(17,85,204);padding-bottom:1em;display:inline-block" \
target="_blank"><img src="http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email" \
width="81" height="18" style="height:18px;width:81px"></a><br></p><p \
style="font-size:1em;margin:0px;font-family:"Verizon NHG \
DS",Arial,sans-serif;line-height:13px;color:black"><b>Gyan Mishra</b></p><p \
style="color:rgb(34,34,34);margin:0px;line-height:13px"><font face="georgia, serif" \
style="color:black;font-size:1em"><i>Network Solutions A</i></font><font \
color="#000000" face="georgia, serif"><i>rchitect </i></font></p><p \
style="color:rgb(34,34,34);margin:0px;line-height:13px"><i \
style="color:rgb(0,0,0);font-size:13px"><font face="georgia, serif">Email <a \
href="mailto:gyan.s.mishra@verizon.com" \
target="_blank">gyan.s.mishra@verizon.com</a></font></i><font color="#000000" \
face="georgia, serif"><i><br></i></font></p><p \
style="font-size:1em;margin:0px;line-height:13px;color:black"><i><font face="georgia, \
serif">M 301 502-1347<br><br></font></i></p></div><div><br></div></div></div></div></div></div></div></div></div>
["image002.jpg" (image/jpeg)]
["image001.jpg" (image/jpeg)]
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic