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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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