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

Fixing a typo

On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra <[e-mail]> wrote:

>
> 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 of SR”,  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*
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*