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

[Peter Psenak <[e-mail]>]

Hi Ketan,

please responses to some of your comments inline (##PP):

On 11/04/2022 08:25, Ketan Talaulikar wrote:
> 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.

##PP
the intent is to use FlexAlgorithms  only.

> 
> 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.

##PP
I strongly disagree.

FAD is data-pane/app independent. Participation is data-plane/app 
dependent. Base flex-algo specification is very clear about that. That 
has advantages and we do not want to modify that part.

Topology calculation for algo/data-plane needs to take both FAD and 
participation into account. You need independent calculation for each 
data-plane/app in the same algo.

The fact that the same FAD is shareable between all apps has it 
advantages and use cases - e.g. if the participation for algo X is the 
same in SR and IP data-planes, one can use SR to protect IP in that algo.


> 
> 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.

##PP
where do you see such assertion? Each flex-algo data-plane/app can be 
deployed independently.

> 
> 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?

##PP
what is the relationship? I see none.


> 
> 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.


##PP
above text does not talk about the same prefix. It talks in general how 
forwarding works in presence of multiple data-planes/apps using the same 
algo.

thanks,
Peter

> 
> 
> Thanks,
> 
> Ketan
> 
> 
> 
> On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee) 
> <acee=[e-mail] <mailto:[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 22^nd , 2022.____
> 
>     __ __
> 
>     Thanks,
>     Acee____
> 
>     _______________________________________________
>     Lsr mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
>