Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Gyan Mishra <[e-mail]>]

Hi Jie

I thought about this and how applying your L2 member link extension to SR
algo would work and would it be feasible or not.

I believe subinterface would work since each subinterface has an L3 logical
IP on it so could map multiple NRPs to multiple L3 sub interfaces and that
would work as each subinterface becomes a ECMP next hop for sr algo sr-mpls
prefix sid steered path.

Let’s say for example you create a network slice and allocate a NRP ID
which maps to a subset of links that belong to a sub topology and in a case
where the subset of links have multiple link coloring being part of
multiple NRPs depicting a degree of isolation and other links let’s say
being part of a single NRP total isolation, but now wanting to be able to
extend the NRP sub topology concept to not just L3 links but L2 member
links that are part of bundles being used within the NRP SR Algo sub
topology.

SR Algo in SR-MPLS used a prefix sid next hop endpoint constraint defined
for the NRP on egress PE  with discrete label x advertise in IGP for sub
topology to be instantiated as an ECMP loose hops steered path from the SR
source node is a L3 NH construct is the problem.

SR Algo in SRv6 used a locators advertised in IGP by each nodes link
coloring for the NRP to instantiate ECMP loose hops steered path from the
SR source node along the sub topology to egress PE L3 NH locator endpoint.

The construct to build the SR Algo sub topology for both SR MPLS is L3 NH
prefix sid or SRv6 NH locator is the issue with extending SR Algo to
support L2 member links.

When you think of QOS/PHB that applies to L3 per next hop basis queuing as
well for NRP resources and not L2. Even if H-QOS was used with interfaces
and subinterfaces it would all be L3 and not L2 interfaces and
subinterfaces.

Kind Regards

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*



On Thu, Mar 21, 2024 at 9:32 PM Dongjie (Jimmy) <jie.dong=
[e-mail]> wrote:

