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

[Ketan Talaulikar]

Hi Gyan,

I am not sure what the confusion is here. The following is how Peter and I
concluded this point. My comment was of editorial nature.

Thanks,
Ketan

>  > 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.
>
>
> KT> Let me clarify what I meant by taking the example of the abstract.
>
> OLD
>
> 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.
>
>
> NEW
>
> An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
> constraint-based paths. The base IGP Flex-Algorithm document
> specified use with Segment Routing (SR) data planes - SR MPLS and
> SRv6.
>
> This document extends IGP Flex-Algorithm, so that it can be used with
> regular IPv4 and IPv6 forwarding.

##PP2
ok

On Sat, Apr 16, 2022 at 8:07 AM Gyan Mishra  wrote:

>
> Hi Acee
>
> Fixing a typo
>
> On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra 
> 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) 
>> wrote:
>>
>>> Gyan,
>>>
>>>
>>>
>>> What is your point here? Is this a trick question?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Acee
>>>
>>>
>>>
>>> *From: *Gyan Mishra 
>>> *Date: *Friday, April 15, 2022 at 5:31 PM
>>> *To: *"Peter Psenak (ppsenak)" 
>>> *Cc: *Acee Lindem , Ketan Talaulikar <
>>> ketant.i...@gmail.com>, "draft-ietf-lsr-ip-flexa...@ietf.org" <
>>> draft-ietf-lsr-ip-flexa...@ietf.org>, "lsr@ietf.org" 
>>> *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?
>>>
>>>
>>>
>>> 

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

[Gyan Mishra]

Hi Acee

Fixing a typo

On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra  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)  wrote:
>
>> Gyan,
>>
>>
>>
>> What is your point here? Is this a trick question?
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> *From: *Gyan Mishra 
>> *Date: *Friday, April 15, 2022 at 5:31 PM
>> *To: *"Peter Psenak (ppsenak)" 
>> *Cc: *Acee Lindem , Ketan Talaulikar <
>> ketant.i...@gmail.com>, "draft-ietf-lsr-ip-flexa...@ietf.org" <
>> draft-ietf-lsr-ip-flexa...@ietf.org>, "lsr@ietf.org" 
>> *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 > 40cisco@dmarc.ietf.org> 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 

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

[Gyan Mishra]

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)  wrote:

> Gyan,
>
>
>
> What is your point here? Is this a trick question?
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Gyan Mishra 
> *Date: *Friday, April 15, 2022 at 5:31 PM
> *To: *"Peter Psenak (ppsenak)" 
> *Cc: *Acee Lindem , Ketan Talaulikar <
> ketant.i...@gmail.com>, "draft-ietf-lsr-ip-flexa...@ietf.org" <
> draft-ietf-lsr-ip-flexa...@ietf.org>, "lsr@ietf.org" 
> *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  40cisco@dmarc.ietf.org> 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
> > 

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

[Acee Lindem (acee)]

Gyan,

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

Thanks,
Acee

From: Gyan Mishra 
Date: Friday, April 15, 2022 at 5:31 PM
To: "Peter Psenak (ppsenak)" 
Cc: Acee Lindem , Ketan Talaulikar , 
"draft-ietf-lsr-ip-flexa...@ietf.org" , 
"lsr@ietf.org" 
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 
mailto:40cisco@dmarc.ietf.org>> 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 

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

[Gyan Mishra]

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

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Andy Bierman]

On Fri, Apr 15, 2022 at 12:25 PM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:

