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

[Peter Psenak <[e-mail]>]

Hi Jie,

On 02/04/2024 10:57, Dongjie (Jimmy) wrote:
>
> Hi Peter,
>
> Thanks for the quick reply.
>
> Do you mean IGP L2 bundle should be abandoned?
>
> Quote from RFC 8668:
>
> “If entities external to IS-IS wish to control traffic flows on the 
> individual physical links that comprise the Layer 2 interface bundle, 
> link attribute information about the bundle members is required.This 
> document introduces the ability for IS-IS to advertise the link 
> attributes of Layer 2 (L2) Bundle Members. “
>

no, absolutely not.

I was referring to the new E-bit.


thanks,
Peter

> Best regards,
>
> Jie
>
> *From:*Peter Psenak <[e-mail]>
> *Sent:* Tuesday, April 2, 2024 4:47 PM
> *To:* Dongjie (Jimmy) <[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 02/04/2024 10:18, Dongjie (Jimmy) wrote:
>
>     Hi Peter,
>
>     Please see inline:
>
>     *From:*Peter Psenak <[e-mail]> <mailto:[e-mail]>
>     *Sent:* Thursday, March 21, 2024 5:39 PM
>     *To:* Dongjie (Jimmy) <jie.dong=[e-mail]>
>     <mailto:jie.dong=[e-mail]>; Les Ginsberg
>     (ginsberg) <[e-mail]> <mailto:[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
>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr