Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

[Ketan Talaulikar]

Hi Acee,

Thanks a lot for your detailed review and your suggestions. We will be
incorporating them in the next update.

Please also check inline below for further responses.


On Wed, Apr 13, 2022 at 10:39 PM Acee Lindem (acee)  wrote:

> Speaking as WG member and document shepherd:
>
>
>
> I support publication of this draft. IS-IS has had this capability for
> some time now and we need it in OSPF. The technical aspects of the draft
> are sound.
>
>
>
> One detail that I think needs to be added is the stub link metric
> corresponding to the link is not modified by acceptance of the reverse
> metric. At least this is my understanding and opinion.
>

KT> That is correct. The draft talks about router links (thanks for that
suggestion) and does not cover stub links since there are no neighbors on
those links to signal the RM in the first place.


>
>
> I also have some comments on the readability. I’ve attempted to correct
> these in the attached diff (there may be mistakes as I did this editing
> quickly).
>
>
>
>1. I don’t like the “to itself” terminology. I know what it mean since
>I’ve seen both the OSPF and IS-IS presentations on the feature. This
>constitutes most of my suggested changes.
>2. Avoid run-on sentences like the one at the end of section 2.
>3. I don’t think “use case” should be hyphenated.
>
> KT> Ack to all of the above.


>
>1. Should we really refer to “statically provisioned metrics” when in
>many case reference bandwidth is used?
>
> KT> Changed to "provisioned metric" to cover both scenarios where metric
value is specified or derived via specified reference bandwidth
configuration.

Thanks,
Ketan



>
>1.
>2. Some other editorial changes.
>
>
>
> Anyway, you can use your best judgement on these.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *Lsr  on behalf of "Acee Lindem (acee)"
> 
> *Date: *Thursday, April 7, 2022 at 3:18 PM
> *To: *"lsr@ietf.org" 
> *Cc: *"draft-ietf-lsr-ospf-reverse-met...@ietf.org" <
> draft-ietf-lsr-ospf-reverse-met...@ietf.org>
> *Subject: *[Lsr] Working Group Last Call for
> draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"
>
>
>
> This begins a Working Group Last Call for
> draft-ietf-lsr-ospf-reverse-metric. While there hasn’t been as much
> discussion as I would like on the draft,  it is filling a gap in OSPF
> corresponding to IS-IS Reverse Metric (RFC 8500).  Please review and send
> your comments, support, or objection to this list before 12 AM UTC on April
> 22nd, 2022.
>
>
>
> Thanks,
>
> Acee
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

[Ketan Talaulikar]

Hi Jeffrey,

Thanks for confirming that we are ok with this draft's relationship with
RFC8042.

Thanks,
Ketan


On Thu, Apr 14, 2022 at 12:13 AM Jeffrey (Zhaohui) Zhang 
wrote:

> Hi Ketan,
>
>
>
> My fault. When I initially grepped for it, I used “8402” instead of “8042”
> and did not find it hence the comment ☹
>
> Sorry about that.
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar 
> *Sent:* Wednesday, April 13, 2022 10:06 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* Acee Lindem (acee) ; lsr@ietf.org;
> draft-ietf-lsr-ospf-reverse-met...@ietf.org
> *Subject:* Re: Working Group Last Call for
> draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey,
>
>
>
> Could you grep for RFC8042 in this draft and then let us know what more is
> needed?
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Wed, Apr 13, 2022 at 7:18 PM Jeffrey (Zhaohui) Zhang <
> zzh...@juniper.net> wrote:
>
> Hi,
>
>
>
> I just noticed this draft, and I would like to refer to
> https://datatracker.ietf.org/doc/html/rfc8042
> 
> “OSPF Two-Part Metric”.
>
> If this has been discussed before, please point me to an existing email
> thread.
>
>
>
> It seems that in the LAN case, the two-part metric mechanism would work
> better.
>
>
>
> ++
>
> |   R0   |
>
> | Router |
>
> ++   ++
>
> (a) Physical   ^ ^ ^   (b) Layer-3   |   R0   |
>
> Topology   | | |  Topology   ++
>
>v v v   ^ ^ ^
>
>  ++| | |
>
>  | Layer 2 Switch || | |
>
>  |  (Aggregation) |+---+ | +---+
>
>  ++| | |
>
>   ^^  ^ ^ ^ ^   ^  v | v
>
>   ||  | | | |   |  +--+  |  +--+
>
>  ++|  | | | |   |  |  R1  |  |  |  R3  |
>
>  | +---+  | | | |   ++ +--+  |  +--+
>
>  v v  v v v vv   v
>
> ++  ++  ++   ++
>
> |   R1   |  |   R2   |  |   R3   |   |   R2   |
>
> | Router |  | Router |  | Router |   ++
>
> +-- -+  ++  ++
>
>
>
> The reason is, when R1’s link to the switch goes up/down, the reverse
> metric from R0 to R1 is not only determined by R1 itself – it depends on
> the capacity between R0 and the switch as well. The two-part metric
> mechanism handles that well – each router advertises its metric to/from the
> “network”, and the R0->R1 metric is the sum of the R0-network and
> network-R1 metric.
>
>
>
> It would be good for this draft to clarify its use in LAN and compare with
> the two-part-metric mechanism.
>
>
>
> Thanks.
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Thursday, April 7, 2022 3:18 PM
> *To:* lsr@ietf.org
> *Cc:* draft-ietf-lsr-ospf-reverse-met...@ietf.org
> *Subject:* [Lsr] Working Group Last Call for
> draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> This begins a Working Group Last Call for
> draft-ietf-lsr-ospf-reverse-metric. While there hasn’t been as much
> discussion as I would like on the draft,  it is filling a gap in OSPF
> corresponding to IS-IS Reverse Metric (RFC 8500).  Please review and send
> your comments, support, or objection to this list before 12 AM UTC on April
> 22nd, 2022.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
___
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

[Charles Eckel (eckelcu)]

On Apr 13, 2022, at 3:02 PM, Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>> wrote:



