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

[Gyan Mishra <[e-mail]>]

Hi Acee

My question cane up from the list of questions posed by Ketan and Peter’s
response to question #3.

See excerpt below.

I am confused by what Ketan stated in his question below and also Peter’s
response which is why I am asking the question again.

I believe the goal of the draft is for Flex Ago to be deployed
independently of SR filling the gap of IGP Flex Algo providing that
solution.  So based on what Ketan stated in his question that IGP Flex Algo
is data plane agnostic and can be used with IP data plane then there is no
gap to be filled by this draft.

Maybe I am misreading Ketan’s question.

So this is a very important point made by Ketan that if IGP Flex Algo is
open to usage outside Flex Algo then it is very important to restate the
goal of this draft, removing assertions in the draft that this draft is for
non SR IP data planes, as that can be accomplished today by IGP Flex Algo,
and the gap or new solution being filled by this draft is for IP prefix
based Flex Algo with Native IP Forwarding.

This as well is quite confusing to me as if IGP Flex Algo can be used
outside of SR then can do everything that this draft is supposed to
accomplish.

So what then is the purpose of this draft?

In Peter’s response is stated that each Flex Algo data plane / app can be
deployed independently meaning this draft and IGP flex Algo can act as 2
ships in the night.  Also confusing.

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.



On Fri, Apr 15, 2022 at 7:51 PM Acee Lindem (acee) <[e-mail]> wrote:

> 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]> 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]>>
> 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>
> >
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*