> Hi Peter,
>
>
>
> Please see inline:
>
>
>
> *From:* Peter Psenak <[e-mail]>
> *Sent:* Thursday, March 21, 2024 7:39 PM
> *To:* Dongjie (Jimmy) <jie.dong=[e-mail]>; Les
> Ginsberg (ginsberg) <[e-mail]>; [e-mail];
> [e-mail]
> *Subject:* Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
>
>
>
> Hi Jie,
>
>
>
> On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
>
> Hi Les,
>
>
>
> Thanks for providing your opinion with an example.
>
>
>
> In your example, the default IGP metric is used, which is normally
> calculated based on bandwidth. While Flex-Algo can support metric types
> such as TE metric and delay.
>
>
>
> When Flex-Algo is used as the control plane of NRP, usually the metric
> types other than IGP metric would be used. We could add some notes about
> the selection of metric type to this document. In most cases per Flex-Algo
> metric type would not be needed.
>
>
>
> Your proposal of making each member link an L3 link is an alternative
> solution, while that would bring back the problems we discussed during the
> L2 bundle standardization, and can impact the network stability and
> scalability.
>
>
>
> Your second proposal (controller based path computation and construction)
> works for scenarios where strict TE-path SID-list is used to steer traffic
> into specific bundle member links on each hop, while traffic with Flex-Algo
> prefix SIDs will be mixed up and ECMP among the member links of the L3
> interface.
>
>
>
> So we do see there is a gap in using Flex-Algo to support NRP, and would
> like to hear feedbacks from the WG on possible solutions (including this
> one).
>
> there is no gap in Flex-algo. Flex-algo is a routing concept and as such
> only works on L3 constructs. That will not change.
>
> [Jie] Yes Flex-Algo is a routing concept and works on L3 topology, that is
> not changed. The gap is in using Flex-Algo for NRP in some scenarios.
>
>
>
> The problem is that you are trying to mix the routing (flex-algo) with the
> PHB/QOS. These are two different things.
>
> You can achieve PHP/QOS by marking the packet and give it a necessary
> treatment you need at each hop, e.g. reserve certain bandwidth to it, or
> even reserve a L2 bundle for it if that's what you want.
>
> [Jie] The concept of NRP is different from QoS, and QoS can be used within
> an NRP.  With SR based NRPs, SR SIDs are used to steer traffic to a subset
> of resources allocated to an NRP, thus Flex-Algo specific SR SID also needs
> to be able to steer traffic to the subset of resources of the associated
> NRP.
>
>
>
> Alternatively, you can classify the traffic at each hop using other
> mechanisms, but it becomes slow and problematic.
>
> [Jie] Yes people probably do not want to do per-hop classification for
> NRPs.
>
>
>
> What you propose is to overwrite the routing decision and instead of using
> the L3 outgoing interface computed based on L3 information, you install the
> specific L2 bundle member out of such L3 interface in forwatding. It works,
> because by using the L2 member of the L3 interface the traffic is forwarded
> to the same next-hop as has been calculated by the L3 routing. Nobody can
> stop you doing that locally if you wish doing so. But there is absolutely
> nothing you need from the IETF to do this. There is no need to advertise
> anything to do what you describe, as this is all a local behavior of the
> node. There is no need to add a new E-bit, and there is not even a need to
> advertise affinities for the L2 bundle members.
>
> [Jie] To me there is not change to the routing decision in L3. The member
> link is still part of the L3 outgoing interface. And the advertisement of
> the bundle member link information is to allow the controller or the
> ingress node to do TE path computation take the individual member links
> into consideration, this aligns with the usage of the L2 bundle as defined
> in their RFCs.
>
> Best regards,
>
> Jie
>
>
>
> I see no need for this draft.
>
> thanks,
> Peter
>
>
>
>
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Les Ginsberg (ginsberg) <[e-mail]> <[e-mail]>
> *Sent:* Thursday, March 21, 2024 10:36 AM
> *To:* Dongjie (Jimmy) <[e-mail]> <[e-mail]>;
> [e-mail]; [e-mail]
> *Subject:* RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
>
>
>
> Jie -
>
>
>
> Thanx for the quick response and confirming that my understanding of the
> intent of the draft is correct.
>
>
>
> Making a routing decision when the full topology information is not
> provided as input to the Decision Process leads to incorrect or sub-optimal
> routing. Here is one simple example.
>
> Consider the following simple topology (Layer 3 links):
>
>
>
>     B
>
>   /   \
>
> A       D
>
>  \   /
>
>     C
>
>
>
>
>
> All layer 3 links participate in Flex Algo 128.
>
> On both B and C, the Layer 3 link to D is an L2 bundle and the total
> bandwidth of the bundle links are the same.
>
> On link B-D, the L2 bundle member assigned to the NRP associated with flex
> algo 128 has 100 Mb of bandwidth.
>
> On link C-D, the L2 bundle member assigned to the NRP associated with flex
> algo 128 has 1 GB of bandwidth.
>
>
>
> The L3 SPF associated with algo 128 utilizes Layer 3 metric
> advertisements. Based on that, traffic from A to D will be equally balanced
> via B and C.
>
> However, what you intend is that when algo 128 traffic is forwarded by B
> it will utilize a 100 Mb link – whereas when algo 128 traffic is forwarded
> by C it will utilize a 1 Gb link.
>
> Clearly the ECMP traffic flow which is the output of the L3 SPF is
> sub-optimal.
>
>
>
> How could this be fixed?
>
>
>
> 1)Do not use L2 bundles on B and C. Make each bundle member an L3 link and
> run IS-IS on the Layer 3 interfaces. In such a case different L3 metrics
> can be advertised for each L3 link and Flex Algo 128 can be associated only
> with the desired L3 link on C and D.
>
> Standard flex-algo as defined in RFC 9350 works and requires no
> modifications.
>
>
>
> 2)Do not use L3 routing/flex algo. Define some other mechanism to mark
> packets in a way that the forwarding recognizes as mapping to the
> appropriate L2 link.
>
> The L2 bundle advertisements provided by IS-IS as per RFC 8668 can be used
> by this (external to IS-IS) mechanism.
>
> For example this mechanism could use the admin group advertised for each
> L2Bundle member to determine the mapping between an NRP and a link.
>
> All of the functionality required is already defined in RFC 8668 – the
> only thing you need to define is this new mechanism – which is not part of
> IS-IS and therefore does not belong in an LSR draft.
>
>
>
> NOTE: Please do not suggest that a different metric-type can be used for
> each Flex-Algo. Such an approach does not scale as it requires as many
> metric-types as Flex-Algos – which we do not have. 😊
>
>
>
> What you MUST NOT do is use L3 routing to make a routing decision for a
> topology which is not part of the input to the routing decision process.
> But that is exactly what you are proposing in this draft.
>
>
>
> Hope this example is clear.
>
>
>
> As regards the clarity of Section 4, that section simply says (using the
> SR-MPLS text):
>
>
>
> “A forwarding entry MUST be installed in the forwarding plane using the
> MPLS label that corresponds to the Prefix-SID associated with the
> Flex-algorithm corresponding to the NRP.”
>
>
>
> But this entry must have next hops which include only the L2 links
> associated with the NRP mapped to Flex-algo 128. How this is done is not
> described – but as it requires using information advertised in the L2
> Bundle Member Descriptors this clearly cannot be done by IS-IS w/o
> violating RFC 8668. IS-IS will simply attempt to install a forwarding entry
> based on the L3 topology – which will indicate to use the L3 link. How this
> forwarding entry is discarded/overwritten is not specified. But, this is a
> problem which should never need to be solved.
>
>
>
>    Les
>
>
>
>
>
>
>
> > -----Original Message-----
>
> > From: Dongjie (Jimmy) <[e-mail]>
>
> > Sent: Wednesday, March 20, 2024 4:30 PM
>
> > To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail];
> draft-zhu-lsr-
>
> > [e-mail]
>
> > Subject: RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
>
> >
>
> > Hi Les,
>
> >
>
> > Thanks for the review and comments.
>
> >
>
> > Please see some replies inline:
>
> >
>
> > > -----Original Message-----
>
> > > From: Les Ginsberg (ginsberg) <[e-mail]>
>
> > > Sent: Thursday, March 21, 2024 7:32 AM
>
> > > To: [e-mail]; [e-mail]
>
> > > Subject: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
>
> > >
>
> > > This draft discusses how to use flex-algo in support of Network
> Resource
>
> > > Partitions (NRPs). In particular, it proposes to use a combination of
> L3 links
>
> > and
>
> > > L2 Bundle member links as the topology associated with a given NRP. In
>
> > those
>
> > > cases where an L3 link is using an L2 bundle and individual bundle
> members
>
> > > are "assigned" to different NRPs, it then proposes to associate the
> parent L3
>
> > > link with multiple flex-algos. The intent seems to be to utilize the
> L3 algo
>
> > > specific SIDs to assign the traffic to subsets of the L2 Bundle
> members.
>
> >
>
> > Your reading of the intent of this document is correct.
>
> >
>
> > With the proposed mechanism, traffic with Flex-Algo specific SIDs could
> be
>
> > steered to different partitions of the L3 link resources.
>
> >
>
> > The only thing I'd like to mention is the L2 bundle members could be
> virtual or
>
> > physical, they are just used to represent different subsets of the link
> resources.
>
> >
>
> >
>
> > > This is extremely problematic.
>
> > >
>
> > > The output of the L3 algo-specific SPF will be to install nexthops
> pointing to
>
> > the
>
> > > L3 interface for packets which arrive with the L3 algo specific SID.
> But since
>
> > the
>
> > > intent is to only forward traffic for a given algo specific SID via
> specific L2
>
> > > Bundle members, the L3 forwarding entries will have to be overwritten
> - in a
>
> > > manner not specified by the draft.
>
> >
>
> > Section 4 of this document specifies the required forwarding plane
> behavior
>
> > and the forwarding entry installation.
>
> >
>
> >
>
> > > The implementation complexities this introduces arise because the
> proposed
>
> > > solution attempts to use a Layer 3 technology (flex-algo) to control
> the use
>
> > of
>
> > > L2 links. This should not be done.
>
> >
>
> > In the proposed mechanism, Flex-Algo is still used for constraint path
>
> > computation, and only the L3 links attributes are used in the
> computation. The
>
> > L2 member links are only to partition the resources used by different
> Flex-Algo
>
> > traffic.
>
> >
>
> >
>
> > > Indeed, even independent of flex-algo, trying to use a Layer 3 routing
>
> > protocol
>
> > > to control traffic flow on an L2 sub-topology is broken.
>
> > > It means that the L2 bundles have been improperly defined for use by
> the L3
>
> > > routing protocol.
>
> >
>
> > There is no routing computation based on the "L2 sub-topology", as L2
> bundle
>
> > member links are not visible in the L3DB. All the Flex-Algo computation
> is
>
> > based on the attributes of L3 links.
>
> >
>
> >
>
> > > RFC 8668 defines the advertisements of L2 Bundle member link
> attributes by
>
> > > IS-IS. The introduction of RFC 8668 states:
>
> > >
>
> > > "...the new advertisements defined in this document are intended to be
>
> > > provided to external (to IS-IS) entities."
>
> > >
>
> > > This means these advertisements are not to be used by the routing
> protocol
>
> > > itself. The association of these advertisements with the Layer 3 SIDs
> defined
>
> > by
>
> > > Flex-Algo is a clear violation of the intended use as stated by RFC
> 8668.
>
> >
>
> > As stated above, L2 bundle link attributes are not used in path
> computation.
>
> > The Flex-Algo specific SIDs still point to the L3 interface based on that
>
> > computation. The only change is that a Flex-Algo SID can further points
> to the
>
> > resource of an L2 member link (consider it as a subset of the resource
> of the L3
>
> > link if that is easier to understand). So the L2 bundle information is
> only used
>
> > for associating different Flex-Algo SIDs with different subsets of
> resources of a
>
> > l3 link.
>
> >
>
> >
>
> > > This draft should be abandoned.
>
> > >
>
> > > NOTE: None of the points above should be interpreted to mean that flex-
>
> > algo
>
> > > cannot be used in support of NRPs. (Whether that is a good idea or not
> is
>
> > out
>
> > > of scope for this discussion).
>
> >
>
> > AFAIK people are talking about using Flex-Algo to support NRPs. This
>
> > document provides a solution to meet their needs.
>
> >
>
> >
>
> > > But the proper way to do that is when the NRP maps to an L3 topology.
> Such
>
> > a
>
> > > usage is fully supported by RFC 9350 and there is no need to write an
>
> > > additional document to define how this is to be done.
>
> >
>
> > In some cases it is possible to map different NRPs to non-overlapping L3
> sub-
>
> > topologies, while in many other cases the same L3 link needs to
> participate in
>
> > multiple NRPs, each of which is assigned with a subset of the link
> resources.
>
> > The latter case cannot be supported by RFC 9350, and it is the target of
> this
>
> > document.
>
> >
>
> >
>
> > > In cases where an NRP maps to an L2 topology, some other mechanism
>
> > needs
>
> > > to be defined as to how forwarding entries for a given NRP are
> determined
>
> > and
>
> > > installed. Such a mechanism would qualify as "external to IS-IS" and
>
> > therefore
>
> > > could make use of RFC 8668 advertisements.
>
> >
>
> > This document also provides descriptions about this. As I mentioned it
> is after
>
> > L3 computation, and makes use of the L2 bundle information.
>
> >
>
> >
>
> > > But attempts to utilize the Layer 3 Flex-Algo technology to control
> traffic flow
>
> > > in an L2 topology are misguided and flawed.
>
> >
>
> > As long as Flex-Algo is used for L3 topology based computation, IMO it
> still
>
> > complies to RFC 9350.
>
> >
>
> > Best regards,
>
> > Jie (on behalf of coauthors)
>
> >
>
> > >
>
> > >    Les
>
>
>
>
>
> _______________________________________________
>
> Lsr mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>