From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Wednesday, April 13, 2022 at 12:43 PM
To: tom petch mailto:ie...@btconnect.com>>
Cc: "lsr@ietf.org" mailto:lsr@ietf.org>>, 
"net...@ietf.org" 
mailto:net...@ietf.org>>, "Rob Wilton (rwilton)" 
mailto:rwilton=40cisco@dmarc.ietf.org>>
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt



On Wed, Apr 13, 2022 at 2:22 AM tom petch 
mailto:ie...@btconnect.com>> wrote:
From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Rob Wilton (rwilton) 
mailto:40cisco@dmarc.ietf.org>>
Sent: 11 April 2022 18:06

Hi all,

Thanks for the comments on this thread so far.  It would be nice if we are able 
to come to some sort of rough consensus to a solution.

I think that there is consensus that the YANG type ip-address (and the v4/v6 
versions) are badly named as the prominent default type name has been given to 
the unusual variant of including zone information.


The core issue: how important is it to have the typedefs align with user 
expectations?
The reason the ip-address typedef has been misused is because most people 
thought they knew
what an IP address was already.  They thought the 1000s of examples of IP 
addresses they had seen
were enough. They copied "inet:ip-address" from another YANG module they found, 
never even reading ietf-inet-types.yang.

There are lots of different SDOs creating YANG modules. Not just IETF and 
OpenConfig.
Vendors need to deal with the integration themselves.
Misalignment at the data type level, especially something as important as 
ip-address, is causing problems.

Pretending the data types are aligned is not an optimal solution.
Churning 100 or so YANG modules to use ip-address-no-zone is easier said than 
done.
IMO this is the hardest proposal to execute.

I totally agree. It is 2022 now and the world has evolved to be all about 
experiences. The NETMOD WG should be more concerned about the IETF YANG 
experience than our pedantic backward compatibility rules. Don’t get me wrong, 
these have their place but as Andy has articulated, in this case everyone 
expects the ip-address types to be the ip-addresses we all know and love. Are 
we going to let them down? I certainly hope not!!!

I support this approach. It is not ideal, and I am sure we all wish we did not 
find ourselves in this situation, but the aligning with user expectations and 
common practice seems the best way forward to me. I would also like to see 
liaisons statements summarizing the plan sent to the other standards orgs and 
industry consortiums and use IETF YANG models.

Cheers,
Charles


Thanks,
Acee


Andy


Based on the comments on this thread, it also seems likely to me that most of 
the usages of ip-address in YANG RFCs is likely to be wrong, and the intention 
was that IP addresses without zones was intended.  At a rough count, of the 
published RFC YANG models at github YangModels/standard/ietf/RFC/ to be:
86 uses of ip-address
68 uses of ipv4-address
66 uses of ipv6-address

1 use of ip-address-no-zone
4 uses of ipv4-address-no-zone
4 uses of ipv6-address-no-zone

These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
quick guess/check it looks like these 49 YANG modules may appear in 40-50 RFCs.




As is sometimes the case with the processes of the IETF, this ignores any 
issues of transition.  I have pointed out a significant number of WG that have 
modules in I-D which include no-zone, in various states, perhaps increasing 
your figures by an order of magnitude.  What are you going to do with I-D e.g. 
in the RFC Editor queue?  Haul them back?

I think that the plan below is a bad one.  I would introduce types with zone - 
that is a no-brainer - but would deprecate the existing types.

Tom Petch

As mentioned previously, it is also worth comparing this to the OpenConfig YANG 
modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone information 
and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP addresses 
in the latest OpenConfig github repository.  However, approximately a third of 
the IP address types are still to the ietf-inet-types.yang rather than 
openconfig-inet-types.yang, so in theory some of those 58 entries could still 
intentionally be supporting zoned IP addresses, but I would expect that the 
vast majority would not.
I do see some strong benefit if this basic type being defined in the same way 
in both IETF and OC YANG, and I believe that the OC folks have got the 
definition right.

I see that some are arguing that the zone in the ip-address definition is 
effectively optional, and implementations are not really obliged to 

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

[Acee Lindem (acee)]

From: netmod  on behalf of Andy Bierman 

Date: Wednesday, April 13, 2022 at 12:43 PM
To: tom petch 
Cc: "lsr@ietf.org" , "net...@ietf.org" , "Rob 
Wilton (rwilton)" 
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt



On Wed, Apr 13, 2022 at 2:22 AM tom petch 
mailto:ie...@btconnect.com>> wrote:
From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Rob Wilton (rwilton) 
mailto:40cisco@dmarc.ietf.org>>
Sent: 11 April 2022 18:06

Hi all,

Thanks for the comments on this thread so far.  It would be nice if we are able 
to come to some sort of rough consensus to a solution.

I think that there is consensus that the YANG type ip-address (and the v4/v6 
versions) are badly named as the prominent default type name has been given to 
the unusual variant of including zone information.


The core issue: how important is it to have the typedefs align with user 
expectations?
The reason the ip-address typedef has been misused is because most people 
thought they knew
what an IP address was already.  They thought the 1000s of examples of IP 
addresses they had seen
were enough. They copied "inet:ip-address" from another YANG module they found, 
never even reading ietf-inet-types.yang.

There are lots of different SDOs creating YANG modules. Not just IETF and 
OpenConfig.
Vendors need to deal with the integration themselves.
Misalignment at the data type level, especially something as important as 
ip-address, is causing problems.

Pretending the data types are aligned is not an optimal solution.
Churning 100 or so YANG modules to use ip-address-no-zone is easier said than 
done.
IMO this is the hardest proposal to execute.

I totally agree. It is 2022 now and the world has evolved to be all about 
experiences. The NETMOD WG should be more concerned about the IETF YANG 
experience than our pedantic backward compatibility rules. Don’t get me wrong, 
these have their place but as Andy has articulated, in this case everyone 
expects the ip-address types to be the ip-addresses we all know and love. Are 
we going to let them down? I certainly hope not!!!

Thanks,
Acee


Andy


Based on the comments on this thread, it also seems likely to me that most of 
the usages of ip-address in YANG RFCs is likely to be wrong, and the intention 
was that IP addresses without zones was intended.  At a rough count, of the 
published RFC YANG models at github YangModels/standard/ietf/RFC/ to be:
86 uses of ip-address
68 uses of ipv4-address
66 uses of ipv6-address