> Hi -
>
> I took a fresh look at RFC 6991, and a couple of things that have
> already been mentioned in this thread bear repetition.
>
> (1) in both the ipv4-address and ipv6-address typdefs, the zone
> is only optionally present.  This is made clear both in the
> string patterns as well as the descriptions, which state that
> it "may" be present, and clearly specify how its absence is
> to be understood.  Thus it's no surprise that their use has not
> caused any problems.  If the definitions go unchanged, there's
> no demonstrated need for any of the existing uses of these typedefs
> to be revised to employ something else, even if other typedefs
> are available that are more precisely targeted.
>
> (2) since both the ipv4-address and ipv6-address typdefs are
> used in the ip-address typedef, which is in turn used in the
> host typedef, any proposal changing the syntax or semantics
> of ipv4-address or ipv6-address  needs to deal with the potential
> collateral damage to any module (IETF or otherwise) employing
> ip-address or host.
>
> (3) since the proposed change is to narrow the syntax / semantics
> of a typedef (along with any other typdefs that directly or indirectly
> incorporate that typedef), the consequence for interoperability is
> that some values go from "MAY reject" (such is the nature of Netconf
> servers - well-formedness is not sufficient to guarantee that a server
> will accept an attempt to apply a particular value to a configuration)
> to "MUST reject" (due to the narrowed pattern and description).  This is
> where stuff breaks.
>
> (4) since ipv4-address-no-zone is derived from ipv4-address (by
> narrowing the pattern), and ipv6-address-no-zone is likewise
> derived from ipv6-address, the proposed change will also require
> these typedefs to be changed, which will in turn bubble up to
> ip-address-no-zone.
>
>
I have been using the term 'ip-address' for simplification.
I understand the actual edits are quite messy and apparently, not even
understood yet.


It still makes no sense to me to engage in making such wide-ranging
> changes affecting both specifications and implementations with a real
> risk to interoperability in order to "fix" a non-problem.
>
>
I agree that the current YANG standards do not allow for any significant
NBC change
to be introduced.  There is only "deprecate and start over with a new
identifier".
There are many components (YANG conformance, YANG import, YANG versioning,
etc.)
that need a lot more work to support "smart tooling" to fix (or at least
warn) users.



Randy
>

Andy


>
> ___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Randy Presuhn]

Hi -

I took a fresh look at RFC 6991, and a couple of things that have
already been mentioned in this thread bear repetition.

(1) in both the ipv4-address and ipv6-address typdefs, the zone
is only optionally present.  This is made clear both in the
string patterns as well as the descriptions, which state that
it "may" be present, and clearly specify how its absence is
to be understood.  Thus it's no surprise that their use has not
caused any problems.  If the definitions go unchanged, there's
no demonstrated need for any of the existing uses of these typedefs
to be revised to employ something else, even if other typedefs
are available that are more precisely targeted.

(2) since both the ipv4-address and ipv6-address typdefs are
used in the ip-address typedef, which is in turn used in the
host typedef, any proposal changing the syntax or semantics
of ipv4-address or ipv6-address  needs to deal with the potential
collateral damage to any module (IETF or otherwise) employing
ip-address or host.

(3) since the proposed change is to narrow the syntax / semantics
of a typedef (along with any other typdefs that directly or indirectly
incorporate that typedef), the consequence for interoperability is
that some values go from "MAY reject" (such is the nature of Netconf
servers - well-formedness is not sufficient to guarantee that a server
will accept an attempt to apply a particular value to a configuration)
to "MUST reject" (due to the narrowed pattern and description).  This is
where stuff breaks.

(4) since ipv4-address-no-zone is derived from ipv4-address (by
narrowing the pattern), and ipv6-address-no-zone is likewise
derived from ipv6-address, the proposed change will also require
these typedefs to be changed, which will in turn bubble up to
ip-address-no-zone.

It still makes no sense to me to engage in making such wide-ranging
changes affecting both specifications and implementations with a real
risk to interoperability in order to "fix" a non-problem.

Randy

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Andy Bierman]

On Fri, Apr 15, 2022 at 9:44 AM tom petch  wrote:

