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

["Acee Lindem (acee)" <[e-mail]>]

Gyan,

What is your point here? Is this a trick question?

Thanks,
Acee

From: Gyan Mishra <[e-mail]>
Date: Friday, April 15, 2022 at 5:31 PM
To: "Peter Psenak (ppsenak)" <[e-mail]>
Cc: Acee Lindem <[e-mail]>, Ketan Talaulikar <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"


Hi Peter

My understanding is that the main goal of this draft is to be able to use flex algo over IPv4 or IPv6 data plane as that is not possible with existing Flex Algo which can only be used on SR data plane.

Is that correct or am I missing something?

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo



Abstract



   An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute

   constraint-based paths.  As currently defined, IGP Flex-Algorithm is

   used with Segment Routing (SR) data planes - SR MPLS and SRv6.

   Therefore, Flex-Algorithm cannot be deployed in the absence of SR.



   This document extends IGP Flex-Algorithm, so that it can be used for

   regular IPv4 and IPv6 prefixes.  This allows Flex-Algorithm to be

   deployed in any IP network, even in the absence of SR.

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-19


Abstract



   IGP protocols traditionally compute best paths over the network based

   on the IGP metric assigned to the links.  Many network deployments

   use RSVP-TE based or Segment Routing based Traffic Engineering to

   steer traffic over a path that is computed using different metrics or

   constraints than the shortest IGP path.  This document proposes a

   solution that allows IGPs themselves to compute constraint-based

   paths over the network.  This document also specifies a way of using

   Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets

   along the constraint-based paths.

Kind Regards

Gyan


On Mon, Apr 11, 2022 at 3:37 AM Peter Psenak <ppsenak=[e-mail]<mailto:[e-mail]>> wrote:
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]> <mailto:[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]> <mailto:[e-mail]<mailto:[e-mail]>>
>     https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
>

_______________________________________________
Lsr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsr
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347