1 use of ip-address-no-zone
4 uses of ipv4-address-no-zone
4 uses of ipv6-address-no-zone

These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
quick guess/check it looks like these 49 YANG modules may appear in 40-50 RFCs.




As is sometimes the case with the processes of the IETF, this ignores any 
issues of transition.  I have pointed out a significant number of WG that have 
modules in I-D which include no-zone, in various states, perhaps increasing 
your figures by an order of magnitude.  What are you going to do with I-D e.g. 
in the RFC Editor queue?  Haul them back?

I think that the plan below is a bad one.  I would introduce types with zone - 
that is a no-brainer - but would deprecate the existing types.

Tom Petch

As mentioned previously, it is also worth comparing this to the OpenConfig YANG 
modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone information 
and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP addresses 
in the latest OpenConfig github repository.  However, approximately a third of 
the IP address types are still to the ietf-inet-types.yang rather than 
openconfig-inet-types.yang, so in theory some of those 58 entries could still 
intentionally be supporting zoned IP addresses, but I would expect that the 
vast majority would not.
I do see some strong benefit if this basic type being defined in the same way 
in both IETF and OC YANG, and I believe that the OC folks have got the 
definition right.

I see that some are arguing that the zone in the ip-address definition is 
effectively optional, and implementations are not really obliged to implement 
it.  I don't find that argument compelling, at least not with the current 
definition of ip-address in RFC 6991.  I see a clear difference between a type 
defined with an incomplete regex that may allow some invalid values and a type 
that is explicitly defined to included additional values in the allowable value 
space.  Further, I believe that a client just looking at the YANG module could 
reasonably expect a server that implements a data node using ip-address would 
be expected to support IP zones, where they are meaningful, or otherwise they 
should deviate that data node to indicate that they don't conform to the model.

We also need to be realistic as to what implementations 

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

[Gyan Mishra]

All

I support Shraddha’s Any bit draft as I think of the change as am
optimization of existing ASLA RFC 8918 and 8919 taking into account
practical deployment considerations when the application specific attribute
differs and having to set the SABM / UDABM bit mask on every link on the
network.


The focus of RFC 8918 and 8919 is to solve the issue where the application
attribute is different and that is solved with the existing specification.
The zero length bit mask only helps if all the applications use the same
link attribute.  However, now if the link attribute is different for each
application, now you have to set the SABM/UDAM bit mask on every link on
the network.  So I do see that adds operational complexity.

I do have a concern about interoperability for devices supporting ASLA and
those supporting the Any bit.

So now if two applications have different attributes would they set the RFC
8918 and 8919 SADM/UDAM bit for the particular application as well as the
new any bit or would they now just set the any bit.  This is the case where
the application link attribute differs and so need to be advertised as
ASLA.  I see section 4 talks about backwards compatibility but I would
think to conform with ASLA the SADM/UDAM application specific but still
would need to be set with the use of Any bit.

I would think that would still be necessary to disambiguate the application
using the link which was the main goal of ASLA.

As for existing ASLA deployment considerations I think BGP-LS extension for
ASLA draft below would help with PCE centralized controller push of the
ASLA as part of the stateful PCE operation in mix environments with many
applications.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-app-specific-attr-08



Kind Regards

Gyan

On Fri, Apr 8, 2022 at 8:03 AM Christian Hopps  wrote:

>
> Robert Raszuk  writes:
>
> > Hi Chris,
> >
> > It seems that there is a subtle but important element on which we may
> > have different opinion.
> >
> > You said: "has to deploy new software that contains the new Wizbang
> > feature, right?"
> >
> > IMO however we are dealing with case where software already supports
> > all required functions on a box. It is just not using it from day
> > one. You buy a router with OS features which allow you to build zoo
> > of different forwarding paradigms.
> >
> > Say day one you see a need to enable flex-algo_1 You enable day one
> > links to distribute link attributes required for this.
> >
> > Day two you want to define new FAD and flood this enabling new
> > flex-algo_2. You reuse already present link attributes entirely or
> > partially in flex-algo_2 computation. You do not need to
> > touch 10s of links each time you enable new flex_algo.
>
> This is purely user interface code, you can do this w/o changing the on
> the wire standard encoding.
>
> Thanks,
> Chris.
> [as wg-member]
>
> > That's a selling point to me.
> >
> > If we would expect that folks will limit flex-algo to just a few
> > maybe this all does not matter. But if we see proposals with rainbow
> > of colors each mapped to different flex-algo and perhaps subtle
> > forwarding difference (same metric but just a different min threshold
> > per each flex-algo) it seems pretty bad idea to explicitly enable
> > each app each time such new threshold used to build different
> > topology.
> >
> > Example:
> >
> > link attribute:  delay
> >
> > applications:
> >
> > flex-algo_1 - build topology where max delay does not exceed 10 ms -
> > color: premium best effort
> > flex-algo_2 - build topology where max delay does not exceed 8 ms -
> > color: black
> > flex-algo_3 - build topology where max delay does not exceed 6 ms -
> > color: bronze
> > flex-algo_4 - build topology where max delay does not exceed 4 ms -
> > color: blue
> > flex-algo_5 - build topology where max delay does not exceed 3 ms -
> > color: silver
> > flex-algo_6 - build topology where max delay does not exceed 3 ms -
> > color: gold
> >
> > etc ...
> >
> > Now tell me how does it make sense to enable each app on the link
> > delay attribute ?
> >
> > Cheers,
> > Robert
> >
> >
> >
> > On Sat, Mar 26, 2022 at 6:42 AM Christian Hopps 
> > wrote:
> >
> >
> > Robert Raszuk  writes:
> >
> > > Les,
> > >
> > > I don't think this is noise.
> > >
> > > Your examples are missing key operational consideration .. Link
> > > attribute applicable to ANY application may be advertised well
> > ahead
> > > of enabling such application in a network.
> > >
> > > So requesting operator to always advertise tuple of app + attr
> > is not
> > > looking forward and makes unnecessary operational burden.
> >
> > [as wg-member]
> >
> > Hi Robert,
> >
> > Originally this was the argument that sort of put wind in the
> > sails (for me) for this any bit, but some more thinking about how
> > things would really work changed my mind.
> >
> > In order for some new feature, let's 

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