> From: netmod  on behalf of Andy Bierman <
> a...@yumaworks.com>
> Sent: 14 April 2022 22:25
>
> On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn <
> randy_pres...@alumni.stanford.edu>
> wrote:
> Hi -
>
> On 2022-04-14 1:33 PM, Andy Bierman wrote:
> >
> >
> > On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder
> >  j.schoenwael...@jacobs-university.de>
> > >> wrote:
> >
> > On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote:
> >
> >  > The proposal is for a 2 year phase to change modules
> >  > that really do want a zone index.  It is not blindly removing the
> > zone
> >  > index.
> >
> > People not reading type definitions will also not read a warning
> > signs. This is blindly removing the zone index in two years, I hardly
> > see a difference from doing the same (damage) today.
> >
> >
> > A 2 year advance notice is way more than normal in the open source world.
> >
> > There does not seem to be any consensus on the general issues or the
> > specific typedef,
> > or even agreement that OpenConfig (and RFC 4001) got it right and IETF
> > got it wrong.
> >
> > One set of data models treats a zone index as the normal case, not the
> > exception,
> > and the other treats a zone index as the exception.
> >
> > Spinning all the YANG modules that use these typedefs is not going to
> > happen,
> > and not even clear that would help with multi-SDO integration, given the
> > disconnect
> > on the design of the typedefs.
> ...
>
> Why do you believe it is necessary to revise all the YANG modules that
> use the current typedefs?  Have any interoperability problems resulted
> from the use of the current definitions?  The argument that not changing
> the substance of the current definitions would somehow result in the
> need to modify the modules that have used the current definitions is
> a paper tiger, I think.
>
> There seems to be many modules where ip-address was used
> when the intention of the WG was to use ip-address-no-zone.
>
> 
> Well, we really do not know.  We do know that in the past two years or so,
> when the meaning of ip-address has been pointed out to YANG module authors,
> most, but not all, have changed to the no-zone format, suggesting that they
> were unfamiliar with the use of zones in IPv6.  But they may have got it
> wrong,  The flavour of RFC4007 is that from now on, all IPv6 addresses will
> include a zone in their representation but since that is mostly the default
> zone and the default zone can be omitted then we do not often see zones in
> the representation.  To quote RFC4007
> ' This is accomplished by assigning, within the node,
>a distinct "zone index" to each zone of the same scope to which that
>node is attached, and by allowing all internal uses of an address to
>be qualified by a zone index.
> '
> All internal uses! that is what an implementer should be doing with YANG
> or with anything else.
>
>

I can support just "part 1" of the proposal.

Total solution:

 - provide guidelines for YANG authors and developers
- base + options approach vs. full + without-options approach
- ip-address vs. ip-address-no-zone


I retract support for my own previous suggestion of allowing the zone index
to be ignored. (!)
There should not be any special exceptions for a few typedefs.
RFC 6241 is very clear about the server requirements for returning  for
an 
request. No further comment in ietf-inet-types is needed.



> Tom Petch
>
>

Andy


> Tom Petch
>
> The easiest solution is to do nothing, and force the server implementers
> to deal with it.
> A server is obligated to check all client input.
> Any request with a zone index can be rejected instead of accepted.
> This solution is compatible with the OpenConfig typedef (unless zone index
> actually used).
>
>
>
> Randy
>
> Andy
>
>
> ___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[tom petch]

From: netmod  on behalf of Andy Bierman 

Sent: 14 April 2022 22:25

On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn 
mailto:randy_pres...@alumni.stanford.edu>> 
wrote:
Hi -

On 2022-04-14 1:33 PM, Andy Bierman wrote:
>
>
> On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder
> mailto:j.schoenwael...@jacobs-university.de>
> >>
>  wrote:
>
> On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote:
>
>  > The proposal is for a 2 year phase to change modules
>  > that really do want a zone index.  It is not blindly removing the
> zone
>  > index.
>
> People not reading type definitions will also not read a warning
> signs. This is blindly removing the zone index in two years, I hardly
> see a difference from doing the same (damage) today.
>
>
> A 2 year advance notice is way more than normal in the open source world.
>
> There does not seem to be any consensus on the general issues or the
> specific typedef,
> or even agreement that OpenConfig (and RFC 4001) got it right and IETF
> got it wrong.
>
> One set of data models treats a zone index as the normal case, not the
> exception,
> and the other treats a zone index as the exception.
>
> Spinning all the YANG modules that use these typedefs is not going to
> happen,
> and not even clear that would help with multi-SDO integration, given the
> disconnect
> on the design of the typedefs.
...

