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