[Jeffrey (Zhaohui) Zhang]

Hi Ketan,

My fault. When I initially grepped for it, I used “8402” instead of “8042” and 
did not find it hence the comment ☹
Sorry about that.

Jeffrey



Juniper Business Use Only
From: Ketan Talaulikar 
Sent: Wednesday, April 13, 2022 10:06 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-ietf-lsr-ospf-reverse-met...@ietf.org
Subject: Re: Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - 
"OSPF Reverse Metric"

[External Email. Be cautious of content]

Hi Jeffrey,

Could you grep for RFC8042 in this draft and then let us know what more is 
needed?

Thanks,
Ketan


On Wed, Apr 13, 2022 at 7:18 PM Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Hi,

I just noticed this draft, and I would like to refer to 
https://datatracker.ietf.org/doc/html/rfc8042
 “OSPF Two-Part Metric”.
If this has been discussed before, please point me to an existing email thread.

It seems that in the LAN case, the two-part metric mechanism would work better.

++
|   R0   |
| Router |
++   ++
(a) Physical   ^ ^ ^   (b) Layer-3   |   R0   |
Topology   | | |  Topology   ++
   v v v   ^ ^ ^
 ++| | |
 | Layer 2 Switch || | |
 |  (Aggregation) |+---+ | +---+
 ++| | |
  ^^  ^ ^ ^ ^   ^  v | v
  ||  | | | |   |  +--+  |  +--+
 ++|  | | | |   |  |  R1  |  |  |  R3  |
 | +---+  | | | |   ++ +--+  |  +--+
 v v  v v v vv   v
++  ++  ++   ++
|   R1   |  |   R2   |  |   R3   |   |   R2   |
| Router |  | Router |  | Router |   ++
+-- -+  ++  ++

The reason is, when R1’s link to the switch goes up/down, the reverse metric 
from R0 to R1 is not only determined by R1 itself – it depends on the capacity 
between R0 and the switch as well. The two-part metric mechanism handles that 
well – each router advertises its metric to/from the “network”, and the R0->R1 
metric is the sum of the R0-network and network-R1 metric.

It would be good for this draft to clarify its use in LAN and compare with the 
two-part-metric mechanism.

Thanks.
Jeffrey



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Thursday, April 7, 2022 3:18 PM
To: lsr@ietf.org
Cc: 
draft-ietf-lsr-ospf-reverse-met...@ietf.org
Subject: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - 
"OSPF Reverse Metric"

[External Email. Be cautious of content]

This begins a Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric. 
While there hasn’t been as much discussion as I would like on the draft,  it is 
filling a gap in OSPF corresponding to IS-IS Reverse Metric (RFC 8500).  Please 
review and send your comments, support, or objection to this list before 12 AM 
UTC on April 22nd, 2022.

Thanks,
Acee

___
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 Wed, Apr 13, 2022 at 2:22 AM tom petch  wrote:

> From: netmod  on behalf of Rob Wilton (rwilton)
> 
> Sent: 11 April 2022 18:06
>
> Hi all,
>
> Thanks for the comments on this thread so far.  It would be nice if we are
> able to come to some sort of rough consensus to a solution.
>
> I think that there is consensus that the YANG type ip-address (and the
> v4/v6 versions) are badly named as the prominent default type name has been
> given to the unusual variant of including zone information.
>
>

The core issue: how important is it to have the typedefs align with user
expectations?
The reason the ip-address typedef has been misused is because most people
thought they knew
what an IP address was already.  They thought the 1000s of examples of IP
addresses they had seen
were enough. They copied "inet:ip-address" from another YANG module they
found, never even reading ietf-inet-types.yang.

There are lots of different SDOs creating YANG modules. Not just IETF and
OpenConfig.
Vendors need to deal with the integration themselves.
Misalignment at the data type level, especially something as important as
ip-address, is causing problems.

Pretending the data types are aligned is not an optimal solution.
Churning 100 or so YANG modules to use ip-address-no-zone is easier said
than done.
IMO this is the hardest proposal to execute.


Andy



> Based on the comments on this thread, it also seems likely to me that most
> of the usages of ip-address in YANG RFCs is likely to be wrong, and the
> intention was that IP addresses without zones was intended.  At a rough
> count, of the published RFC YANG models at github
> YangModels/standard/ietf/RFC/ to be:
> 86 uses of ip-address
> 68 uses of ipv4-address
> 66 uses of ipv6-address
>
> 1 use of ip-address-no-zone
> 4 uses of ipv4-address-no-zone
> 4 uses of ipv6-address-no-zone
>
> These types appear in 49 out of the 141 YANG modules published in RFCs.
> At a quick guess/check it looks like these 49 YANG modules may appear in
> 40-50 RFCs.
>
>
> 
>
> As is sometimes the case with the processes of the IETF, this ignores any
> issues of transition.  I have pointed out a significant number of WG that
> have modules in I-D which include no-zone, in various states, perhaps
> increasing your figures by an order of magnitude.  What are you going to do
> with I-D e.g. in the RFC Editor queue?  Haul them back?
>
> I think that the plan below is a bad one.  I would introduce types with
> zone - that is a no-brainer - but would deprecate the existing types.
>
> Tom Petch
>
> As mentioned previously, it is also worth comparing this to the OpenConfig
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the
> ietf-inet-types.yang rather than openconfig-inet-types.yang, so in theory
> some of those 58 entries could still intentionally be supporting zoned IP
> addresses, but I would expect that the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same
> way in both IETF and OC YANG, and I believe that the OC folks have got the
> definition right.
>
> I see that some are arguing that the zone in the ip-address definition is
> effectively optional, and implementations are not really obliged to
> implement it.  I don't find that argument compelling, at least not with the
> current definition of ip-address in RFC 6991.  I see a clear difference
> between a type defined with an incomplete regex that may allow some invalid
> values and a type that is explicitly defined to included additional values
> in the allowable value space.  Further, I believe that a client just
> looking at the YANG module could reasonably expect a server that implements
> a data node using ip-address would be expected to support IP zones, where
> they are meaningful, or otherwise they should deviate that data node to
> indicate that they don't conform to the model.
>
> We also need to be realistic as to what implementations will do.  They are
> not going to start writing code to support zones just because they are in
> the model.  They will mostly reject IP addresses with zone information.
> Perhaps some will deviate the type to ip-address-no-zone, but probably most
> won't.
>
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel at
> all appealing.  This would take a significant amount of time/effort and I
> think that we will struggle to find folks who are willing to do this.
> Although errata could be used to point out the bug, then can't be used to
> fix it, all the errata would be "hold for document update" at best.
> Further, during the time that it would take us to fix it, it is plausible
> that more 

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