Why do you believe it is necessary to revise all the YANG modules that
use the current typedefs?  Have any interoperability problems resulted
from the use of the current definitions?  The argument that not changing
the substance of the current definitions would somehow result in the
need to modify the modules that have used the current definitions is
a paper tiger, I think.

There seems to be many modules where ip-address was used
when the intention of the WG was to use ip-address-no-zone.


Well, we really do not know.  We do know that in the past two years or so, when 
the meaning of ip-address has been pointed out to YANG module authors, most, 
but not all, have changed to the no-zone format, suggesting that they were 
unfamiliar with the use of zones in IPv6.  But they may have got it wrong,  The 
flavour of RFC4007 is that from now on, all IPv6 addresses will include a zone 
in their representation but since that is mostly the default zone and the 
default zone can be omitted then we do not often see zones in the 
representation.  To quote RFC4007
' This is accomplished by assigning, within the node,
   a distinct "zone index" to each zone of the same scope to which that
   node is attached, and by allowing all internal uses of an address to
   be qualified by a zone index.
'
All internal uses! that is what an implementer should be doing with YANG or 
with anything else.

Tom Petch

Tom Petch

The easiest solution is to do nothing, and force the server implementers to 
deal with it.
A server is obligated to check all client input.
Any request with a zone index can be rejected instead of accepted.
This solution is compatible with the OpenConfig typedef (unless zone index 
actually used).



Randy

Andy


___
netmod mailing list
net...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Dongjie (Jimmy)]

Hi Ketan, Peter,

I’ve just finished reading this thread, and think Ketan’s concerns make sense. 
Although the current Flex-Algo Definition is independent of the data plane 
encapsulation, I’m not sure if there is real benefit to use the same FAD with 
different data plane participation to cut out different topologies for path 
computation.

We used to have similar discussion on the list in December of 2020. At that 
time there was suggestion to simply use different Flex-Algo IDs with different 
data planes participation, or we may need to define per data plane Flex-Algo 
participation mechanisms for IPv4, IPv6, SR-MPLS and SRv6 respectively.

Per Flex-Algo SPF computation is straightforward for implementation and 
inter-operation, and also easy to manage and troubleshoot for operators. 
Actually a Flex-Algo ID can be seen as the identifier of the combination of the 
rules/constraints defined in FAD, and the set of nodes which participate in the 
Flex-Algo. But if one Flex-Algo can correspond to multiple topologies in the 
same network, we would need some additional identifiers for each of these 
topologies.

Thus my suggestion is also to make per Flex-Algo computation the default 
behavior. Per Flex-Algo per data plane computation could be optional.

Best regards,
Jie


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Wednesday, April 13, 2022 4:53 PM
To: Peter Psenak mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org; 
draft-ietf-lsr-ip-flexa...@ietf.org;
 Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - 
"IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Peter,

I will not press this point further if I am the only one that finds this 
complexity without any benefit. :-)

Please check inline below for some clarifications with KT3.


On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Ketan,


please see inline (##PP3):

On 13/04/2022 06:00, Ketan Talaulikar wrote:
> Hi Peter,
>
> Please check inline below with KT2. I am trimming everything other than
> the one point of continuing debate.
>
>  >  >
>  >  > 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.
>  >
>  >
>  > KT> No issue with this 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.
>  >
>  >
>  > KT> So, an implementation now needs to potentially support
> performing
>  > multiple topology computations for each algo. This is a
> complication for
>  > which I do not see the justification. Why not just pick different
>  > algorithms for different data planes for those (rare?)
> deployments where
>  > someone wants multiple data planes?
>
> ##PP2
> flex-algo architecture supports multiple apps/data-planes per algo,
> with
> unique participation per app/data-plane. That requires per-algo/per
> app/data-plane calculation. What is complicated on it?
>
>
> KT2> This specific and precise