[as wg-member] Hi Jie,
If different topologies need to use different members of a link bundle, then the link bundle has been incorrectly defined. You should re-bundle your links according to their expected topological use and then everything just works w/o any new tech needed. "KISS" seems to apply here. It sounds from the discussion like you are trying to define a solution to a self-created problem (incorrect link-bundle definitions). Given this, I agree with the other detractors. Thanks, Chris. > On Mar 22, 2024, at 13:00, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > Jie – > Just a short summary from my POV. > Multiple people have provided input to you as to why what you are trying to > do won’t work. > I won’t repeat what has been said before. > I know you really want your solution to work – but it does not. > If you think otherwise, I think it is only because you have not yet > implemented/tested it – or you have not tested the problematic scenarios – I > provided you with one easy example. > This draft should not go forward – and I say that regardless as to whether > you are headed towards Standards track or Informational. The solution you are > advocating does not work. > Thanx for the good discussion. > Les > From: Dongjie (Jimmy) <[email protected]> > Sent: Thursday, March 21, 2024 6:32 PM > To: Peter Psenak (ppsenak) <[email protected]>; 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 Peter, > Please see inline: > From: Peter Psenak <[email protected]> > Sent: Thursday, March 21, 2024 7:39 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 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) <[email protected]> > Sent: Thursday, March 21, 2024 10:36 AM > To: Dongjie (Jimmy) <[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]> > > > Sent: Thursday, March 21, 2024 7:32 AM > > > To: [email protected]; [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 _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