[Ketan Talaulikar]

Hi Jeffrey,

Could you grep for RFC8042 in this draft and then let us know what more is
needed?

Thanks,
Ketan


On Wed, Apr 13, 2022 at 7:18 PM Jeffrey (Zhaohui) Zhang 
wrote:

> Hi,
>
>
>
> I just noticed this draft, and I would like to refer to
> https://datatracker.ietf.org/doc/html/rfc8042 “OSPF Two-Part Metric”.
>
> If this has been discussed before, please point me to an existing email
> thread.
>
>
>
> It seems that in the LAN case, the two-part metric mechanism would work
> better.
>
>
>
> ++
>
> |   R0   |
>
> | Router |
>
> ++   ++
>
> (a) Physical   ^ ^ ^   (b) Layer-3   |   R0   |
>
> Topology   | | |  Topology   ++
>
>v v v   ^ ^ ^
>
>  ++| | |
>
>  | Layer 2 Switch || | |
>
>  |  (Aggregation) |+---+ | +---+
>
>  ++| | |
>
>   ^^  ^ ^ ^ ^   ^  v | v
>
>   ||  | | | |   |  +--+  |  +--+
>
>  ++|  | | | |   |  |  R1  |  |  |  R3  |
>
>  | +---+  | | | |   ++ +--+  |  +--+
>
>  v v  v v v vv   v
>
> ++  ++  ++   ++
>
> |   R1   |  |   R2   |  |   R3   |   |   R2   |
>
> | Router |  | Router |  | Router |   ++
>
> +-- -+  ++  ++
>
>
>
> The reason is, when R1’s link to the switch goes up/down, the reverse
> metric from R0 to R1 is not only determined by R1 itself – it depends on
> the capacity between R0 and the switch as well. The two-part metric
> mechanism handles that well – each router advertises its metric to/from the
> “network”, and the R0->R1 metric is the sum of the R0-network and
> network-R1 metric.
>
>
>
> It would be good for this draft to clarify its use in LAN and compare with
> the two-part-metric mechanism.
>
>
>
> Thanks.
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Thursday, April 7, 2022 3:18 PM
> *To:* lsr@ietf.org
> *Cc:* draft-ietf-lsr-ospf-reverse-met...@ietf.org
> *Subject:* [Lsr] Working Group Last Call for
> draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> This begins a Working Group Last Call for
> draft-ietf-lsr-ospf-reverse-metric. While there hasn’t been as much
> discussion as I would like on the draft,  it is filling a gap in OSPF
> corresponding to IS-IS Reverse Metric (RFC 8500).  Please review and send
> your comments, support, or objection to this list before 12 AM UTC on April
> 22nd, 2022.
>
>
>
> Thanks,
>
> Acee
>
>
>
___
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"

[Ketan Talaulikar]

Hi Peter,

I would still reiterate the need to clarify the usage of "application"
terminology in the base FlexAlgo spec. We don't need to call it
"data-plane", I was suggesting "forwarding mechanism" or it can be
something else as well.

Just my 2c

Thanks,
Ketan


On Wed, Apr 13, 2022 at 2:35 PM Peter Psenak  wrote:

