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.
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. 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. 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. 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. 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). 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 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. But attempts to utilize the Layer 3 Flex-Algo technology to control traffic flow in an L2 topology are misguided and flawed. Les _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
