Best regards,
Jie
*From:*Peter Psenak <[email protected]>
*Sent:* Tuesday, April 2, 2024 4:47 PM
*To:* Dongjie (Jimmy) <[email protected]>; Les Ginsberg (ginsberg)
<[email protected]>; [email protected];
[email protected]
*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 <[email protected]> <mailto:[email protected]>
*Sent:* Thursday, March 21, 2024 5:39 PM
*To:* Dongjie (Jimmy) <[email protected]>
<mailto:[email protected]>; Les Ginsberg
(ginsberg) <[email protected]> <mailto:[email protected]>;
[email protected]; [email protected]
*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) <[email protected]>
<mailto:[email protected]>
*Sent:* Thursday, March 21, 2024 10:36 AM
*To:* Dongjie (Jimmy) <[email protected]>
<mailto:[email protected]>; [email protected];
[email protected]
*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) <[email protected]>
> Sent: Wednesday, March 20, 2024 4:30 PM
> To: Les Ginsberg (ginsberg) <[email protected]>; [email protected];
draft-zhu-lsr-
> [email protected]
> 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) <[email protected]
<mailto:[email protected]>>
> > Sent: Thursday, March 21, 2024 7:32 AM
> > To: [email protected] <mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
> > 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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