> Hi Ketan,
>
> please see inline (##PP4):
>
>
> On 13/04/2022 10:52, Ketan Talaulikar wrote:
> > 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  > > 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 statement that you have provided
> > is not
> >  > covered in either draft-ietf-lsr-flex-algo or this document. For
> >  > starters, this needs to be clarified and covered so that it gets
> the
> >  > attention of any reader during the review. This has implications
> for
> >  > implementations.
> >
> > ##PP3
> > sure we can add it explicitly there, but if you read the base
> flex-algo
> > draft carefully, it is quite clear. I will add that 

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

[Jeffrey (Zhaohui) Zhang]

Hi,

I just noticed this draft, and I would like to refer to 
https://datatracker.ietf.org/doc/html/rfc8042 "OSPF Two-Part Metric".
If this has been discussed before, please point me to an existing email thread.

It seems that in the LAN case, the two-part metric mechanism would work better.

++
|   R0   |
| Router |
++   ++
(a) Physical   ^ ^ ^   (b) Layer-3   |   R0   |
Topology   | | |  Topology   ++
   v v v   ^ ^ ^
 ++| | |
 | Layer 2 Switch || | |
 |  (Aggregation) |+---+ | +---+
 ++| | |
  ^^  ^ ^ ^ ^   ^  v | v
  ||  | | | |   |  +--+  |  +--+
 ++|  | | | |   |  |  R1  |  |  |  R3  |
 | +---+  | | | |   ++ +--+  |  +--+
 v v  v v v vv   v
++  ++  ++   ++
|   R1   |  |   R2   |  |   R3   |   |   R2   |
| Router |  | Router |  | Router |   ++
+-- -+  ++  ++

The reason is, when R1's link to the switch goes up/down, the reverse metric 
from R0 to R1 is not only determined by R1 itself - it depends on the capacity 
between R0 and the switch as well. The two-part metric mechanism handles that 
well - each router advertises its metric to/from the "network", and the R0->R1 
metric is the sum of the R0-network and network-R1 metric.

It would be good for this draft to clarify its use in LAN and compare with the 
two-part-metric mechanism.

Thanks.
Jeffrey



Juniper Business Use Only
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Thursday, April 7, 2022 3:18 PM
To: lsr@ietf.org
Cc: draft-ietf-lsr-ospf-reverse-met...@ietf.org
Subject: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - 
"OSPF Reverse Metric"

[External Email. Be cautious of content]

This begins a Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric. 
While there hasn't been as much discussion as I would like on the draft,  it is 
filling a gap in OSPF corresponding to IS-IS Reverse Metric (RFC 8500).  Please 
review and send your comments, support, or objection to this list before 12 AM 
UTC on April 22nd, 2022.

Thanks,
Acee

___
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

[Rob Wilton (rwilton)]

Hi Tom,

Please see inline ...

> -Original Message-
> From: tom petch 
> Sent: 13 April 2022 10:22
> To: Rob Wilton (rwilton) ; net...@ietf.org;
> lsr@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-
> yang-10.txt
> 
> From: netmod  on behalf of Rob Wilton
> (rwilton) 
> Sent: 11 April 2022 18:06
> 
> Hi all,
> 
> Thanks for the comments on this thread so far.  It would be nice if we are
> able to come to some sort of rough consensus to a solution.
> 
> I think that there is consensus that the YANG type ip-address (and the v4/v6
> versions) are badly named as the prominent default type name has been
> given to the unusual variant of including zone information.
> 
> Based on the comments on this thread, it also seems likely to me that most
> of the usages of ip-address in YANG RFCs is likely to be wrong, and the
> intention was that IP addresses without zones was intended.  At a rough
> count, of the published RFC YANG models at github
> YangModels/standard/ietf/RFC/ to be:
> 86 uses of ip-address
> 68 uses of ipv4-address
> 66 uses of ipv6-address
> 
> 1 use of ip-address-no-zone
> 4 uses of ipv4-address-no-zone
> 4 uses of ipv6-address-no-zone
> 
> These types appear in 49 out of the 141 YANG modules published in RFCs.  At
> a quick guess/check it looks like these 49 YANG modules may appear in 40-50
> RFCs.
> 
> 
> 
> 
> As is sometimes the case with the processes of the IETF, this ignores any
> issues of transition.  I have pointed out a significant number of WG that have
> modules in I-D which include no-zone, in various states, perhaps increasing
> your figures by an order of magnitude.  What are you going to do with I-D
> e.g. in the RFC Editor queue?  Haul them back?

I think that depends on what consensus is reached.

I have no desire of trying to republish existing RFCs to either change 
"ip-address" to "ip-address-no-zone" or to change "ip-address-no-zone" to 
"ip-address".  I think the pragmatic thing to do would be to potentially flag 
these as errata so that they are hopefully fixed if/when the YANG module is 
eventually updated.

Entirely separately from this specific discussion, it would be good if we (the 
IETF) could come up with a better long-term plan for maintaining and evolving 
IETF YANG modules.


> 
> I think that the plan below is a bad one.  I would introduce types with zone -
> that is a no-brainer - but would deprecate the existing types.

Why is deprecating an existing type a problem?  It is deprecated, not obsolete.

It does not mean that modules can't use "ip-address-no-zone", it would just 
indicate that "ip-address" is the recommended type, if we get to a consensus 
where ip-address should migrate to meaning exactly the same as 
ip-address-no-zone.

There are APIs in Java that have been deprecated for 10+ years that are still 
available for use, but where the recommended is to not use them, or use a 
replacement API instead.

Regards,
Rob


> 
> Tom Petch
> 
> As mentioned previously, it is also worth comparing this to the OpenConfig
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the ietf-inet-
> types.yang rather than openconfig-inet-types.yang, so in theory some of
> those 58 entries could still intentionally be supporting zoned IP addresses,
> but I would expect that the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same way
> in both IETF and OC YANG, and I believe that the OC folks have got the
> definition right.
> 
> I see that some are arguing that the zone in the ip-address definition is
> effectively optional, and implementations are not really obliged to
> implement it.  I don't find that argument compelling, at least not with the
> current definition of ip-address in RFC 6991.  I see a clear difference 
> between
> a type defined with an incomplete regex that may allow some invalid values
> and a type that is explicitly defined to included additional values in the
> allowable value space.  Further, I believe that a client just looking at the
> YANG module could reasonably expect a server that implements a data node
> using ip-address would be expected to support IP zones, where they are
> meaningful, or otherwise they should deviate that data node to indicate that
> they don't conform to the model.
> 
> We also need to be realistic as to what implementations will do.  They are
> not going to start writing code to support zones just because they are in the
> model.  They will mostly reject IP addresses with zone information.  Perhaps
> some will deviate the type to ip-address-no-zone, but probably most won't.
> 
> The 

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

[tom petch]

From: netmod  on behalf of Rob Wilton (rwilton) 

Sent: 11 April 2022 18:06

Hi all,

Thanks for the comments on this thread so far.  It would be nice if we are able 
to come to some sort of rough consensus to a solution.

I think that there is consensus that the YANG type ip-address (and the v4/v6 
versions) are badly named as the prominent default type name has been given to 
the unusual variant of including zone information.

Based on the comments on this thread, it also seems likely to me that most of 
the usages of ip-address in YANG RFCs is likely to be wrong, and the intention 
was that IP addresses without zones was intended.  At a rough count, of the 
published RFC YANG models at github YangModels/standard/ietf/RFC/ to be:
86 uses of ip-address
68 uses of ipv4-address
66 uses of ipv6-address

1 use of ip-address-no-zone
4 uses of ipv4-address-no-zone
4 uses of ipv6-address-no-zone

These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
quick guess/check it looks like these 49 YANG modules may appear in 40-50 RFCs.




As is sometimes the case with the processes of the IETF, this ignores any 
issues of transition.  I have pointed out a significant number of WG that have 
modules in I-D which include no-zone, in various states, perhaps increasing 
your figures by an order of magnitude.  What are you going to do with I-D e.g. 
in the RFC Editor queue?  Haul them back?

I think that the plan below is a bad one.  I would introduce types with zone - 
that is a no-brainer - but would deprecate the existing types.

Tom Petch

As mentioned previously, it is also worth comparing this to the OpenConfig YANG 
modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone information 
and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP addresses 
in the latest OpenConfig github repository.  However, approximately a third of 
the IP address types are still to the ietf-inet-types.yang rather than 
openconfig-inet-types.yang, so in theory some of those 58 entries could still 
intentionally be supporting zoned IP addresses, but I would expect that the 
vast majority would not.
I do see some strong benefit if this basic type being defined in the same way 
in both IETF and OC YANG, and I believe that the OC folks have got the 
definition right.

I see that some are arguing that the zone in the ip-address definition is 
effectively optional, and implementations are not really obliged to implement 
it.  I don't find that argument compelling, at least not with the current 
definition of ip-address in RFC 6991.  I see a clear difference between a type 
defined with an incomplete regex that may allow some invalid values and a type 
that is explicitly defined to included additional values in the allowable value 
space.  Further, I believe that a client just looking at the YANG module could 
reasonably expect a server that implements a data node using ip-address would 
be expected to support IP zones, where they are meaningful, or otherwise they 
should deviate that data node to indicate that they don't conform to the model.

We also need to be realistic as to what implementations will do.  They are not 
going to start writing code to support zones just because they are in the 
model.  They will mostly reject IP addresses with zone information.  Perhaps 
some will deviate the type to ip-address-no-zone, but probably most won't.

The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
appealing.  This would take a significant amount of time/effort and I think 
that we will struggle to find folks who are willing to do this.  Although 
errata could be used to point out the bug, then can't be used to fix it, all 
the errata would be "hold for document update" at best.  Further, during the 
time that it would take us to fix it, it is plausible that more incorrect 
usages of ip-address will likely occur (but perhaps could be policed via 
scripted checks/warnings).


I still feel the right long-term solution here is to get to a state where the 
"ip-address" type means what 99% of people expect it to mean, i.e., excluding 
zone information.

Given the pushback on making a single non-backwards compatible change to the 
new definition, I want to ask whether the following might be a possible path 
that gains wider consensus:

(1) In RFC 6991 bis, I propose that we:
(i) define new ip-address-with-zone types (and v4 and v6 versions) and keep the 
-no-zone versions.
(ii) we change the description of "ip-address" to indicate:
- Although the type allows for zone information, many implementations are 
unlikely to accept zone information in most scenarios (i.e., so the description 
of the type more accurately reflects reality).
- A new ip-address-with-zone type has been introduced to use where zoned IP 
addresses are required/useful, and models that use 

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

[Ketan Talaulikar]

Hi Robert,

Please check inline below with KT4.


On Wed, Apr 13, 2022 at 1:31 PM Robert Raszuk  wrote:

> Hi Ketan,
>
> > KT2> I see the primary use case for IP FlexAlgo (or another data plane)
>> > to be that the data plane is used by itself. In the (rare?) case where
>> > multiple data planes are required to coexist, it is simpler both from
>> > implementation and deployment POV to use different algos. It would be
>> > good to have operator inputs here. The only cost that I see for this is
>> > that the same FAD may get advertised twice only in the case where it is
>> > identical for multiple data planes. So I am still not seeing the
>> benefit
>> > of enabling multiple (i.e. per data plane) computations for a single
>> > algo rather than just keeping it a single computation per algo where a
>> > single data plane is associated with a specific algo.
>>
>> ##PP3
>> I really do not see the problem. As you stated above repeating the same
>> FAD for multiple algos would be inefficient. The beauty of FAD is that
>> it is app independent and can be used by many of them.
>>
>
>
> As I had very same doubts as you I think the advantage here is that even
> for the same FAD you can have different links attribute/metric values
> advertised on a per "app" basis.
>

KT4> This is not possible. Please check my response (KT3) to Peter. All of
FlexAlgo is a single "app" when it comes to link attributes using ASLA. So
one cannot advertise different link attributes for different FlexAlgo
forwarding mechanisms (i.e. SR or IP) when they are using the same algo and
sharing the FAD.


> Hence you may effectively get different topologies on a per "application"
> basis while still using same algorithm.
>

KT4> We get different topologies only via separate signaling of Node
Participation in a given "FlexAlgo forwarding mechanism" (I don't use the
term "application" here) - i.e. SR Algo TLV and IP Algo TLV.


>
> Again as I and others said it few times the name "app" is badly chosen to
> describe forwarding behaviour in data plane but I guess no one is going to
> listen and change that name now :)
>

