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

[Peter Psenak <[e-mail]>]

Hi Jie,

On 02/04/2024 10:18, Dongjie (Jimmy) wrote:
>
> Hi Peter,
>
> Please see inline:
>
> *From:*Peter Psenak <[e-mail]>
> *Sent:* Thursday, March 21, 2024 5: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] Fully agree Flex-Algo is a routing concept and works on L3 
> control plane, while it shows a gap in how to map Flex-Algos to 
> different subset of resources for network slicing. Currently traffic 
> of different Flex-Algos would share the same set of resources on the 
> L3 outgoing interfaces. *
>
> 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] QoS PHB is per-hop behavior, which cannot provide end-to-end 
> resource guarantee at NRP/Slice granularity. Consider the difference 
> between DiffServ and IntServ. And within each NRP, QoS is still needed. *
>
> *Reserving an L2 bundle member link for NRP is the approach proposed 
> in this document. *
>
> Alternatively, you can classify the traffic at each hop using other 
> mechanisms, but it becomes slow and problematic. **
>
> *[Jie] Agree that per-hop traffic classification has many problems. *
>
> 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] The distributed path computation is still based on the L3 
> links/interfaces, the change is in the forwarding entry installation. 
> Thanks for confirming it works. *
>
> *The advertisement of the L2bundle information is for the controller 
> or ingress nodes to perform path computation based on NRP-specific 
> constraints and can use Algo-specific SIDs together with bundle member 
> Adj-SIDs in building the SID list, this aligns with the usage of L2 
> bundle and extends its applicability to Flex-Algo-specific SIDs. *
>
> *The E bit is to indicate the L2 bundle is working in the exclusive 
> mode (rather than load balancing), which means the Flex-Algo SIDs can 
> be used to steer traffic to the corresponding member links. *
>
given that such information is not used during the flex-algo computation 
itself, there is no need to signal it by IGP. If the controller needs to 
know about such a property, there are other ways how it can learn about it.

thanks,
Peter


> **
>
> *Best regards,*
>
> *Jie*
>
> **
>
> I see no need for this draft.
>
> thanks,
> Peter
>
>     Best regards,
>
>     Jie
>
>     *From:*Les Ginsberg (ginsberg) <[e-mail]>
>     <mailto:[e-mail]>
>     *Sent:* Thursday, March 21, 2024 10:36 AM
>     *To:* Dongjie (Jimmy) <[e-mail]>
>     <mailto:[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]
>     <mailto:[e-mail]>>
>
>     > > Sent: Thursday, March 21, 2024 7:32 AM
>
>     > > To: [e-mail] <mailto:[e-mail]>;
>     [e-mail]
>     <mailto:[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
>