Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[Ketan Talaulikar <[e-mail]>]

Hello All,

Following are some comments on this draft:

1) Is this draft about opening the use of all IGP Algorithms for IP (Algo)
Routing or intended to be specific to Flexible Algorithms (i.e. algo
128-255) alone. I think it is important to specify the scope unambiguously.
Perhaps it makes sense to restrict the usage in this particular document to
FlexAlgorithms alone. If not, the draft probably needs an update and we
need to also cover algo 1 (Strict SPF) applicability and update the text to
refer more generically to algo-specific IP routing.

2) The relationship between the algo usage for IP FlexAlgo and other data
planes (e.g. FlexAlgo with SR) is not very clear. There arise complications
when the algo usage for IP FlexAlgo overlap with other (say SR) data planes
since the FAD is shared but the node participation is not shared. While Sec
9 suggests that we can work through these complications, I question the
need for such complexity. The FlexAlgo space is large enough to allow it to
be shared between various data planes without overlap. My suggestion would
be to neither carve out parallel algo spaces within IGPs for various types
of FlexAlgo data planes nor allow the same algo to be used by both IP and
SR data planes. So that we have a single topology computation in the IGP
for a given algo based on its FAD and data plane participation and then
when it comes to prefix calculation, the results could involve programming
of entries in respective forwarding planes based on the signaling of the
respective prefix reachabilities. The coverage of these aspects in a
dedicated section upfront will help.

3) This draft makes assertions that IGP FlexAlgo cannot be deployed without
SR. This is not true since the base IGP FlexAlgo spec explicitly opens it
up for usage outside of the SR forwarding plane. We already have BIER and
MLDP forwarding planes as users of the IGP FlexAlgo. My suggestion is to
remove such assertions from the document. It is sufficient to just say that
the document enables the use of IGP FlexAlgo for IP prefixes with native IP
forwarding.

4) The draft is mixing up "address" and "prefix" in some places. IGP path
computation is for prefixes and not addresses. There are a few instances
where "address" should be replaced by "prefix". References to RFC791 and
RFC8200 seem unnecessary.

5) The draft does not cover the actual deployment use-case or applicability
of IP FlexAlgo. The text in Sec 3 is not clear and insufficient. What is
the point/use of sending traffic to a loopback of the egress router?
Perhaps it makes sense in a deployment where IP-in-IP encapsulation is used
for delivering an overlay service? If so, would be better to clarify this.
The other deployment scenario is where "external" or "host/leaf prefixes"
are associated with a FlexAlgo to provide them a different/appropriate
routing path through the network. Yet another is the use of IP FlexAlgo
along with LDP. Sec 9 does not address the topic well enough. I would
suggest expanding and clarifying this and perhaps other such deployment use
cases (or applicability) in the document in one of the earlier sections to
provide a better context to the reader.

6) It would be better to move the common (i.e. not protocol specific) text
from 5.1 and 5.2 under 5. This might also apply to some extent to the
contents of sec 6.

7) Most of the text with MUSTs in sec 5 doesn't really make sense in
repeating - this is covered in the base FlexAlgo spec already. The only
key/important MUST is the one related to using separate algo for IP
FlexAlgo over SR data planes. See my previous comment (2) above.

8) Sec 5.1, the SHOULD needs to be MUST in the text below.

   A router receiving multiple IP Algorithm
   sub-TLVs from the same originator SHOULD select the first
   advertisement in the lowest-numbered LSP and subsequent instances of
   the IP Algorithm Sub-TLV MUST be ignored.


9) Sec 5.1, I would suggest changing the following text as indicated. Also,
perhaps add that the algo 0 MUST NOT be advertised and a receiver MUST
ignore if it receives algo 0.
OLD

   The IP Algorithm Sub-TLV could be used to advertise
   support for non-zero standard algorithms, but that is outside the
   scope of this document.

NEW

   The use of IP Algorithm Sub-TLV to advertise support for algorithms

   outside the flex-algorithm range is outside the
   scope of this document.

10) Sec 5.1, the SHOULD needs to be MUST in the text below

   The IP Algorithm TLV is optional.  It SHOULD only be advertised once
   in the Router Information Opaque LSA.


11) Sec 6. The following text is better moved into the respective
protocol sub-sections. OSPFv3 is not covered anyway by it.

   Two new top-level TLVs are defined in ISIS [ISO10589
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589>]
to advertise
   prefix reachability associated with a Flex-Algorithm.

   *  The IPv4 Algorithm Prefix Reachability TLV

   *  The IPv6 Algorithm Prefix Reachability TLV

   New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684
<https://datatracker.ietf.org/doc/html/rfc7684>] is
   defined to advertise prefix reachability associated with a Flex-
   Algorithm in OSPFv2.

12) Sec 6.1 & 6.2. There is no discussion regd the use of the Prefix
Attribute Flags sub-TLV with the new top-level TLVs.

 I think their usage MUST (or at least SHOULD) be included as it helps
determine the route type and prefix attributes that

have proven to be quite useful for various use cases and deployments.


13) Sec 6.2 what happens when the same prefix is advertised as SRv6
Locator as well as IPv6 Algo Prefix (same or conflicting algos).
Perhaps both must be ignored?

The same applies for OSPFv3 as well.


14) Sec 6.3, OSPFv2 MT-ID reference should be RFC4915. Perhaps the
range of MT should be mentioned since it is a 8 bit field here.


15) Sec 6.4, the metric field in the sub-TLV has to be 32-bit. While
24-bit is ok when the FAD uses IGP metric, it will not suffice for
other IGP metric types.


16) Sec 6.3 & 6.4, the conflict checking with base algo 0 prefix
reachability cannot be limited only to the OSPFv2/3 Extended LSAs but
should also cover the base fixed form

OSPFv2/v3 LSAs. We could use a more generic term like "normal prefix
reachability" advertisements perhaps to cover the different LSAs?


17) Sec 7 and 8, suggest to not use the term "application" to avoid
confusion with ASLA. My understanding is that there is a single
FlexAlgo application when it comes to ASLA.

Perhaps the intention here is "data plane" ?


18) The relationship between the BIER IPA and this draft needs some
clarifications - should the BIER WG be notified if they want to update
draft-ietf-bier-bar-ipa?

This (in some way) goes back to my comment (2) above.


19) Sec 8, what prevents the use of IP FlexAlgo paths programmed by
LDP as well. Or if the intention is to use them strictly for IP
forwarding only

then this needs to be clarified.


20)  The following text in Sec 9 is about using the same FlexAlgo
(with a common definition) for multiple data-planes at the same time.
The key is that we only are able to use

prefix in one algo/data-plane? I am wondering if we can improve this
text to bring this out in a better way. Or altogether remove this if
we agree to not allow sharing of algo

between different data planes to keep things simple.

   Multiple application can use the same Flex-Algorithm value at the

   same time and and as such share the FAD for it.  For example SR-MPLS
   and IP can both use such common Flex-Algorithm.  Traffic for SR-MPLS
   will be forwarded based on Flex-algorithm specific SR SIDs.  Traffic
   for IP Flex-Algorithm will be forwarded based on Flex-Algorithm
   specific prefix reachability announcements.


Thanks,

Ketan



On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee) <acee=
[e-mail]> wrote:

> This begins a WG last call for draft-ietf-lsr-ip-flexalgo-04.  The draft
> had a lot of support and discussion initially and has been stable for some
> time. Please review and send your comments, support, or objection to this
> list before 12 AM UTC on April 22nd, 2022.
>
>
>
> Thanks,
> Acee
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>