KT4> I've suggested a proposal to clarify in my response to Peter.
Unfortunately, the "application" in ASLA may be too late to change, but we
have the opportunity to clarify in the base FlexAlgo as well as this spec.


>
> Practically if folks will use different algorithms to construct different
> topologies or use the same algorithm with different metrics all depends on
> what real user _applications_ the network is to carry modulo what
> flexibility network elements used to construct such network provide.
>

KT4> So the questions are really as follows:
Q1) Why would an operator want to enable FlexAlgo with IP forwarding in a
network where they can as well do SR forwarding based FlexAlgo?
Q2) When both IP and SR Forwarding based FlexAlgo are sharing the same algo
value, an implementation would need to perform separate computations when
the node participation is different for the two forwarding mechanisms. In
this case, is it still better to use the same algo or ok to use different
algo values from an operational perspective (monitoring, troubleshooting,
management, etc.)?

Thanks,
Ketan


>
> Thx,
> R.
>
>
___
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"

[Peter Psenak]

Hi Ketan,

please see inline (##PP4):


On 13/04/2022 10:52, Ketan Talaulikar wrote:

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 > 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 statement that you have provided
is not
 > covered in either draft-ietf-lsr-flex-algo or this document. For
 > starters, this needs to be clarified and covered so that it gets the
 > attention of any reader during the review. This has implications for
 > implementations.

##PP3
sure we can add it explicitly there, but if you read the base flex-algo
draft carefully, it is quite clear. I will add that exact statement in
the next re-spin of the base spec.


KT3> Thanks. I think we may also need to carefully scrub the use of the 
term "application" since it seems to bring out different interpretations 
thanks to the "application" in ASLA. It is better if we use the term 
"application" only in the same semantics as ASLA  - this means that 
FlexAlgo is a single "application". We can perhaps use the term "traffic 
flows" or "service flows" as an alternate for "application flows" that 
are steered over or use a FlexAlgo.  And then when it comes to Node 
Participation in a FlexAlgo, we could use the term "FlexAlgo Forwarding 
Mechanism" instead of "Applications' Forwarding for FlexAlgo". Thoughts?


##PP4
the term application is used in the base flex-algo spec from day one. It 
was chosen 

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

[Ketan Talaulikar]

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  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 statement that you have provided is not
> > covered in either draft-ietf-lsr-flex-algo or this document. For
> > starters, this needs to be clarified and covered so that it gets the
> > attention of any reader during the review. This has implications for
> > implementations.
>
> ##PP3
> sure we can add it explicitly there, but if you read the base flex-algo
> draft carefully, it is quite clear. I will add that exact statement in
> the next re-spin of the base spec.
>

KT3> Thanks. I think we may also need to carefully scrub the use of the
term "application" since it seems to bring out different interpretations
thanks to the "application" in ASLA. It is better if we use the term
"application" only in the same semantics as ASLA  - this means that
FlexAlgo is a single "application". We can perhaps use the term "traffic
flows" or "service flows" as an alternate for "application flows" that are
steered over or use a FlexAlgo.  And then when it comes to Node
Participation in a FlexAlgo, we could use the term "FlexAlgo Forwarding
Mechanism" instead of "Applications' Forwarding for FlexAlgo". Thoughts?


> >
> >
> > If your implementation does not want to support it, fine, but the
> > architecture allows it and there is/are implementation(s) that
> already
> > support it. This is not defined in this draft, it's defined in base
> > flex-algo spec.
> >
> >
> > KT2> I am not sure if it is really an option for implementation once it
> > is in the specification. And this is not about "my" implementation :-).
> > So it is not that because some implementations can do (or does) it that
> > it should be in the 

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

[Martin Björklund]

Jürgen Schönwälder  wrote:
> On Tue, Apr 12, 2022 at 04:52:41PM +0200, Martin Björklund wrote:
> > Jürgen Schönwälder  wrote:
> > 
> > [...]
> > 
> > > For me, the only sensible option (other than accepting that types are
> > > named the way they are) is to introduce ip-address-with-zone and to
> > > deprecate ip-address and stop there. Yes, this means coexistance of
> > > inet:ip-address and ip-address-with-zone until YANG is getting
> > > replaced.
> > 
> > But then what would you do with inet:host?
> >
> 
> I would define ip-address-with-zone to be the same as ip-address
> (i.e., with an optional zone index) and then I would then use
> ip-address-with-zone instead of ip-address in inet:host (like we are
> all going to replace the deprecated ip-address with either
> ip-address-with-zone or ip-address-no-zone in all modules in the
> future to avoid depending on a deprecated definition).

But if people believe that we have a big problem that ip-address may
contain a zone index, don't we have the same problem w/ inet:host?
Don't we have to deprecate also inet:host for the same reason?

(To be clear: Personally, I do not think that deprecating these
typedefs is the best solution)
 
> It does not make sense to me to have a type mandating a zone since on
> all systems I know of the zone index shows up only when needed (and
> creating yet another union seems overkill).

Did anyone suggest this?  I thought ip-address-with-zone was supposed to be
exactly what ip-address is today.



/martin


> 
> /js
> 
> PS: I guess someone will propose to use ip-address-opt-zone instead
> ip-address-with-zone. ;-)
> 
> -- 
> Jürgen Schönwälder  Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

___
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"

[Robert Raszuk]

Hi Ketan,

> KT2> I see the primary use case for IP FlexAlgo (or another data plane)
> > to be that the data plane is used by itself. In the (rare?) case where
> > multiple data planes are required to coexist, it is simpler both from
> > implementation and deployment POV to use different algos. It would be
> > good to have operator inputs here. The only cost that I see for this is
> > that the same FAD may get advertised twice only in the case where it is
> > identical for multiple data planes. So I am still not seeing the benefit
> > of enabling multiple (i.e. per data plane) computations for a single
> > algo rather than just keeping it a single computation per algo where a
> > single data plane is associated with a specific algo.
>
> ##PP3
> I really do not see the problem. As you stated above repeating the same
> FAD for multiple algos would be inefficient. The beauty of FAD is that
> it is app independent and can be used by many of them.
>


As I had very same doubts as you I think the advantage here is that even
for the same FAD you can have different links attribute/metric values
advertised on a per "app" basis. Hence you may effectively get different
topologies on a per "application" basis while still using same algorithm.

Again as I and others said it few times the name "app" is badly chosen to
describe forwarding behaviour in data plane but I guess no one is going to
listen and change that name now :)

Practically if folks will use different algorithms to construct different
topologies or use the same algorithm with different metrics all depends on
what real user _applications_ the network is to carry modulo what
flexibility network elements used to construct such network provide.

Thx,
R.
___
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"

[Peter Psenak]

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 statement that you have provided is not 
covered in either draft-ietf-lsr-flex-algo or this document. For 
starters, this needs to be clarified and covered so that it gets the 
attention of any reader during the review. This has implications for 
implementations.


##PP3
sure we can add it explicitly there, but if you read the base flex-algo 
draft carefully, it is quite clear. I will add that exact statement in 
the next re-spin of the base spec.



If your implementation does not want to support it, fine, but the
architecture allows it and there is/are implementation(s) that already
support it. This is not defined in this draft, it's defined in base
flex-algo spec.


KT2> I am not sure if it is really an option for implementation once it 
is in the specification. And this is not about "my" implementation :-). 
So it is not that because some implementations can do (or does) it that 
it should be in the specification. The determination on whether it 
should be in a specification needs to be based on the tradeoff between 
requiring multiple computations per algo with the potential benefit or 
use case that is enabled by it.


##PP3
again, this is how things have been defined from day one, and for a good 
reason. Requiring per app flex-algo even though I want to use the same 
metric and constraints for both app would be inefficient.






 >
 >
 >     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.
 >
 >
 > KT> Would this protection use case not violate the base FlexAlgo
rule
 > that the protection has to remain within the specific topology.
If there
 > is an SR data plane, then why would one want an IP data plane as
well?

##PP2
if the participation in two app/data-planes is the same for the algo,
the resulting topology is the same. If your implementation is smart, it
can only run a single computation for that case. There is no violation
here whatsoever.


KT2> If