[Lsr] Re: Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Delay
Y
[RFC9492<https://urldefense.com/v3/__https:/www.iana.org/go/rfc9492__;!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvT7cfK2pA$>]
13
Min/Max Unidirectional Link Delay
Y
[RFC9492<https://urldefense.com/v3/__https:/www.iana.org/go/rfc9492__;!!NEt6yMaO-gk!CCtWq3oQk0cXbjdWmHoJomutLcmgPIHyX5LjNSahUulgW61QgLgqXr_Kj74WrmzBmvkbwwnzm_SiyvT7cfK2pA$>]

 Ok I got it. Will fix in -12 version



7) Regarding 
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-6<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*section-6__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumnzxX7UA$>,
 it seems like we want to retain a numbering ordering of rules/sequence for 
flex-algo as extension documents are introduced. Am I correct? If so, then this 
document should formally "update" RFC9350 since it is changing the "set of 
rules/sequence" for FlexAlgo computations. Further such extensions will also 
need to keep updating the base spec similarly. I would suggest that a full set 
of rules that is a union of what is in RFC9350 and rules added by this draft 
are maintained in an Appendix section. Other documents in the future can 
similarly maintain the latest set of rules.
 This draft is adding 2 new rules at the end of existing rules. Its not 
modifying or changing the order.
I don’t see what value it is going to add by repeating the set of rules in 
Appendix.

KT> What happens when another FlexAlgo document adds more rules? What happens 
when some FlexAlgo document wants to insert rules in the middle of existing 
ones instead of appending at the end? My point is that if there is a desire to 
establish a "live" set of rules in specific orders, then we need to leave a 
trail of document "updates" on the base FlexAlgo that one can refer to know how 
these "live set of rules" are getting "updated" by this and future documents. I 
am thinking of this on lines similar to an update for an FSM.
 It’s a matter of choice. For ex RFC 8029
Has so many updates to the Rules but each update only lists the 
changes.

KT2> I am not sure I follow and it would help if you can perhaps give an 
example.

   I am fine with whatever WG decides to do.
I want to hear if anyone in WG has an opinion on adding Appendix.

KT2> Sure. My point is that this seems like an ordered set of rules that are 
being updated by multiple documents (more to come). How does one keep track of 
the "current" set of rules without some trail or each new(er) document 
capturing the "latest" set?
 I don’t see any other opinions on mailing list. Will add appendix in -12 
with full set of rules.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar 
Sent: Saturday, April 27, 2024 11:44 AM
To: Shraddha Hegde 
Cc: Acee Lindem ; lsr ; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]

Hi Shraddha,

Please check inline below with KT2.

On Mon, Apr 15, 2024 at 12:16 PM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Hi Ketan,

Thanks for reply.
Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Monday, April 8, 2024 2:25 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: Acee Lindem mailto:acee.lin...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]

Hi Shraddha,

Thanks for your responses. Please check inline below for clarifications with KT.


On Thu, Apr 4, 2024 at 9:49 AM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Hi Ketan,

Thanks for the review and comments.
Pls see inline for replies.



Juniper Business Use Only
From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Thursday, March 21, 2024 10:07 PM
To: Acee Lindem mailto:acee.lin...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]

Hi All,

I have reviewed this document and believe it needs some further work before 
publication.

I am sharing my comments below:

1) There is the following text in sec 2.1 and 2.2 for

[Lsr] Re: Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Acee,

I believe Les and I have agreed to the text that I added and his comments are 
closed.
Les, let me know if you don't agree.

I don't agree with Ketan's comment on removing code points from OSPF TE opaque 
LSAs.
Early code points are already taken and implementations underway. If he can 
elaborate his concern
With having generic metric in opaque LSA
We can see what details need to be added in the draft.

I got some more comments from Peter. Will publish -12 soon.


Rgds
Shraddha




Juniper Business Use Only
-Original Message-
From: Acee Lindem 
Sent: Friday, May 10, 2024 12:29 AM
To: Acee Lindem 
Cc: Shraddha Hegde ; Ketan Talaulikar 
; lsr ; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org; Les Ginsberg (ginsberg) 

Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]


Any update?

Thanks,
Acee

> On Apr 26, 2024, at 11:53 AM, Acee Lindem  wrote:
>
> Hi Ketan, Shraddha and Les,
>
>
> I’m trying to conclude this thread and send this document to the AD. I’ve 
> read the Emails but I must admit I don’t understand all the arguments.
>
>
> Ketan - if we have the generic-metric in IS-IS, why wouldn’t define it in 
> OSPF as well? If you cannot provide a compelling argument, I ‘m going to 
> request publication of the document send it to the actual LSR AD.
>
> Shraddha - I see that you included similar text in section 4.3.1 to address 
> Les’s comment. I guess the example referring to Flex algo 128/129 is not 
> needed.
>
> Les - I’m sure what the I-bit but I don’t see that adding it at this juncture 
> is a good idea unless the described protocol enhancements don’t work without 
> it.
>
> Thanks,
> Acee
>
>
>
>> On Apr 15, 2024, at 02:46, Shraddha Hegde 
>>  wrote:
>>
>> Hi Ketan,
>>  Thanks for reply.
>> Pls see inline..
>>
>> Juniper Business Use Only
>> From: Ketan Talaulikar 
>> Sent: Monday, April 8, 2024 2:25 PM
>> To: Shraddha Hegde 
>> Cc: Acee Lindem ; lsr ;
>> draft-ietf-lsr-flex-algo-bw-...@ietf.org
>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms:
>> Bandwidth, Delay, Metrics and Constraints" -
>> draft-ietf-lsr-flex-algo-bw-con-07
>>  [External Email. Be cautious of content]  Hi Shraddha,  Thanks for
>> your responses. Please check inline below for clarifications with KT.
>>   On Thu, Apr 4, 2024 at 9:49 AM Shraddha Hegde  wrote:
>> Hi Ketan,
>>  Thanks for the review and comments.
>> Pls see inline for replies.
>>   Juniper Business Use Only
>> From: Ketan Talaulikar 
>> Sent: Thursday, March 21, 2024 10:07 PM
>> To: Acee Lindem 
>> Cc: lsr ; draft-ietf-lsr-flex-algo-bw-...@ietf.org
>> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms:
>> Bandwidth, Delay, Metrics and Constraints" -
>> draft-ietf-lsr-flex-algo-bw-con-07
>>  [External Email. Be cautious of content]  Hi All,  I have reviewed
>> this document and believe it needs some further work before publication.
>>  I am sharing my comments below:
>>  1) There is the following text in sec 2.1 and 2.2 for Generic Metric.
>>  A metric value of 0xFF is considered as maximum link metric and a link 
>> having this metric value MUST NOT be used during Flex-algorithm calculations 
>> [RFC9350]. The link with maximum generic metric value is not available for 
>> the use of Flexible Algorithms but is availble for other use cases.
>>  I believe the FlexAlgo reference here is to 
>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!BeudAtZGk7-XssYqte2dyPuiegf-oXoroaYsXYyIEJLEdZf1Bh4Jn5Mopid4VlitSAJoWvYiC0bPAdcSDIhyKQ$
>>But the above text does not align with the RFC9350. If a link is to be 
>> made unavailable for FlexAlgos operating with a specific Generic Metric, 
>> then the way to do that is to omit that specific Generic Metric TLV from the 
>> ASLA for flex-algo application. The same would apply for other applications 
>> - just omit the metric. Why do we need a special MAX-LINK-METRIC value for 
>> generic metric given that it is a new thing we are introducing?
>>   I see what you are saying. Text is updated as below for ISIS and 
>> similar for OSPF.
>> “A metric value of
>>0xFF is considered as maximum link metric and a link having
>>this metric value MUST be used during Flex-algorithm calculations
>>as a last resort link as described in sec 15.3 of RFC[9350]  KT>
>> Thanks - that works. Perhaps also clarify that to make the link unusable by

Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-flex-algo-bw-con-08

[Shraddha Hegde]

Hi Stewart,

Thanks for the review and comments.
Pls see inline for replies. Version -10 will address your comments


Juniper Business Use Only
-Original Message-
From: Stewart Bryant via Datatracker 
Sent: Monday, April 8, 2024 10:00 PM
To: rtg-...@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con@ietf.org; last-c...@ietf.org; 
lsr@ietf.org
Subject: Rtgdir last call review of draft-ietf-lsr-flex-algo-bw-con-08

[External Email. Be cautious of content]


Reviewer: Stewart Bryant
Review result: Has Nits

I reviewed version 08 as a RTG Area reviewer.

This is a well written document that has a few editorial issues that could 
usefully  be looked at before proceeding. Some affect the text that the reader 
will see, some affect the production process.

It is not clear that all abbreviations are expanded on first use and a detailed 
check by the editor should be carried out. The editor could usefully include a 
terminology section or a glossary to help the new reader with the 
not-officially-well-known abbreviations. I picked up ASLA, FAPM, FAEMB there 
may be others.
 I added full expansion for all acronyms on first use. Hope that helps.

=

The nits checker picked up:

  ** There are 13 instances of too long lines in the document, the longest
 one being 11 characters in excess of 72.

and

 ** Obsolete normative reference: RFC 8919 (Obsoleted by RFC 9479)

  ** Obsolete normative reference: RFC 8920 (Obsoleted by RFC 9492)

  -- Obsolete informational reference (is this intentional?): RFC 5316
 (Obsoleted by RFC 9346)

It also picked up RFC-ietf-lsr-flex-algo-bw-con-04 meaning "This RFC" perhaps 
consider that to avoid all the reviewers figuring out what is happening.

===
 Fixed
Minor English
   constraint based paths in IGP.  This draft documents a generic metric
SB> s/in/in an/

===
 Fixed

 The micro-loop avoidance procedures
   described in [I-D.bashandy-rtgwg-segment-routing-uloop] can be used
   to avoid micro-loops when the automatic metric calculation is
   deployed.
SB> Indeed, but so can any micro-loop avoidance method.
 Referred RFC 5715 as well for other possible mechanisms.

===
  A--BCFD
  |  |
   --E---

   Figure 7: Parallel interfaces

   For exmple, in the above diagram, there are two parallel links
   between B->C, C->F, F->D.  Let us assume the link bandwidth is
   uniform 10Gbps on all links and the metric for each link will be the
   same.  Traffic from B to D will be forwarded B->E->D.  Since the
   bandwidth is higher on the B->C->F->D path, the metric for that path
   should be lower, and that path should be selected.  Interface Group
   Mode is preferred in cases where there are parallel layer-3 links.

SB> This paragraph is not well expressed. Please consider rewording.
SB> I think that you man to say that the B C F D path needs to have a
SB> lower
metric than B E D to attract the traffic via B C F D, but it is not well 
expressed in the text.
 Updated the text

   In the interface group mode, every node MUST identify the set of
   parallel links between a pair of nodes based on IGP link
   advertisements and MUST consider cumulative bandwidth of the parallel
   links while arriving at the metric of each link.
SB> Of course it is a bit more subtle because there will be additional
forwarding delay in F and we need to consider ingress traffic at C, F and E.

===
 This one is not clear me. Could you pls elaborate more?

In the text you use a uniform term TBD and in IANA a uniform term TBA. For 
clarity in later stages of the publication process it might be useful to give 
each IANA parameter a unique identifier, for example TBD1, TBD2 etc.
 Fixed.  The generic metric on for same sub-TLV multiple code points are 
taken based which TLV it appears-in.
Will have to be co-ordinated with RFC editors I think.

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

Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Hi Ketan,

Thanks for reply.
Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar 
Sent: Monday, April 8, 2024 2:25 PM
To: Shraddha Hegde 
Cc: Acee Lindem ; lsr ; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]

Hi Shraddha,

Thanks for your responses. Please check inline below for clarifications with KT.


On Thu, Apr 4, 2024 at 9:49 AM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Hi Ketan,

Thanks for the review and comments.
Pls see inline for replies.



Juniper Business Use Only
From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Thursday, March 21, 2024 10:07 PM
To: Acee Lindem mailto:acee.lin...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]

Hi All,

I have reviewed this document and believe it needs some further work before 
publication.

I am sharing my comments below:

1) There is the following text in sec 2.1 and 2.2 for Generic Metric.

A metric value of 0xFF is considered as maximum link metric and a link 
having this metric value MUST NOT be used during Flex-algorithm calculations 
[RFC9350<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html*RFC9350__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmuk-veyTXw$>].
 The link with maximum generic metric value is not available for the use of 
Flexible Algorithms but is availble for other use cases.

I believe the FlexAlgo reference here is to 
https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9350.html*name-max-metric-consideration__;Iw!!NEt6yMaO-gk!DwOojW2YZ48IROz9qMyyh7uKj3rYC-09avEhFQtcPkvxJ5mKF5Cyy6qSVvDJ89s9DmAUVwsT_pgfmumv0_0Zeg$>

But the above text does not align with the RFC9350. If a link is to be made 
unavailable for FlexAlgos operating with a specific Generic Metric, then the 
way to do that is to omit that specific Generic Metric TLV from the ASLA for 
flex-algo application. The same would apply for other applications - just omit 
the metric. Why do we need a special MAX-LINK-METRIC value for generic metric 
given that it is a new thing we are introducing?

 I see what you are saying. Text is updated as below for ISIS and similar 
for OSPF.
“A metric value of
   0xFF is considered as maximum link metric and a link having
   this metric value MUST be used during Flex-algorithm calculations
   as a last resort link as described in sec 15.3 of RFC[9350]

KT> Thanks - that works. Perhaps also clarify that to make the link unusable by 
FlexAlgo using that generic metric, the advertisement of the particular generic 
metric can be skipped.
 ok


2) This comment is specific to OSPF given the encoding differences it has with 
ISIS. Section 2.2 allows for Generic Metric TLV to be used in too many places 
without clear specification of what it is used for - this is a potential 
pitfall for interop issues. RFC9492 provides helpful directions for us here.
a) This draft specifies FlexAlgo extensions, it is natural that Generic Metric 
be advertised under ASLA TLV. No issues here.
b) This draft does not specify anything about use of generic metric in base 
OSPF and as a reminder there is nothing like L-bit in OSPF encoding. Therefore, 
it does not make sense to advertise Generic Metric outside of ASLA and under 
the OSPFv2 Extended Link TLV or OSPFv3 Router Link TLV.
c) This draft does not specify anything about use of generic metric with 
RSVP-TE/GMPLS. Therefore, it does not make sense to advertise Generic Metric in 
the TE Opaque LSAs.
We can have specific documents that introduce (b) or (c) when there is a proper 
specification.
 Generic metric is a link attribute and can be used by other applications 
apart from Flex-algo.
I don’t see a reason to not take code-points under other applicable LSAs.

KT> I disagree on this one. There is a reason why what is proposed in the draft 
for ISIS is OK - due to the L-bit in ASLA, we need codepoints both under ASLA 
and at the top level for FlexAlgo. There is no L-bit in OSPF and therefore this 
does not apply. The code-points can be allocated when the behavior is specified 
for those other LSAs and applications (beyond FlexAlgo) in OSPF. We should not 
set the precedent for allocating code-points for TLVs without any defined use 
or behavior.

 Early code points are taken and implementations underway for other 
applications.

“Implementations MUST support se

Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Les,

Given that most cases can be satisfied with the text I proposed,
I don't really see the need of introducing another bit.
I'll add the text in -09 version.

Rgds
Shraddha


Juniper Business Use Only
-Original Message-
From: Les Ginsberg (ginsberg)
Sent: Friday, April 12, 2024 9:46 PM
To: Shraddha Hegde ; Acee Lindem ; lsr
Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]


Shraddha -

Thanx for the response.
Please see inline.


Juniper Business Use Only
> -Original Message-
> From: Shraddha Hegde
> Sent: Friday, April 12, 2024 8:02 AM
> To: Les Ginsberg (ginsberg) ; Acee Lindem ; lsr
> Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org
> Subject: RE: [Lsr] Working Group Last Call for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-ietf-lsr-flex-algo-bw-con-07
>
> Hi Les,
>
> Thanks for bringing-up this point.
> I agree some clarification is required for the case when G bit is set

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

Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Hi Les,

Thanks for bringing-up this point.
I agree some clarification is required for the case when G bit is set.

In case of automatic metric calculation, there may be some links that are 
outliers and an operator
may want to statically configure the bandwidth metric for such links. This is 
the reason, if bandwidth metric
is advertised that MUST be used.

I think providing an I bit at the FAD level would mean network wide and the 
flexibility of overriding
On a per-link basis won't be possible.

"In case of Interface Group Mode, if all the parallel links have been 
advertised with the Bandwidth Metric, The individual link Bandwidth Metric MUST 
be used. If only some links among the parallel links have the Bandwidth Metric 
advertisement, the Bandwidth Metric for such links MUST be ignored and automatic
Metric calculation MUST be used to derive link metric"

For the case you described where for different flex-algorithms are using some 
of the parallel links an operator can use below options.
> Option 1:
For flex-algo 128, which uses configured bandwidth metric, use user 
defined metric type 128 and flex-algo 128 to use metric-type 128.
  For Flex-algo 129 use automatic bandwidth metric with G bit set.
  > Option 2:
For flex-algo 128 use configured  bandwidth metric
  For flex-algo 129 use automatic bandwidth metric.

Let me know what you think.


Rgds
Shraddha

Juniper Business Use Only
-Original Message-
From: Les Ginsberg (ginsberg) 
Sent: Tuesday, April 9, 2024 1:08 AM
To: Acee Lindem ; lsr 
Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]


Draft authors -

Regarding Section 5, which defines the rules for deriving Bandwidth metric, 
Rule #1 states:

"If the Generic Metric sub-TLV with Bandwidth metric type is advertised for the 
link as described in Section 4, it MUST be used during the Flex-Algorithm 
calculation."

I think this constraint does not fit all possible use cases.

(Note: For brevity, I am inventing the acronym GMBM to represent "Generic 
Metric sub-TLV with Bandwidth metric type".)

Consider two nodes A, B that are connected by two parallel links - call them 
AB-1 and AB-2.

Suppose a customer deploys Flex-Algo 128, which specifies use of Bandwidth 
Metric, but also uses affinity to exclude link AB-2. Customer configures 
advertisement of GMBM for link AB-1 - all is working as expected.

Now customer deploys Flex-Algo 129, also specifying use of bandwidth metric, 
but wants both links (AB-1, AB-2) to be used and wants automatic bandwidth 
metric calculation to be used so metric automatically adapts to the number of 
links which are up between A-B. Since there is advertisement of GMBM for link 
AB-1, automatic bandwidth calculation cannot include Link AB-1 - which means 
the customer does not have a way to get what is desired without:

o Removing the advertisement of GMBM for AB-1 o Adding automatic bandwidth to 
the FAD for Flex-Algo 128

This might be quite surprising to a customer - especially if Flex-Algo 128 has 
been deployed for some time and has been working well.

There are probably multiple ways this limitation could be overcome.

One way would be to define an additional bit in the bandwidth constraint 
sub-TLVs - call it the I-bit - meaning ignore GMBM even when advertised.
This would specify use of the automated calculation based on the bandwidth of 
all links even in the presence of an explicit GMBM on one or more members of 
the Group.

Related to this, I think some clarification as regards the existing G-bit is 
required i.e., I assume that automatic calculation only includes the bandwidth 
for links which do not have a GMBM advertisement - but the current text is not 
clear on that point.

Les

> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Monday, February 19, 2024 2:26 PM
> To: lsr 
> Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org
> Subject: [Lsr] Working Group Last Call for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-ietf-lsr-flex-algo-bw-con-07
>
>
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07.
> At least some of the flex algorithm enhancements described in the
> document have been implemented.
>
>  Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!CnWa8DhzclXyIWWfxwRc7drMZ8u5PeYwo-igztZ7ldO2XGqLDqrkUF
> YdW-wHndStV44AccJ0eM9SmM_X$

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

Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Hi Ketan,

Thanks for the review and comments.
Pls see inline for replies.



Juniper Business Use Only
From: Ketan Talaulikar 
Sent: Thursday, March 21, 2024 10:07 PM
To: Acee Lindem 
Cc: lsr ; draft-ietf-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]

Hi All,

I have reviewed this document and believe it needs some further work before 
publication.

I am sharing my comments below:

1) There is the following text in sec 2.1 and 2.2 for Generic Metric.

A metric value of 0xFF is considered as maximum link metric and a link 
having this metric value MUST NOT be used during Flex-algorithm calculations 
[RFC9350].
 The link with maximum generic metric value is not available for the use of 
Flexible Algorithms but is availble for other use cases.

I believe the FlexAlgo reference here is to 
https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration

But the above text does not align with the RFC9350. If a link is to be made 
unavailable for FlexAlgos operating with a specific Generic Metric, then the 
way to do that is to omit that specific Generic Metric TLV from the ASLA for 
flex-algo application. The same would apply for other applications - just omit 
the metric. Why do we need a special MAX-LINK-METRIC value for generic metric 
given that it is a new thing we are introducing?

 I see what you are saying. Text is updated as below for ISIS and similar 
for OSPF.
“A metric value of
   0xFF is considered as maximum link metric and a link having
   this metric value MUST be used during Flex-algorithm calculations
   as a last resort link as described in sec 15.3 of RFC[9350]

2) This comment is specific to OSPF given the encoding differences it has with 
ISIS. Section 2.2 allows for Generic Metric TLV to be used in too many places 
without clear specification of what it is used for - this is a potential 
pitfall for interop issues. RFC9492 provides helpful directions for us here.
a) This draft specifies FlexAlgo extensions, it is natural that Generic Metric 
be advertised under ASLA TLV. No issues here.
b) This draft does not specify anything about use of generic metric in base 
OSPF and as a reminder there is nothing like L-bit in OSPF encoding. Therefore, 
it does not make sense to advertise Generic Metric outside of ASLA and under 
the OSPFv2 Extended Link TLV or OSPFv3 Router Link TLV.
c) This draft does not specify anything about use of generic metric with 
RSVP-TE/GMPLS. Therefore, it does not make sense to advertise Generic Metric in 
the TE Opaque LSAs.
We can have specific documents that introduce (b) or (c) when there is a proper 
specification.
 Generic metric is a link attribute and can be used by other applications 
apart from Flex-algo.
I don’t see a reason to not take code-points under other applicable LSAs.

3) Please introduce a reserved field to pad the OSPF FAEMD sub-TLV to a 4 octet 
boundary as is the convention in OSPF - 
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-3.2.2
 OK

4) In section 3.2.2 there is the following text for OSPF. Could you please use 
the TLV/sub-TLV name? OSPF folks are not good at remembering numbers ;-)

The Min Unidirectional Link Delay as advertised by sub-sub-TLV 12 of ASLA 
sub-TLV 
[RFC8920],
 MUST be compared against the Maximum delay advertised in the FAEMD sub-TLV.
 changed to “The Unidirectional Link Delay as advertised by sub-sub-TLV 12”

5) Do we want to call out that the reference bandwidth approach requires a 
router to compute and maintain a per link per algo bandwidth metric for every 
link in that algo topology. It may not be very obvious to some.
 updated as below
“Advertising
   the reference bandwidth in the FAD constraints allows the metric
   computation to be done on every node for each link.
   The metric is computed using reference bandwidth and the advertised link 
bandwidth.
   Centralized control of this
   reference bandwidth simplifies management in the case that 

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt

[Shraddha Hegde]

Hi Pengshaofu,

Thank you for review and comments.
Pls see inline..



Juniper Business Use Only
From: Lsr  On Behalf Of peng.sha...@zte.com.cn
Sent: Thursday, March 21, 2024 3:12 PM
To: acee.lin...@gmail.com
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt

[External Email. Be cautious of content]




Hi Chairs, WG,



I have relearned this document, and there are some non-blocking comments:



[1]

For Interface Group Mode of automatic metric calculation, it may biases the 
utilization rate of each link of the parallel link-set.

Although the document give an example (figure 7) to explain why this mode is 
applied, it seems not convincing.

In Figure 7, the expected path is B-C-F-D, while B-E-D is an unexpected path.

However please consider the following example that I believe that the expected 
path in this example should also be B-C-F-D + B-C'-F'-D (i.e., an ECMP path) if 
according to the same intention of the operators, but in this case most people 
may not consider them (i.e., the ECMP paths) as expected paths. There seems 
contradictory.

example:

A --- B  C  F  D

 C'  F' ---

- E 

 I am not sure I understand your comment. The draft emphasizes that 
B->C->F->D has more bandwidth and hence should have lower metric. Do you agree 
with that?



[2]

For the description of Bandwidth Thresholds Sub-TLV of ISIS and OSPF, there are 
such descripton:

  "When the computed link bandwidth ... "

can it change to "when the used link bandwidth ..." ?

IMO we can say the computed bandwidth metric but can not say the computed link 
bandwidth.

 In case of interface group mode, the link bandwidth is computed based on 
the parallel links and that’s why the term is used.

Please also check the erros of threshold #number as below:

When the computed link bandwidth is greater than or equal to Bandwidth 
Threshold 1 and less than Bandwidth Threshold 1(//should be threshold 2), 
Threshold Metric 1 MUST be assigned as the Bandwidth Metric on the link during 
the Flex-Algorithm SPF calculation.

Similarly, when the computed link bandwidth is greater than or equal to 
Bandwidth Threshold 1 (//should be threshold 2) and less than Bandwidth 
Threshold 2(//should be threshold 3), Threshold Metric 2 MUST be assigned as 
the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation.

 Good catch. I have fixed for both ISIS/OSPF

[3]

For section 5. Bandwidth metric considerations, there may have errors:



4.In ISIS the Link Bandwidth for Flex-Algorithm purposes is advertised as a 
sub-sub-TLV 9 of the Flex-algorithm specific ASLA sub-TLV. It is also possible 
to advertise the link bandwidth or Flex-Algorith(// should be changed to "for 
Flex-Algorithm" ?), in sub-TLV 9 of TLV 22/222/23/223/141 [RFC5305], together 
with the L-Flag set in the Flex-Algorithm specific ASLA advertisement. In the 
absence of both of these advertisements, the bandwidth of the link is not 
available for Flex-Algorithm purposes.

 Fixed



Regards,

PSF


Original
From: AceeLindem mailto:acee.lin...@gmail.com>>
To: lsr mailto:lsr@ietf.org>>;
Date: 2024年03月20日 11:00
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt
Speaking as WG Member:

My comments have been addressed with this version and I support publication (as 
working member).

Speaking as WG Co-Chair:

It would be good for others  to review this draft as well  (and especially 
those writing Flex-Algo
extension drafts).  We had limited support (5 non-authors including myself). 
I'll give it another
week or so for review prior to requesting publication.

Thanks,
Acee

> On Mar 18, 2024, at 6:56 AM, 
> internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote:
>
> Internet-Draft draft-ietf-lsr-flex-algo-bw-con-08.txt is now available. It is
> a work item of the Link State Routing (LSR) WG of the IETF.
>
>   Title:   Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints
>   Authors: Shraddha Hegde
>William Britto A J
>Rajesh Shetty
>Bruno Decraene
>Peter Psenak
>Tony Li
>   Name:draft-ietf-lsr-flex-algo-bw-con-08.txt
>   Pages:   30
>   Dates:   2024-03-18
>
> Abstract:
>
>   Many networks configure the link metric relative to the link
>   capacity.  High bandwidth traffic gets routed as per the link
>   capacity.  Flexible algorithms provide mechanisms to create
>   constraint based paths in IGP.  This draft documents a generic metric
>   type and set of bandwidth related constraints to be used in Flexible
>   Algorithms.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
>
> There is also an HTMLized

Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Acee,

I read your comment about elephant flow and added below text in sec 4.1.1.2

“Note that a single elephant flow is normally
   pinned to a single layer-3 interface. If the single layer-3 link
   bandwidth is not sufficient for any single elephant flow, the mechanisms
   to solve this issue are outside the scope of this document”
Replace the term “centralized controller” with “PCE”

Posting -08 version now. Pls check

Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Shraddha Hegde
Sent: Wednesday, March 6, 2024 12:22 PM
To: Acee Lindem 
Cc: lsr ; draft-ietf-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]

Hi Acee,

Thanks for the review and edits.
I have incorporated all edits.
Will post -08 when window opens.
Pls see inline for replies



Juniper Business Use Only


Juniper Business Use Only
From: Acee Lindem mailto:acee.lin...@gmail.com>>
Sent: Friday, March 1, 2024 4:16 AM
To: Acee Lindem mailto:acee.lin...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]


Authors,

I support publication of this document but not in its current state. I have the 
following comments that should be resolved first:

1. "Backward Compatibility" section is missing. This should be 
straightforward given that an FAD computation only includes
nodes supporting that FAD.
 OK

 2. “Security Considerations” is “TBD”.
 ok

 3. There is no “Operational Considerations” section. Someone may ask for 
one.
 ok

 4. The document alludes to the problem with elephant flows. Yet for 
“Interface Group Mode”, the aggregate bandwidth for multiple L3 links is used. 
How would this work when a flow is typically bound to a single L3 interface?
 All we are trying to do in this document is to assign metric relative to 
bandwidth. IGPs cannot  do any bandwidth management and path placement and it’s 
been mentioned in the introduction section clearly.

 5. #3 in section 5 is very hard to parse. Possibly split into multiple 
coherent sentences.
 will do


Lots of editorial nits - I’m attaching some suggested edits but I’m not sure I 
got them all.

  1. Use “sub-TLV” and “Sub-TLV” consistent with the usage in RFC  9350. I 
tried to fix these on the fly but it probably still needs work. Basically, it 
is capitalized when used as part of a proper noun identifying a specific 
sub-TLV. Also, in section titles and captions.
 will do

  2. Reference RFC9350 rather than the Flex-Algo draft throughout.
 ok

  3. I didn’t make the change but I’d use “Layer-2” and “Layer-3” 
hyphenated.
ok


See attached editorial suggestions  in the RFC diff.

Thanks,
Acee


> On Feb 19, 2024, at 5:25 PM, Acee Lindem 
> mailto:acee.lin...@gmail.com>> wrote:
>
>
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm 
> enhancements described in the document have been implemented.
>
> Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org<mailto:Lsr@ietf.org>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Hi Acee,

Thanks for the review and edits.
I have incorporated all edits.
Will post -08 when window opens.
Pls see inline for replies



Juniper Business Use Only
From: Acee Lindem 
Sent: Friday, March 1, 2024 4:16 AM
To: Acee Lindem 
Cc: lsr ; draft-ietf-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]


Authors,

I support publication of this document but not in its current state. I have the 
following comments that should be resolved first:

1. "Backward Compatibility" section is missing. This should be 
straightforward given that an FAD computation only includes
nodes supporting that FAD.
 OK

 2. “Security Considerations” is “TBD”.
 ok

 3. There is no “Operational Considerations” section. Someone may ask for 
one.
 ok

 4. The document alludes to the problem with elephant flows. Yet for 
“Interface Group Mode”, the aggregate bandwidth for multiple L3 links is used. 
How would this work when a flow is typically bound to a single L3 interface?
 All we are trying to do in this document is to assign metric relative to 
bandwidth. IGPs cannot  do any bandwidth management and path placement and it’s 
been mentioned in the introduction section clearly.

 5. #3 in section 5 is very hard to parse. Possibly split into multiple 
coherent sentences.
 will do


Lots of editorial nits - I’m attaching some suggested edits but I’m not sure I 
got them all.

  1. Use “sub-TLV” and “Sub-TLV” consistent with the usage in RFC  9350. I 
tried to fix these on the fly but it probably still needs work. Basically, it 
is capitalized when used as part of a proper noun identifying a specific 
sub-TLV. Also, in section titles and captions.
 will do

  2. Reference RFC9350 rather than the Flex-Algo draft throughout.
 ok

  3. I didn’t make the change but I’d use “Layer-2” and “Layer-3” 
hyphenated.
ok


See attached editorial suggestions  in the RFC diff.

Thanks,
Acee


> On Feb 19, 2024, at 5:25 PM, Acee Lindem 
> mailto:acee.lin...@gmail.com>> wrote:
>
>
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm 
> enhancements described in the document have been implemented.
>
> Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call IPR Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints"

[Shraddha Hegde]

I am not aware of any undisclosed IPR related to this document.

Rgds
Shraddha


Juniper Business Use Only
-Original Message-
From: Acee Lindem 
Sent: Tuesday, February 20, 2024 3:51 AM
To: draft-ietf-lsr-flex-algo-bw-...@ietf.org
Cc: lsr 
Subject: Working Group Last Call IPR Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints"

[External Email. Be cautious of content]


Co-Authors,

Are you aware of any IPR that applies to draft-ietf-lsr-flex-algo-bw-con-07.txt?
If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There are a few IPR statements already - 
https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-dynamic-flooding__;!!NEt6yMaO-gk!Fa_72tN2aXOE3toziHfWMIl3LbZd2xY9ovNOQtdq9floSVnscXyioPF1rI9FCWPsVEY2eZQ5DEM0q3GBfjSLAQ$

If you are listed as a document author or contributor please respond to this 
email regardless of whether or not you are aware of any relevant IPR. *The 
response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a response has 
been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any IPR 
that has not yet been disclosed in conformance with IETF rules.

Also, we have six authors and four from the same company. Please verify that 
all co-authors should be included as such.

Thanks,
Acee

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

Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03

[Shraddha Hegde]

> 1. It is not clear whether " OSPFv2 Prefix Attributes Sub-TLV" and "OSPFv3 
> Prefix Attributes Sub-TLV"
> Would allow other sub-tlvs under them in future. If so, the flags should be a 
> separate sub-sub-TLV under Prefix attributes sub-TLV. If it does not allow 
> other attributes, pls rename it as " OSPFv2 Prefix flags Sub-TLV"

no sub0sub-TLVs, the value portion is just a bitstring like ISIS
IPv4/IPv6 Extended Reachability Attribute Flags (rfc7794).

Pls rename the " OSPFv2 Prefix Attributes Sub-TLV" to "OSPFV2 Prefix Attribute 
Flags Sub-TLV"
Similarly for OSPFv3 as well.

Rgds
Shraddha


Juniper Business Use Only
-Original Message-
From: Peter Psenak 
Sent: Wednesday, November 22, 2023 6:04 PM
To: Shraddha Hegde ; Acee Lindem ; 
Lsr 
Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and 
OSPFv3" - draft-chen-lsr-prefix-extended-flags-03

[External Email. Be cautious of content]


Hi Shraddha,

On 22/11/2023 12:58, Shraddha Hegde wrote:
> I support the adoption of the document.
>
> I have below comments
>
> 1. It is not clear whether " OSPFv2 Prefix Attributes Sub-TLV" and "OSPFv3 
> Prefix Attributes Sub-TLV"
> Would allow other sub-tlvs under them in future. If so, the flags should be a 
> separate sub-sub-TLV under Prefix attributes sub-TLV. If it does not allow 
> other attributes, pls rename it as " OSPFv2 Prefix flags Sub-TLV"

no sub0sub-TLVs, the value portion is just a bitstring like ISIS
IPv4/IPv6 Extended Reachability Attribute Flags (rfc7794).

>
> 2. section 3 has below statement
> " This  document does not define any flags."
> For OSPFv3 this document defines 2 new bits. This text needs to be
> updated and IANA section

U/UP-flags have been moved here by mistake, they are defined in the UPA dratf. 
Will be fixed.

thanks,
Peter


> Needs to be updated.
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Friday, November 17, 2023 9:27 PM
> To: Lsr 
> Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org
> Subject: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2
> and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03
>
> [External Email. Be cautious of content]
>
>
> LSR WG,
>
> This starts the Working Group adoption call for 
> draft-chen-lsr-prefix-extended-flags-03. Please send your support or 
> objection to this list before December 2nd, 2023. The extra week is to allow 
> for the US Thanksgiving holiday.
>
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!DGBre12MrjIxWhX5kt5kFUqEsrj_psPbViIAnrBl4i9-7wff2Fyrg5
> EIgKXtJdujJ3xKN4aYAomnS4NXOHM$
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!CHZKllXRW53oZBGLQM6OMuuD4hNd4LBdpKiUSSdltPg2q6Vgit95so
> Gd81oq6wmPRzmzejKflaSIFyUS0ZtvOpizQWibXZ4G$
>

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

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Shraddha Hegde]

Support the adoption as co-author of this draft.



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Saturday, November 18, 2023 12:01 AM
To: Tony Przygienda ; Tony Li 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)

[External Email. Be cautious of content]

+2 support adoption as coauthor

(Chairs – is it really necessary for the authors to express support for their 
own draft? )

   Les

From: Tony Przygienda mailto:tonysi...@gmail.com>>
Sent: Friday, November 17, 2023 10:29 AM
To: Tony Li mailto:tony...@tony.li>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)

+1, support adoptoinb as co-author

On Fri, Nov 17, 2023 at 6:58 PM Tony Li 
mailto:tony...@tony.li>> wrote:

I support adoption as co-author.

T


On Nov 17, 2023, at 9:23 AM, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:

Hi,

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS 
(ietf.org)

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

Thanks,
Yingzhen

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

Re: [Lsr] IPR Poll for draft-pkaneria-lsr-multi-tlv

[Shraddha Hegde]

No, I'm not aware of any IPR that applies to this draft



Juniper Business Use Only
From: Lsr  On Behalf Of Antoni Przygienda
Sent: Friday, November 17, 2023 10:32 PM
To: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Cc: lsr-chairs 
Subject: Re: [Lsr] IPR Poll for draft-pkaneria-lsr-multi-tlv

[External Email. Be cautious of content]

No, I'm not aware of any IPR that applies to this draf




Juniper Business Use Only
From: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Date: Friday, 17 November 2023 at 18:00
To: 
draft-pkaneria-lsr-multi-...@ietf.org
 
mailto:draft-pkaneria-lsr-multi-...@ietf.org>>,
 lsr mailto:lsr@ietf.org>>
Cc: lsr-chairs mailto:lsr-cha...@ietf.org>>
Subject: IPR Poll for draft-pkaneria-lsr-multi-tlv
[External Email. Be cautious of content]

Hi,


This is an IPR call for draft-pkaneria-lsr-multi-tlv 
(draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS 
(ietf.org))

The authors and contributors please respond to this IPR call.



Please state either:

"No, I'm not aware of any IPR that applies to this draft"

or

"Yes, I'm aware of IPR that applies to this draft"



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3669, 5378 and 8179 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been disclosed"



If you answer no, please provide any additional details you think

appropriate.



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. The response needs to be sent to the LSR WG mailing

list. The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,

Yingzhen


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03

[Shraddha Hegde]

I support the adoption of the document.

I have below comments

1. It is not clear whether " OSPFv2 Prefix Attributes Sub-TLV" and "OSPFv3 
Prefix Attributes Sub-TLV"
Would allow other sub-tlvs under them in future. If so, the flags should be a 
separate sub-sub-TLV under Prefix attributes sub-TLV. If it does not allow 
other attributes, pls rename it as " OSPFv2 Prefix flags Sub-TLV"

2. section 3 has below statement
" This  document does not define any flags."
For OSPFv3 this document defines 2 new bits. This text needs to be updated and 
IANA section
Needs to be updated.

Rgds
Shraddha


Juniper Business Use Only
-Original Message-
From: Lsr  On Behalf Of Acee Lindem
Sent: Friday, November 17, 2023 9:27 PM
To: Lsr 
Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org
Subject: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and 
OSPFv3" - draft-chen-lsr-prefix-extended-flags-03

[External Email. Be cautious of content]


LSR WG,

This starts the Working Group adoption call for 
draft-chen-lsr-prefix-extended-flags-03. Please send your support or objection 
to this list before December 2nd, 2023. The extra week is to allow for the US 
Thanksgiving holiday.


Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!DGBre12MrjIxWhX5kt5kFUqEsrj_psPbViIAnrBl4i9-7wff2Fyrg5EIgKXtJdujJ3xKN4aYAomnS4NXOHM$

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

Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

[Shraddha Hegde]

I agree, the granularity would depend on the feature/RFC.

Another aspect I have seen in TLV implementations is, Receiving side processing 
is supported
But sending side isn’t. It may be useful to introduce this sending 
support/receiving support notion in the
Model.

Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Yingzhen Qu
Sent: Friday, November 17, 2023 4:28 AM
To: Tony Li 
Cc: Acee Lindem ; Les Ginsberg (ginsberg) 
; Loa Andersson ; lsr@ietf.org
Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

[External Email. Be cautious of content]

Speaking as a co-author of the draft, I'm open to name suggestions.

As for granularity, I'd say this really varies per RFC/feature. We want to make 
it useful for operators but not too tedious to implement. Realistically, we 
won't be able to have modules for all existing RFCs, so it's more about new 
RFCs. The WG should decide the level of feature granularity as part of the 
document when it is to be published.

Thanks,
Yingzhen

On Thu, Nov 16, 2023 at 2:44 PM Tony Li 
mailto:tony...@tony.li>> wrote:
Hi Acee,

I concur that a simpler name is better and am fine with what you propose. Or 
pretty much anything other than ‘PICS’.  :-)

I disagree that feature level granularity is sufficient. Example: suppose an 
implementation supports traffic engineering. Is that sufficient for an 
operator? Is that enough to ensure interoperability? I’m not convinced. Does 
the node support administrative groups? What about extended administrative 
groups? Maybe we don’t need to be at the individual TLV level for every 
feature, but it sure would be nice to call out each and every option that an 
implementation may support.

Yes, I realize that it’s a giant hassle, but if we ever want to get to the 
world when network management is fully automated, we will need to make 
everything transparent.

Regards,
Tony



On Nov 16, 2023, at 2:32 PM, Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:

Speaking as a WG contributor:

Hi Les,

I think a simpler name is better - perhaps ietf-isis-feature-support.yang with 
YANG prefix isis-fs would be better.  Which brings me to my next and more 
important point…

Like carbon neutrality, everyone at the LSR WG meeting who had an opinion 
thought such a YANG model would be operationally useful. However, I think the 
level of granularity is key. I believe that having a separate data node for 
each TLV/sub-TLV as was done in the example ietf-isis-pics-sr-mpls.yang module 
is way too granular to be useful. Rather, the YANG reporting should be done at 
the feature level. Also, does a distinction need to be made as to whether the 
IS-IS node supports the feature or both supports it and has it enabled (as 
would be the case for non-backward compatible features)?

Thanks,
Acee


On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:

Loa -

I agree with you that simply "IS-IS Support" may not be the best choice.
Although, the meeting minutes have not yet been posted, as I recall my response 
to Tony Li's suggestion of "IS-IS Support" was "Yes - something like that."

The draft authors have not yet discussed this - but we will and share the 
proposed new name.
Other suggestions welcomed.

  Les


-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Loa 
Andersson
Sent: Thursday, November 16, 2023 2:06 AM
To: lsr@ietf.org
Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

Working Group,

During the presentation of draft-qgp-lsr-isis-pics-yang there was a
rather strong opposition in the chat against using the ISO-term "PICS"
in an IETF document.

I think the term "Support" was suggested (excuse me if I missed
something), but I'm not that impressed, and would rather like to see
something like - "Supported Protocol Aspects".

/Loa
--
Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  
loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64

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

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

___
Lsr mailing list
Lsr@ietf.org

Re: [Lsr] IPR Poll for Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Shraddha Hegde]

I am not aware of any undisclosed IPR related to this document.

Rgds
Shraddha



Juniper Business Use Only
From: Dhamija, Amit 
Sent: Tuesday, August 29, 2023 8:38 AM
To: Acee Lindem ; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
Cc: lsr 
Subject: Re: IPR Poll for Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft 
name)

[External Email. Be cautious of content]

Hi Acee,

I'm not aware of any undisclosed IPR.
Brgds
Amit D
Rakuten
From: Acee Lindem mailto:acee.i...@gmail.com>>
Date: Thursday, 24 August 2023 at 1:32 AM
To: 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
 
mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>
Cc: lsr mailto:lsr@ietf.org>>
Subject: IPR Poll for Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft 
name)
[EXTERNAL] This message comes from an external organization.

Co-Authors,

Are you aware of any IPR that applies to 
draft-posenak-lsr-igp-ureach-prefix-announce-04?
If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There are a few IPR statements already - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-dynamic-flooding

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Also, since there are nine authors, it would be great if you could reduce the 
author list and make
the others contributors (which still requires an IPR response).

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

Re: [Lsr] Interdomain UPA & UP Flag

[Shraddha Hegde]

Most maintenance operations I have seen use ISIS overload with max metric 
advertise mechanism to
Switch the overlay services to another node. While this mechanism works fine 
for  MPLS environments that 
Leak the loopbacks across domains and in BGP-LU based environments, this 
mechanism is not
Available in deployments that use summarized prefixes for reachability.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Aijun Wang  
Sent: Tuesday, March 28, 2023 4:32 PM
To: Peter Psenak 
Cc: Shraddha Hegde ; Robert Raszuk ; 
lsr 
Subject: Re: [Lsr] Interdomain UPA & UP Flag

[External Email. Be cautious of content]


The following sentence should be:
> If it is planned, why the overlay service being switched over as scheduled?

If it is planned, why doesn’t the overlay service be switched over as scheduled?




Aijun Wang
China Telecom

> On Mar 28, 2023, at 19:53, Aijun Wang  wrote:
>
> There is no significant benefits to use the prefix unreachable announcement 
> mechanism to transfer the planned maintenance information.
>
> If it is planned, why the overlay service being switched over as scheduled?
>
> The PUA/UPA mechanism is mainly for the fast switchover of overlay services 
> upon the accident network failures.
>
> Please pay more attentions to other aspects of such mechanism.
>
> Aijun Wang
> China Telecom
>
>>> On Mar 28, 2023, at 18:51, Peter Psenak 
>>>  wrote:
>>>
>>> On 28/03/2023 11:41, Aijun Wang wrote:
>>> There is already overload bit to accomplish the maintenance 
>>> purposes, Why do you guys repeat such work again?
>>
>> OL-bit is only propagated inside the area. We are solving 
>> inter-area/inter-domain routing convergence here.
>>
>> Peter
>>
>>> Aijun Wang
>>> China Telecom
>>>>> On Mar 28, 2023, at 18:00, Shraddha Hegde 
>>>>>  wrote:
>>>>
>>>> Hi Robert,
>>>>
>>>>> Second, if you say this is needed for BGP free deployments then I 
>>>>> question the merit on the basis that UPA is >ephemeral and expires 
>>>>> say in 120 sec which will not be enough for most planned 
>>>>> maintenance work. So if someone >insists to add UP Flag it should 
>>>>> be not just a bit but also a time or time delta from set UTC where 
>>>>> it is expected that >provided prefix will be down,
>>>>
>>>> That is a good point that there should be a max-time associated with 
>>>> maintenance.
>>>>
>>>> I do not think that this needs to be signaled in IGP. It can be a local 
>>>> configuration.
>>>>
>>>> Rgds
>>>>
>>>> Shraddha
>>>>
>>>> Juniper Business Use Only
>>>>
>>>> *From:* Lsr  *On Behalf Of *Robert Raszuk
>>>> *Sent:* Monday, March 27, 2023 1:36 PM
>>>> *To:* lsr 
>>>> *Subject:* [Lsr] Interdomain UPA & UP Flag
>>>>
>>>> *[External Email. Be cautious of content]*
>>>>
>>>> Hi,
>>>>
>>>> I would like to get more clarification in respect to extending External 
>>>> LSAs for UPA. Area summary use case is pretty clear - but in case of 
>>>> redistribution (typical src of external LSAs) IMO we are going way too far 
>>>> with this. Let's all keep in mind that this is a pulse designed to trigger 
>>>> upper protocol switchover.
>>>>
>>>> Needless to say that would work only via one hop by design as 
>>>> redistribution happens via RIB and by definition of UPA unreachable routes 
>>>> are not being installed in RIB in the first place.
>>>>
>>>> On the apparently relative terms I do not see a need for the UP Flag. 
>>>> First planned maintenance should be solved by BGP protocol and there are 
>>>> already a number of tools in BGP allowing one to do it.
>>>>
>>>> Second, if you say this is needed for BGP free deployments then I 
>>>> question the merit on the basis that UPA is ephemeral and expires 
>>>> say in 120 sec which will not be enough for most planned 
>>>> maintenance work. So if someone insists to add UP Flag it should be 
>>>> not just a bit but also a time or time delta from set UTC where it 
>>>> is expected that provided prefix will be down,
>>>>
>>>> Kind regards,
>>>>
>>>> R.
>>>>
>>>> ___
>>>> Lsr mailing list
>>>> Lsr@ietf.org
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>>>> sr__;!!NEt6yMaO-gk!FL0C5GIdGXqvoI4vgKh2djk4mgkPgInWxmoWOOpMb4mt7rBn
>>>> QQ4e0rOGmZeNTkkGwpxGbwZ9jmR1cfW9YiEsw4uB$
>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Interdomain UPA & UP Flag

[Shraddha Hegde]

Hi Robert,

> Second, if you say this is needed for BGP free deployments then I question 
> the merit on the basis that UPA is >ephemeral and expires say in 120 sec 
> which will not be enough for most planned maintenance work. So if someone 
> >insists to add UP Flag it should be not just a bit but also a time or time 
> delta from set UTC where it is expected that >provided prefix will be down,

That is a good point that there should be a max-time associated with 
maintenance.
I do not think that this needs to be signaled in IGP. It can be a local 
configuration.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr  On Behalf Of Robert Raszuk
Sent: Monday, March 27, 2023 1:36 PM
To: lsr 
Subject: [Lsr] Interdomain UPA & UP Flag

[External Email. Be cautious of content]

Hi,

I would like to get more clarification in respect to extending External LSAs 
for UPA. Area summary use case is pretty clear - but in case of redistribution 
(typical src of external LSAs) IMO we are going way too far with this. Let's 
all keep in mind that this is a pulse designed to trigger upper protocol 
switchover.

Needless to say that would work only via one hop by design as redistribution 
happens via RIB and by definition of UPA unreachable routes are not being 
installed in RIB in the first place.

On the apparently relative terms I do not see a need for the UP Flag. First 
planned maintenance should be solved by BGP protocol and there are already a 
number of tools in BGP allowing one to do it.

Second, if you say this is needed for BGP free deployments then I question the 
merit on the basis that UPA is ephemeral and expires say in 120 sec which will 
not be enough for most planned maintenance work. So if someone insists to add 
UP Flag it should be not just a bit but also a time or time delta from set UTC 
where it is expected that provided prefix will be down,

Kind regards,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] UPA and planned/unplanned signalling

[Shraddha Hegde]

Les,

Pls see inline..


Juniper Business Use Only

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Tuesday, March 28, 2023 11:02 AM
To: Shraddha Hegde ; lsr@ietf.org
Subject: RE: UPA and planned/unplanned signalling

[External Email. Be cautious of content]


Shraddha -

Thanx for the response.

So the way you are proposing to use UPA on the receiving nodes is:

1)For unplanned loss of reachability trigger BGP-PIC for immediate response

2)For planned loss of reachability, don't trigger BGP-PIC - simply trigger a 
best path calculation considering the high cost of reaching the node about to 
go into maintenance.
You can "get away with doing this" because you assume that when you receive the 
UPA indicating planned maintenance that the node is still reachable i.e., 
maintenance hasn't actually started yet.

Do I understand you correctly?
 That is correct.

This does help me to understand your motivation, but I am not fully 
appreciating the benefits.
Whether you trigger BGP-PIC or not, you will have to do a new best path 
calculation. I don't see that not triggering BGP-PIC provides a benefit worth 
pursuing.
But maybe we just will have to agree to disagree on that.
 ok

If there is consensus to keep the two bits, I would suggest that the UP flag be 
a modifier of the U flag i.e., the U flag is always set (planned or unplanned), 
the UP flag is set in addition to the U flag when the trigger is planned 
maintenance. The UP flag would be ignored if sent without U flag set.
This would provide a modest simplification for those implementations which 
don't care about the distinction - just look at the U flag.
For those implementations that want to make the distinction you seem to favor, 
they would inspect both flags.

??
 The flags should be defined to mean one thing or the other which is how it 
is defined currently. I do not like the proposal  of defining the meaning of 
the flags based on how one implementation wants to interpret them.
It is quite surprising to me that looking at two different flags is presumably 
more complex for some implementations.
However, I am not going to argue beyond this on this topic. I am fine with 
whatever co-authors decide on this.

   Les


> -Original Message-
> From: Shraddha Hegde 
> Sent: Monday, March 27, 2023 9:25 PM
> To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> Subject: RE: UPA and planned/unplanned signalling
>
> Hi Les,
>
> Pls see inline for replies.
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, March 28, 2023 9:10 AM
> To: Shraddha Hegde ; lsr@ietf.org
> Subject: UPA and planned/unplanned signalling
>
> [External Email. Be cautious of content]
>
>
> Shraddha -
>
> To follow up on our discussion over chat at the LSR meeting yesterday...
>
> At a remote ABR, if BGP had already been told about a planned node 
> maintenance event (by means that is outside the scope of the UPA 
> draft), then BGP would have moved traffic away from the node on which 
> the maintenance event is scheduled in advance of the arrival of the 
> UPA advertisement. In such a case the arrival of the UPA advertisement 
> would be of no significance. Since traffic has already moved away it 
> does not matter whether BGP processes the UPA or does not.
>
> If, however, BGP had NOT been told about planned maintenance in 
> advance, the arrival of the UPA should be treated in the same way 
> regardless of whether the trigger was a planned maintenance event or 
> not. The node associated with the address advertised in the UPA has 
> become unreachable and BGP needs to act accordingly.
>  This is the case when BGP is not aware of the planned maintenance 
> and is learning that info from IGP.
> You are right that the final outcome of the planned maintenance vs 
> unreachability is same that the traffic needs to be moved away From 
> the remote PE. The difference is in how that is achieved. In case of 
> unreachability, the action need to be immediate and mechanisms such as 
> BGP-PIC needed. In case of planned maintenance,  it would just be 
> costing out Igp metric for the PE and hence the control plane 
> convergence.
> There may be implementations which just choose to trigger one 
> mechanisms for both scenarios and draft does not Mandate/suggest any 
> of this and is left to implementations.
>
>
>
> I therefore see no value add in differentiating between 
> planned/unplanned in the UPA advertisement.
>
> I hope this is clear.
> Please point out what I might have missed.
>
> Thanx.
>
>Les

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

Re: [Lsr] UPA and planned/unplanned signalling

[Shraddha Hegde]

Hi Les,

Pls see inline for replies.


Juniper Business Use Only

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Tuesday, March 28, 2023 9:10 AM
To: Shraddha Hegde ; lsr@ietf.org
Subject: UPA and planned/unplanned signalling

[External Email. Be cautious of content]


Shraddha -

To follow up on our discussion over chat at the LSR meeting yesterday...

At a remote ABR, if BGP had already been told about a planned node maintenance 
event (by means that is outside the scope of the UPA draft), then BGP would 
have moved traffic away from the node on which the maintenance event is 
scheduled in advance of the arrival of the UPA advertisement. In such a case 
the arrival of the UPA advertisement would be of no significance. Since traffic 
has already moved away it does not matter whether BGP processes the UPA or does 
not.

If, however, BGP had NOT been told about planned maintenance in advance, the 
arrival of the UPA should be treated in the same way regardless of whether the 
trigger was a planned maintenance event or not. The node associated with the 
address advertised in the UPA has become unreachable and BGP needs to act 
accordingly.
 This is the case when BGP is not aware of the planned maintenance and is 
learning that info from IGP.
You are right that the final outcome of the planned maintenance vs 
unreachability is same that the traffic needs to be moved away
>From the remote PE. The difference is in how that is achieved. In case of 
>unreachability, the action need to be immediate and mechanisms such as BGP-PIC 
>needed. In case of planned maintenance,  it would just be costing out
Igp metric for the PE and hence the control plane convergence. 
There may be implementations which just choose to trigger one mechanisms for 
both scenarios and draft does not
Mandate/suggest any of this and is left to implementations.



I therefore see no value add in differentiating between planned/unplanned in 
the UPA advertisement.

I hope this is clear.
Please point out what I might have missed.

Thanx.

   Les

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

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

[Shraddha Hegde]

I prefer changing the sentence to
" The IS-IS FAD Sub-TLV has an area/level scope"

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, February 14, 2023 2:26 AM
To: Acee Lindem ; Chris Parker 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]


Disclaimer: I am not an author of the flex-algo draft.

However, the text regarding "scope" of the FAD sub-TLV is in the context of the 
flooding scope of the containing Router Capability TLV (as defined in RFC 7981).
There we have two scopes defined:

1)Area/level scope (S-bit clear)

Such information MUST NOT be leaked between levels

2)Domain-wide scope (S-bit set)

Such information MUST be flooded across the entire IS-IS flooding domain - 
which means it is leaked between levels (UP and DOWN as appropriate)

Both "area/level" and "domain-wide" are terms used in RFC 7981.

The full paragraph from the flex-algo draft reads:

"The IS-IS FAD Sub-TLV has an area scope. The Router Capability TLV in which 
the FAD Sub-TLV is present MUST have the S-bit clear."

I think this is correct - but if the authors wanted to update this to 
"area/level" I would not object.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Monday, February 13, 2023 12:15 PM
> To: Chris Parker 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Two small potential typing errors in 
> draft-ietf-lsr-flex-algo
>
> Hi Chris,
>
> > On Feb 13, 2023, at 2:56 PM, Chris Parker 
> > 
> wrote:
> >
> > Hi all,
> >
> > First time poster here. Sincere apologies if I make any mistakes in
> etiquette. I work at Juniper, and am mailing on suggestion of Shraddha 
> Hegde, after a conversation about draft-ietf-lsr-flex-algo.
> >
> > Having read the draft, I think I've found two tiny things to fix.
> >
> > The first is a typo: In the text "The following values area 
> > allocated by IANA
> from this registry for Flex-Algorithms", I think it should say "are", not 
> "area”.
>
> This is definitely a typo.
>
> >
> > The second is a point of clarification in the text "The IS-IS FAD 
> > Sub-TLV has
> an area scope". I think perhaps this should be "level scope", not 
> "area scope".
>
> I can’t seem to find similar IS-IS terminology. I’ll defer to the authors.
> However, you’d be correct for OSPF.
>
> >
> > For example, imagine a level 2 backbone that contains four areas. I 
> > would
> imagine the intended behavior is actually to flood this sub-TLV 
> through the entire level 2 backbone, rather than just to the other 
> routers in the particular area that the originator happens to reside in?
> >
> > Hopefully these are useful changes. Apologies once again if I've 
> > made any
> errors in this process.
>
> Speaking as WG Co-Chair - This is definitely the right process and we 
> look forward to your future reviews of LSR documents!!!
>
> Thanks,
> Acee
>
>
> >
> > Best regards
> > Chris Parker
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls
> > r__;!!NEt6yMaO-gk!HBc_idYdlO5aWVAVEVX1LRxYrDu_445eISaA4KmlFc4JtucPDh
> > zuPTzcXChYX4Zjpc8NSYtp5Hkb0-bbx1BHCi2QTEYt6aW5$
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!HBc_idYdlO5aWVAVEVX1LRxYrDu_445eISaA4KmlFc4JtucPDhzuPT
> zcXChYX4Zjpc8NSYtp5Hkb0-bbx1BHCi2QTEYt6aW5$
___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HBc_idYdlO5aWVAVEVX1LRxYrDu_445eISaA4KmlFc4JtucPDhzuPTzcXChYX4Zjpc8NSYtp5Hkb0-bbx1BHCi2QTEYt6aW5$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[Shraddha Hegde]

Acee,

Anything pending from authors to request for early allocation?

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Acee Lindem  
Sent: Thursday, January 12, 2023 11:47 PM
To: Shraddha Hegde 
Cc: lsr-...@ietf.org; lsr-cha...@ietf.org; 
draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; lsr 
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[External Email. Be cautious of content]


Hi Shraddha,

I see now. I hadn’t read the complete document for some time and was looking 
usage in the constraints encodings as opposed to the intended purpose of a 
metric to which the new constraints are applied.


Thanks,
Acee

> On Jan 12, 2023, at 12:01 AM, Shraddha Hegde  wrote:
>
> Acee,
>
> This draft defines a new metric-type called "bandwidth metric" and available 
> for use in flex-algo.
> The specifics are described in   section 4 of the draft.
> Instead of defining a stand alone "bandwidth metric type", the draft defines 
> "generic metric"
> Where there is a provision for metric-type/metric value pair. Defines 
> standard metric types and  to make it Flexible there is user defined 
> metric-types "Bandwidth metric" is one of the standard metric-types of 
> the generic metric that this draft has defined and used.
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Acee Lindem 
> Sent: Wednesday, January 11, 2023 11:44 PM
> To: Shraddha Hegde ; lsr-...@ietf.org
> Cc: lsr-cha...@ietf.org; 
> draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; lsr 
> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt
>
> [External Email. Be cautious of content]
>
>
> +LSR List….
>
>
> Hi Shraddha,
>
> I’ll request the ADs approve early allocation. However, I recall unanswered 
> questions as to whether the generic metric was required and how it would be 
> used.  It isn’t required for the bandwidth constraints defined in the draft. 
> Can you comment on this point?
>
> Thanks,
> Acee
>
>> On Jan 9, 2023, at 11:43 PM, Shraddha Hegde  wrote:
>>
>> Chairs,
>>
>> Authors would like to request IANA early code-point allocation for the draft.
>>
>> Rgds
>> Shraddha
>>
>>
>> Juniper Business Use Only
>>
>> -Original Message-
>> From: Lsr  On Behalf Of 
>> internet-dra...@ietf.org
>> Sent: Tuesday, January 10, 2023 10:10 AM
>> To: i-d-annou...@ietf.org
>> Cc: lsr@ietf.org
>> Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Link State Routing WG of the IETF.
>>
>>   Title   : Flexible Algorithms: Bandwidth, Delay, Metrics and 
>> Constraints
>>   Authors : Shraddha Hegde
>> William Britto A J
>> Rajesh Shetty
>> Bruno Decraene
>> Peter Psenak
>> Tony Li
>> Filename: draft-ietf-lsr-flex-algo-bw-con-04.txt
>> Pages   : 29
>> Date: 2023-01-09
>>
>> Abstract:
>>  Many networks configure the link metric relative to the link  
>> capacity.  High bandwidth traffic gets routed as per the link  
>> capacity.  Flexible algorithms provides mechanisms to create  
>> constraint based paths in IGP.  This draft documents a generic metric  
>> type and set of bandwidth related constraints to be used in Flexible  
>> Algorithms.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
>> tf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuV
>> k4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UPWiFZZw$
>>
>> There is also an htmlized version available at:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
>> ft-ietf-lsr-flex-algo-bw-con-04__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93
>> MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8Use7KjR
>> U$
>>
>> A diff from the previous version is available at:
>> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2
>> =draft-ietf-lsr-flex-algo-bw-con-04__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMS
>> pU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UFI
>> _AgUI$
>>
>>
>> Internet-Drafts are also available by rsync at 
>> rsync.ietf.org::internet-drafts
>>
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>> __;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARD
>> pp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UhNjFf88$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[Shraddha Hegde]

Les,

As I explained in this e-mail chain, my motivation for including max-link 
metric is
Option 2 in your description. That is the reason I referred to RFC 3784 text.

We can add text to describe the motivation for max link metric in next revision.

Request WG to provide details If there are other usecases/motivations beyond 
what is discussed in this e-mail chain.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Monday, January 16, 2023 11:06 PM
To: Shraddha Hegde ; Mengxiao.Chen 
; lsr@ietf.org
Subject: RE: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[External Email. Be cautious of content]


Shraddha -

I think Mengxiao has raised a legitimate point. The use of max-metric to 
exclude a link is at best redundant in flex-algo since there are existing ways 
to exclude a link. Simply quoting RFC 5305 doesn’t really help in understanding 
the motivation of the authors in adding this restriction.

I do not object to this additional restriction, but I think the draft should be 
more forthcoming as to why this was introduced. I can think of a couple of 
possible reasons:

1)Existing logic in implementations for algo 0 have this restriction. Applying 
it to all algos simplifies implementations.

2)As the new generic metric can potentially be used for use cases other than 
flex-algo, it makes sense to apply the same restriction.

Perhaps the authors had different motivations...

Please consider adding text that helps the readers to understand why this new 
restriction was added.

Les

> -Original Message-
> From: Lsr  On Behalf Of Shraddha Hegde
> Sent: Sunday, January 15, 2023 9:27 PM
> To: Mengxiao.Chen ; lsr@ietf.org
> Subject: Re: [Lsr] FW: I-D Action: 
> draft-ietf-lsr-flex-algo-bw-con-04.txt
>
> Hi,
>
> This is the excerpt from the RFC 3784
> " If a link is advertised with the maximum link metric (2^24 - 1), this
>link MUST NOT be considered during the normal SPF computation.  This
>will allow advertisement of a link for purposes other than building
>the normal Shortest Path Tree.  An example is a link that is
>available for traffic engineering, but not for hop-by-hop routing."
>
> This same usecase applies to flex-algo and generic metric as well. 
> Maximum link metric Implies the link is not available for use in 
> flex-lago but can be used for other Purposes like SR-TE.
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Mengxiao.Chen 
> Sent: Thursday, January 12, 2023 1:18 PM
> To: Shraddha Hegde ; lsr@ietf.org
> Subject: RE: [Lsr] FW: I-D Action: 
> draft-ietf-lsr-flex-algo-bw-con-04.txt
>
> [External Email. Be cautious of content]
>
>
> Hi Shraddha,
>
> Thank you for replies.
> I think the case of Flex-Algo is different from normal SPF. Flex-Algo 
> is used to compute paths based on constraints.
> The topology constraints include whether a link is considered for 
> flex-algo calculation. And it is already realized by Node 
> Participation, Admin Group and SRLG, as specified in draft-ietf-lsr-flex-algo.
> Could you explain the reason for defining additional Max-Generic-Metric?
>
> Thanks,
> Mengxiao
>
> -Original Message-
> From: Shraddha Hegde 
> Sent: Thursday, January 12, 2023 12:45 PM
> To: Mengxiao.Chen ; lsr@ietf.org
> Subject: RE: [Lsr] FW: I-D Action: 
> draft-ietf-lsr-flex-algo-bw-con-04.txt
>
> Hi Chenmengxiao,
>
> Thanks for review and comments.
> Pls see inline [SH] for replies
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Chenmengxiao 
> Sent: Wednesday, January 11, 2023 8:26 AM
> To: Shraddha Hegde ; lsr@ietf.org
> Subject: RE: [Lsr] FW: I-D Action: 
> draft-ietf-lsr-flex-algo-bw-con-04.txt
>
> [External Email. Be cautious of content]
>
>
> Hi Shraddha,
>
> In the new version, Generic Metric sub-TLV added "A metric value of 
> 0x is considered as maximum link metric and a link having this 
> metric MUST NOT be considered in SPF computation."
> With that I have two questions/suggestions:
> #1  Generic Metric sub-TLV may be used for different kinds of 
> metric-type, maximum value can have different meanings. Besides, Admin 
> Group rules can be used to exclude a link in Flex-Algo. Why must 
> define a global unreachable value?
> [SH] RFC 3784 defined MAX-LINK-METRIC so that links can be advertised 
> but not used for normal SPF computation.
> Same case applies here where links are not considered for flex-algo 
> calculations but can be used for other reasons inside a flex-algo plane.
>
> #2  According to draft-ietf-lsr-flex-algo, I think it's better to use 
> "Flex- Algorithm calculations" instead of

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-05.txt

[Shraddha Hegde]

-05 version posted.

Changes listed below.

1.  IANA section "IGP metric-type Registry" updated
2.  Editorial comments from Les
3.  "SPF computations" changed to "Flex-algorithm calculations"

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: Monday, January 16, 2023 9:54 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-05.txt

[External Email. Be cautious of content]


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Flexible Algorithms: Bandwidth, Delay, Metrics and 
Constraints
    Authors : Shraddha Hegde
  William Britto A J
  Rajesh Shetty
  Bruno Decraene
  Peter Psenak
  Tony Li
  Filename: draft-ietf-lsr-flex-algo-bw-con-05.txt
  Pages   : 30
  Date: 2023-01-16

Abstract:
   Many networks configure the link metric relative to the link
   capacity.  High bandwidth traffic gets routed as per the link
   capacity.  Flexible algorithms provides mechanisms to create
   constraint based paths in IGP.  This draft documents a generic metric
   type and set of bandwidth related constraints to be used in Flexible
   Algorithms.



The IETF datatracker status page for this draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!GnyojdrcMbE5AMwab6RxhQ9WVfYPMtfG4SwnbvbdwSoqAVQ-r-k5HimwOGPrO_Mg5rq0dF2DZHv5MlyTMwR8lGlfCcE$

There is also an htmlized version available at:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-05__;!!NEt6yMaO-gk!GnyojdrcMbE5AMwab6RxhQ9WVfYPMtfG4SwnbvbdwSoqAVQ-r-k5HimwOGPrO_Mg5rq0dF2DZHv5MlyTMwR8a4zEEu8$

A diff from the previous version is available at:
https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-flex-algo-bw-con-05__;!!NEt6yMaO-gk!GnyojdrcMbE5AMwab6RxhQ9WVfYPMtfG4SwnbvbdwSoqAVQ-r-k5HimwOGPrO_Mg5rq0dF2DZHv5MlyTMwR8hYHkk2c$


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GnyojdrcMbE5AMwab6RxhQ9WVfYPMtfG4SwnbvbdwSoqAVQ-r-k5HimwOGPrO_Mg5rq0dF2DZHv5MlyTMwR8Yj7K4Sw$

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

Re: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[Shraddha Hegde]

Hi,

This is the excerpt from the RFC 3784
" If a link is advertised with the maximum link metric (2^24 - 1), this
   link MUST NOT be considered during the normal SPF computation.  This
   will allow advertisement of a link for purposes other than building
   the normal Shortest Path Tree.  An example is a link that is
   available for traffic engineering, but not for hop-by-hop routing."

This same usecase applies to flex-algo and generic metric as well. Maximum link 
metric
Implies the link is not available for use in flex-lago but can be used for other
Purposes like SR-TE.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Mengxiao.Chen  
Sent: Thursday, January 12, 2023 1:18 PM
To: Shraddha Hegde ; lsr@ietf.org
Subject: RE: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[External Email. Be cautious of content]


Hi Shraddha,

Thank you for replies.
I think the case of Flex-Algo is different from normal SPF. Flex-Algo is used 
to compute paths based on constraints.
The topology constraints include whether a link is considered for flex-algo 
calculation. And it is already realized by Node Participation, Admin Group and 
SRLG, as specified in draft-ietf-lsr-flex-algo.
Could you explain the reason for defining additional Max-Generic-Metric?

Thanks,
Mengxiao

-Original Message-----
From: Shraddha Hegde 
Sent: Thursday, January 12, 2023 12:45 PM
To: Mengxiao.Chen ; lsr@ietf.org
Subject: RE: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

Hi Chenmengxiao,

Thanks for review and comments.
Pls see inline [SH] for replies


Juniper Business Use Only

-Original Message-
From: Chenmengxiao 
Sent: Wednesday, January 11, 2023 8:26 AM
To: Shraddha Hegde ; lsr@ietf.org
Subject: RE: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[External Email. Be cautious of content]


Hi Shraddha,

In the new version, Generic Metric sub-TLV added "A metric value of 0x 
is considered as maximum link metric and a link having this metric MUST NOT be 
considered in SPF computation."
With that I have two questions/suggestions:
#1  Generic Metric sub-TLV may be used for different kinds of metric-type, 
maximum value can have different meanings. Besides, Admin Group rules can be 
used to exclude a link in Flex-Algo. Why must define a global unreachable value?
[SH] RFC 3784 defined MAX-LINK-METRIC so that links can be advertised but not 
used for normal SPF computation.
Same case applies here where links are not considered for flex-algo 
calculations but can be used for other reasons inside a flex-algo plane.

#2  According to draft-ietf-lsr-flex-algo, I think it's better to use 
"Flex-Algorithm calculations" instead of "SPF computation".
[SH]. Agree. Will update .


Thanks,
Mengxiao

-Original Message-
From: Lsr  On Behalf Of Shraddha Hegde
Sent: Tuesday, January 10, 2023 12:43 PM
To: lsr@ietf.org
Subject: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

WG,

New version of the draft has been posted.
Changes listed below.

1. Suggested codepoints in IANA section removed 2. Section 2.1 and 2.2 updated. 
Metric 0 is allowed. Added  below sentence "
Maximum link metric MUST NOT be used in SPF"
3. editorial changes.

Pls review the draft.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, January 10, 2023 10:10 AM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[External Email. Be cautious of content]


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Flexible Algorithms: Bandwidth, Delay, Metrics and 
Constraints
Authors : Shraddha Hegde
  William Britto A J
  Rajesh Shetty
  Bruno Decraene
  Peter Psenak
  Tony Li
  Filename: draft-ietf-lsr-flex-algo-bw-con-04.txt
  Pages   : 29
  Date: 2023-01-09

Abstract:
   Many networks configure the link metric relative to the link
   capacity.  High bandwidth traffic gets routed as per the link
   capacity.  Flexible algorithms provides mechanisms to create
   constraint based paths in IGP.  This draft documents a generic metric
   type and set of bandwidth related constraints to be used in Flexible
   Algorithms.



The IETF datatracker status page for this draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UPWiFZZw$

There is also an htmlized version available at:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[Shraddha Hegde]

Hi Les,

Thanks for the review and comments.

Pls see inline..


Juniper Business Use Only

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Thursday, January 12, 2023 11:20 AM
To: Shraddha Hegde ; Acee Lindem ; 
lsr-...@ietf.org
Cc: lsr-cha...@ietf.org; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; lsr 

Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[External Email. Be cautious of content]


Shraddha -

Regarding the new Generic Metric sub-TLV, there is a significant omission in 
the draft:

Given that (as you discuss in Sections 2.1 and 2.2) some metric types cannot be 
advertised in the new Generic Metric sub-TLV because they are specified to be 
advertised in a different encoding, it seems necessary to enhance the existing 
IGP Metric Types registry 
(https://urldefense.com/v3/__https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml*igp-metric-type__;Iw!!NEt6yMaO-gk!FHcrzTJX8kOctn17M90O5h5i25FaSb269D86OFFOHnCNI_AxfpRZ69BVND6VAs54Hnrp000QrzBMSulNpvsxtjrOmE_vE9Da$
 ) to specify for each defined metric type whether it can/cannot be advertised 
in the Generic Metric sub-TLV. But you do not discuss extending the registry in 
this way at all in the draft.

As I have stated in the past, I am not a big fan of the Generic Metric sub-TLV. 
I think it would be possible to do what you want to do without a generic 
container - but I am also amenable to what is in the draft. However, you MUST 
ensure that the IGP Metric Types registry is explicit as regards how each 
defined metric type (now and in the future) is advertised (inside the Generic 
Metric sub-TLV or not)
 agree with extending the IGP metric-type registry to add a column on 
allowed in Generic-metric sub-TLV or not.

I also think that the clarity of the presentation in Sections 2.1/2.2 could be 
enhanced by separating the text into multiple paragraphs. For example:


The Generic Metric sub-TLV MAY be advertised multiple times. For a particular 
metric type, the Generic Metric sub-TLV MUST be advertised only once for a link 
when advertised in TLV 22,222,23,223 and 141. When Generic metric sub-TLV is 
advertised in ASLA, each metric type MUST be advertised only once 
per-application for a link. If there are multiple Generic Metric sub-TLVs 
advertised for a link for same metric type (and same application in case of 
ASLA) in one or more received LSPDUs, advertisement in the lowest numbered 
fragment MUST be used and the subsequent ones MUST be ignored.

If the metric type indicates a standard metric type for which there are other 
advertisement mechanisms (e.g., the IGP metric, the Min Unidirectional Link 
Delay, or the Traffic Engineering Default Metric, as of this writing), the 
Generic Metric advertisement MUST be ignored.

A metric value of 0xFF is considered as maximum link metric and a link 
having this metric value MUST NOT be considered in SPF computation.


 ok. Will update.

Thanx.

Les

> -Original Message-
> From: Lsr  On Behalf Of Shraddha Hegde
> Sent: Wednesday, January 11, 2023 9:01 PM
> To: Acee Lindem ; lsr-...@ietf.org
> Cc: lsr-cha...@ietf.org; 
> draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; lsr 
> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt
>
> Acee,
>
> This draft defines a new metric-type called "bandwidth metric" and 
> available for use in flex-algo.
> The specifics are described in   section 4 of the draft.
> Instead of defining a stand alone "bandwidth metric type", the draft 
> defines "generic metric"
> Where there is a provision for metric-type/metric value pair. Defines 
> standard metric types and  to make it Flexible there is user defined 
> metric-types "Bandwidth metric" is one of the standard metric-types of 
> the generic metric that this draft has defined and used.
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Acee Lindem 
> Sent: Wednesday, January 11, 2023 11:44 PM
> To: Shraddha Hegde ; lsr-...@ietf.org
> Cc: lsr-cha...@ietf.org; 
> draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; lsr 
> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt
>
> [External Email. Be cautious of content]
>
>
> +LSR List….
>
>
> Hi Shraddha,
>
> I’ll request the ADs approve early allocation. However, I recall 
> unanswered questions as to whether the generic metric was required and 
> how it would be used.  It isn’t required for the bandwidth constraints 
> defined in the draft.
> Can you comment on this point?
>
> Thanks,
> Acee
>
> > On Jan 9, 2023, at 11:43 PM, Shraddha Hegde 
> wrote:
> >
> > Chairs,
> >
> > Authors would like to request IANA early code-point allocation for 
> > the
> draft.
> >
> > Rgds
> > Shrad

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[Shraddha Hegde]

Acee,

This draft defines a new metric-type called "bandwidth metric" and available 
for use in flex-algo.
The specifics are described in   section 4 of the draft. 
Instead of defining a stand alone "bandwidth metric type", the draft defines 
"generic metric"
Where there is a provision for metric-type/metric value pair. Defines standard 
metric types and  to make it
Flexible there is user defined metric-types
"Bandwidth metric" is one of the standard metric-types of the generic metric 
that this draft
has defined and used.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Acee Lindem  
Sent: Wednesday, January 11, 2023 11:44 PM
To: Shraddha Hegde ; lsr-...@ietf.org
Cc: lsr-cha...@ietf.org; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; lsr 

Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[External Email. Be cautious of content]


+LSR List….


Hi Shraddha,

I’ll request the ADs approve early allocation. However, I recall unanswered 
questions as to whether the generic metric was required and how it would be 
used.  It isn’t required for the bandwidth constraints defined in the draft. 
Can you comment on this point?

Thanks,
Acee

> On Jan 9, 2023, at 11:43 PM, Shraddha Hegde  wrote:
>
> Chairs,
>
> Authors would like to request IANA early code-point allocation for the draft.
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Tuesday, January 10, 2023 10:10 AM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt
>
> [External Email. Be cautious of content]
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
>
>    Title   : Flexible Algorithms: Bandwidth, Delay, Metrics and 
> Constraints
>Authors : Shraddha Hegde
>  William Britto A J
>  Rajesh Shetty
>  Bruno Decraene
>  Peter Psenak
>  Tony Li
>  Filename: draft-ietf-lsr-flex-algo-bw-con-04.txt
>  Pages   : 29
>  Date: 2023-01-09
>
> Abstract:
>   Many networks configure the link metric relative to the link
>   capacity.  High bandwidth traffic gets routed as per the link
>   capacity.  Flexible algorithms provides mechanisms to create
>   constraint based paths in IGP.  This draft documents a generic metric
>   type and set of bandwidth related constraints to be used in Flexible
>   Algorithms.
>
>
>
> The IETF datatracker status page for this draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UPWiFZZw$
>
> There is also an htmlized version available at:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-04__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8Use7KjRU$
>
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-flex-algo-bw-con-04__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UFI_AgUI$
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UhNjFf88$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[Shraddha Hegde]

Hi Chenmengxiao,

Thanks for review and comments.
Pls see inline [SH] for replies


Juniper Business Use Only

-Original Message-
From: Chenmengxiao  
Sent: Wednesday, January 11, 2023 8:26 AM
To: Shraddha Hegde ; lsr@ietf.org
Subject: RE: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[External Email. Be cautious of content]


Hi Shraddha,

In the new version, Generic Metric sub-TLV added "A metric value of 0x 
is considered as maximum link metric and a link having this metric MUST NOT be 
considered in SPF computation."
With that I have two questions/suggestions:
#1  Generic Metric sub-TLV may be used for different kinds of metric-type, 
maximum value can have different meanings. Besides, Admin Group rules can be 
used to exclude a link in Flex-Algo. Why must define a global unreachable value?
[SH] RFC 3784 defined MAX-LINK-METRIC so that links can be advertised but not 
used for normal SPF computation.
Same case applies here where links are not considered for flex-algo 
calculations but can be used for other reasons inside a flex-algo plane.

#2  According to draft-ietf-lsr-flex-algo, I think it's better to use 
"Flex-Algorithm calculations" instead of "SPF computation".
[SH]. Agree. Will update .


Thanks,
Mengxiao

-Original Message-
From: Lsr  On Behalf Of Shraddha Hegde
Sent: Tuesday, January 10, 2023 12:43 PM
To: lsr@ietf.org
Subject: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

WG,

New version of the draft has been posted.
Changes listed below.

1. Suggested codepoints in IANA section removed 2. Section 2.1 and 2.2 updated. 
Metric 0 is allowed. Added  below sentence "
Maximum link metric MUST NOT be used in SPF"
3. editorial changes.

Pls review the draft.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, January 10, 2023 10:10 AM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[External Email. Be cautious of content]


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Flexible Algorithms: Bandwidth, Delay, Metrics and 
Constraints
Authors : Shraddha Hegde
  William Britto A J
  Rajesh Shetty
  Bruno Decraene
  Peter Psenak
  Tony Li
  Filename: draft-ietf-lsr-flex-algo-bw-con-04.txt
  Pages   : 29
  Date: 2023-01-09

Abstract:
   Many networks configure the link metric relative to the link
   capacity.  High bandwidth traffic gets routed as per the link
   capacity.  Flexible algorithms provides mechanisms to create
   constraint based paths in IGP.  This draft documents a generic metric
   type and set of bandwidth related constraints to be used in Flexible
   Algorithms.



The IETF datatracker status page for this draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UPWiFZZw$

There is also an htmlized version available at:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-04__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8Use7KjRU$

A diff from the previous version is available at:
https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-flex-algo-bw-con-04__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UFI_AgUI$


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UhNjFf88$

___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!B3EvgEhULdgY7X_tTtFDz1kUMPiFcuvaU0zktRs-P5iMsY7ZrD6-0mgwGqWTppQ3ECBriApWSFv5qaYgKumZNy0$
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or disseminat

[Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[Shraddha Hegde]

WG,

New version of the draft has been posted.
Changes listed below.

1. Suggested codepoints in IANA section removed
2. Section 2.1 and 2.2 updated. Metric 0 is allowed. Added  below sentence "
Maximum link metric MUST NOT be used in SPF"
3. editorial changes.

Pls review the draft.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, January 10, 2023 10:10 AM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

[External Email. Be cautious of content]


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Flexible Algorithms: Bandwidth, Delay, Metrics and 
Constraints
Authors : Shraddha Hegde
  William Britto A J
  Rajesh Shetty
  Bruno Decraene
  Peter Psenak
  Tony Li
  Filename: draft-ietf-lsr-flex-algo-bw-con-04.txt
  Pages   : 29
  Date: 2023-01-09

Abstract:
   Many networks configure the link metric relative to the link
   capacity.  High bandwidth traffic gets routed as per the link
   capacity.  Flexible algorithms provides mechanisms to create
   constraint based paths in IGP.  This draft documents a generic metric
   type and set of bandwidth related constraints to be used in Flexible
   Algorithms.



The IETF datatracker status page for this draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UPWiFZZw$

There is also an htmlized version available at:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-04__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8Use7KjRU$

A diff from the previous version is available at:
https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-flex-algo-bw-con-04__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UFI_AgUI$


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Db--a1RCey-Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg-iL_V_VJkQ-71AZ8UhNjFf88$

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

Re: [Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

[Shraddha Hegde]

This is a simple flood reduction algorithm based on well proven algorithms 
deployed in MANET.
Recent evolution in network topologies towards highly regular topologies in 
datacenters as well as in WANs
will benefit from the flood reduction in IGPs.
As a co-author of this draft, I support the adoption of this draft.

Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 23, 2022 1:31 AM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for 
Dense Topologies" - draft-white-lsr-distoptflood-03

[External Email. Be cautious of content]

LSR WG,

This begins a 2 week WG adoption call for the following draft:

https://datatracker.ietf.org/doc/draft-white-lsr-distoptflood/

The draft would be adopted on the Informational or Experimental track.

Please indicate your support or objection by December 7th, 2022.
Also indicate whether you believe it should be Informational or Experimental 
track.

Thanks,
Acee


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

Re: [Lsr] IPR Poll for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

[Shraddha Hegde]

I am not aware of any IPR other than the one declared by Juniper.

Rgds
Shraddha



Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Wednesday, November 23, 2022 1:26 AM
To: Antoni Przygienda ; Shraddha Hegde 
; Russ White 
Cc: lsr@ietf.org
Subject: IPR Poll for "IS-IS Optimal Distributed Flooding for Dense Topologies" 
- draft-white-lsr-distoptflood-03

[External Email. Be cautious of content]

Authors,

Are you aware of any IPR that applies to draft-white-lsr-distoptflood-03.txt?

The following IPR declarations have been disclosed:

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-white-lsr-distoptflood

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Shraddha Hegde]

Snipped to open comments.

KT> Since we are talking about SRv6 Locators, that are associated with the node 
and not a LAN, I am not sure these fields hold much relevance. Please let me 
know if I am missing something.
 I agree there is no relevance, but its important to specify there is no 
relevance and describe what should be filled while sending.

KT2> We don't have these fields in the SRv6 Locator TLV so there is nothing to 
be filled in there. I believe you are suggesting clarification on how these 
fields need to be filled when an SRv6 Locator is also advertised as "normal" 
prefix reachability using the Intra-Area-Prefix TLV in the E-Intra-Area-Prefix 
LSA (e.g., for algo 0). Can you please confirm?

 Yes. That is correct.



Juniper Business Use Only
From: Ketan Talaulikar 
Sent: Monday, August 22, 2022 10:23 AM
To: Shraddha Hegde 
Cc: Yingzhen Qu ; Acee Lindem (acee) 
; lsr ; 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[External Email. Be cautious of content]

Hi Shraddha,

Thanks for your response. Please check inline below with KT2 for some 
clarifications.

We'll work on posting the update once this one remaining discussion point is 
closed.


On Mon, Aug 22, 2022 at 9:46 AM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Hi Ketan,

Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Thursday, August 18, 2022 11:28 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; lsr 
mailto:lsr@ietf.org>>; 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[External Email. Be cautious of content]

Hi Shraddha,

Thanks for your detailed review and please check inline below for responses.


On Thu, Aug 18, 2022 at 5:15 PM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Authors,

OSPFv3 extensions for Srv6 is a useful draft and I support progressing this 
draft.
I have below comments.



  1. Add a section to describe benefits of defining a new locator LSA rather 
than
 putting locator sub-TLV in existing LSAs.

KT> I do not personally see a significant benefit in using a new LSA as opposed 
to re-using existing ones. When this draft was originally proposed, we 
(authors) were not able to use the base extended prefix LSAs due to the 
mandatory requirement for using the base prefix reachability TLVs per RFC8362. 
Hence, we went with the new LSAs so as not to mix up the reachabilities and 
follow RFC8362. However, after further discussions in the WG, there were newer 
methods determined (e.g., the use of LSInfinity as a metric for the base prefix 
reachability TLVs that we are doing for OSPFv3 IP FlexAlgo). However, by then 
there were already implementations using the new LSAs for OSPFv3 SRvt, so it 
was decided to continue with the approach of using the new LSAs.

 OK

2.
"The processing of the prefix
  advertised in the SRv6 Locator TLV, the calculation of its
  reachability, and the installation in the forwarding plane follows
  the OSPFv3 [RFC5340] specifications for the respective route types.
  Locators associated with algorithms 0 and 1 SHOULD be advertised
  using the respective OSPFv3 Extended LSA types with extended TLVs
  [RFC8362] so that routers that do not support SRv6 will install a
  forwarding entry for SRv6 traffic matching those locators.  When
  operating in Extended LSA sparse-mode [RFC8362], these locators
  SHOULD be also advertised using the respective legacy OSPFv3 LSAs
  [RFC5340]."

   I suggest to change the SHOULD to MUST
   and always use legacy LSAs/extended LSAs for reachability
  calculation for algo 0 and algo 1.
  The current text says use legacy LSAs/extended LSAs if its there.

KT> The usage of SHOULD is aligned with the ISIS SRv6 spec (refer 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#section-5<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions*section-5__;Iw!!NEt6yMaO-gk!F5ePU2u8gidMUa5UIGC_tSJ6PeNxoOhrD6NgqAHhxZ7Pk487kQLvCJuHJdmtzGeVlQJ0aMsTGgoiZbjikKYjlA$>).

 If we decide to keep congruent with ISIS, that's fine
I noticed that section corresponding to below is missing in OSPF

"Locators associated with Flexible Algorithms (see Section 4 of
   
[I-D.ietf-lsr-flex-algo<https://urldefense.com/v3/__htt

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Shraddha Hegde]

Hi Ketan,

Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar 
Sent: Thursday, August 18, 2022 11:28 PM
To: Shraddha Hegde 
Cc: Yingzhen Qu ; Acee Lindem (acee) 
; lsr ; 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[External Email. Be cautious of content]

Hi Shraddha,

Thanks for your detailed review and please check inline below for responses.


On Thu, Aug 18, 2022 at 5:15 PM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Authors,

OSPFv3 extensions for Srv6 is a useful draft and I support progressing this 
draft.
I have below comments.



  1. Add a section to describe benefits of defining a new locator LSA rather 
than
 putting locator sub-TLV in existing LSAs.

KT> I do not personally see a significant benefit in using a new LSA as opposed 
to re-using existing ones. When this draft was originally proposed, we 
(authors) were not able to use the base extended prefix LSAs due to the 
mandatory requirement for using the base prefix reachability TLVs per RFC8362. 
Hence, we went with the new LSAs so as not to mix up the reachabilities and 
follow RFC8362. However, after further discussions in the WG, there were newer 
methods determined (e.g., the use of LSInfinity as a metric for the base prefix 
reachability TLVs that we are doing for OSPFv3 IP FlexAlgo). However, by then 
there were already implementations using the new LSAs for OSPFv3 SRvt, so it 
was decided to continue with the approach of using the new LSAs.

 OK

2.
"The processing of the prefix
  advertised in the SRv6 Locator TLV, the calculation of its
  reachability, and the installation in the forwarding plane follows
  the OSPFv3 [RFC5340] specifications for the respective route types.
  Locators associated with algorithms 0 and 1 SHOULD be advertised
  using the respective OSPFv3 Extended LSA types with extended TLVs
  [RFC8362] so that routers that do not support SRv6 will install a
  forwarding entry for SRv6 traffic matching those locators.  When
  operating in Extended LSA sparse-mode [RFC8362], these locators
  SHOULD be also advertised using the respective legacy OSPFv3 LSAs
  [RFC5340]."

   I suggest to change the SHOULD to MUST
   and always use legacy LSAs/extended LSAs for reachability
  calculation for algo 0 and algo 1.
  The current text says use legacy LSAs/extended LSAs if its there.

KT> The usage of SHOULD is aligned with the ISIS SRv6 spec (refer 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#section-5<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions*section-5__;Iw!!NEt6yMaO-gk!F5ePU2u8gidMUa5UIGC_tSJ6PeNxoOhrD6NgqAHhxZ7Pk487kQLvCJuHJdmtzGeVlQJ0aMsTGgoiZbjikKYjlA$>).

 If we decide to keep congruent with ISIS, that's fine
I noticed that section corresponding to below is missing in OSPF

"Locators associated with Flexible Algorithms (see Section 4 of
   
[I-D.ietf-lsr-flex-algo<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions#ref-I-D.ietf-lsr-flex-algo>])
 SHOULD NOT be advertised in Prefix
   Reachability TLVs (236 or 237).  Advertising the Flexible Algorithm
   locator in regular Prefix Reachability TLV (236 or 237) would make
   the forwarding for it to follow algo 0 path."

I think this applies to OSPF as well as there is no algo field in the legacy or
Extended LSAs.



  The locator TLV does not seem to have all the information needed 
in all cases
  for route calculation. From a quick scan I found below info 
missing in Locator TLV

   - NSSA forwarding address

   when the locator is exported from another OSPF domain and 
originated as a NSSA type
  the ability to advertise NSSA fwding address and use it in route 
calculation is required

KT> Thanks for catching that. Looks like we've missed the listing of the IPv6 
Forwarding Address and similar sub-TLVs that can be used as a sub-TLV of the 
SRv6 Locator TLV. Will fix that and share the update for review.
 ok



3. If authors agree to change as per comment 2 then metric and route-type 
fields in locator TLV
   for alo 0 and algo 1 must be ignored.

KT> Please see my response to your comment #2.


4. Need to add clarification the intra area prefix LSA corresponding to the 
locator will have the fields
Referenced LS Type, Referenced Link State ID, and Referenced
  Advertising Router

KT> Since we are talking about SRv6 Locators, that are associated with the node 
and not a LAN, I am not sure these fields hold much relevance. Please let me 
know if I am missing something.
 I agree there is no relevance, but its important to specify there is no 
relevance and describe what 

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Shraddha Hegde]

Authors,

OSPFv3 extensions for Srv6 is a useful draft and I support progressing this 
draft.
I have below comments.



  1. Add a section to describe benefits of defining a new locator LSA rather 
than
 putting locator sub-TLV in existing LSAs.
2.
"The processing of the prefix
  advertised in the SRv6 Locator TLV, the calculation of its
  reachability, and the installation in the forwarding plane follows
  the OSPFv3 [RFC5340] specifications for the respective route types.
  Locators associated with algorithms 0 and 1 SHOULD be advertised
  using the respective OSPFv3 Extended LSA types with extended TLVs
  [RFC8362] so that routers that do not support SRv6 will install a
  forwarding entry for SRv6 traffic matching those locators.  When
  operating in Extended LSA sparse-mode [RFC8362], these locators
  SHOULD be also advertised using the respective legacy OSPFv3 LSAs
  [RFC5340]."

   I suggest to change the SHOULD to MUST
   and always use legacy LSAs/extended LSAs for reachability
  calculation for algo 0 and algo 1.
  The current text says use legacy LSAs/extended LSAs if its there.
  The locator TLV does not seem to have all the information needed 
in all cases
  for route calculation. From a quick scan I found below info 
missing in Locator TLV

   - NSSA forwarding address

   when the locator is exported from another OSPF domain and 
originated as a NSSA type
  the ability to advertise NSSA fwding address and use it in route 
calculation is required



3. If authors agree to change as per comment 2 then metric and route-type 
fields in locator TLV
   for alo 0 and algo 1 must be ignored.

4. Need to add clarification the intra area prefix LSA corresponding to the 
locator will have the fields
Referenced LS Type, Referenced Link State ID, and Referenced
  Advertising Router


Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Yingzhen Qu
Sent: Wednesday, August 17, 2022 5:22 AM
To: Acee Lindem (acee) 
Cc: lsr ; draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[External Email. Be cautious of content]

I support progressing this draft.

I have the following minor comments for the authors to consider:


  *   The title of Section 4 of this draft is "Advertisement of SRH Operation 
Limits", and really it only covers the advertisements of MSDs, so may consider 
to change the title to be consistent with the ISIS SRv6 extensions draft, 
"Advertising Maximum SRv6 SID Depths".

  *   The subsections in section 4 are almost identical to the subsections in 
draft-ietf-lsr-isis-srv6-extesions. It's up to the authors and the WG to decide 
whether to keep this duplicate.
  *   In draft-ietf-lsr-isis-srv6-extensions, "topology/algorithm" is used, and 
it's not consistently used in this draft. For example, in section 5 the second 
paragraph, only "algorithm" is used, while "topology/algorithm" is used later.

Nits (line numbers are from idnits):

208the SR Algorithm TLV defined in [RFC8665] as described in [RFC8666]
SR Algorithm/SR-Algorithm  Please add a "-" to be consistent with RFC 8665.


355The SRv6 Locator LSA has a function code of TBD while the S1/S2 bits
"TBD" should be replaced with "42" as in IANA considerations.

Thanks,
Yingzhen


On Jul 29, 2022, at 10:16 AM, Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>> wrote:

As promised in today's LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.


https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

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

[Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo

[Shraddha Hegde]

Authors,


I suggest that the usecase can be satisfied using the backward compatible
Maximum link metric mechanism defined in the draft.
I don't see any need to define protocol extensions,
that are backward incompatible and can cause serious issues in the network
in the presence of older implementations.

Rgds
Shraddha


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

[Shraddha Hegde]

>It only mandates that this prefix not be used in SPF computation, and leave 
>the possibility of using it for other purposes,
>where "indicating the prefix is unreachable" could be one of the possible use 
>cases

I totally agree with that statement.
An indication of unreachability in the prefix-attribute flags in ISIS is useful.
In OSPF, we could use extended prefix opaque LSA to achieve it.

Rgds
Shraddha


Juniper Business Use Only
From: Lsr  On Behalf Of Dongjie (Jimmy)
Sent: Friday, July 29, 2022 10:24 AM
To: Ketan Talaulikar ; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
Cc: lsr 
Subject: Re: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

[External Email. Be cautious of content]

Hi authors, WG,

I also have some comments which aligns with Ketan's first and third points as 
below:

Firstly, both RFC 5305 and 5308 say that:

"If a prefix is advertised with a metric larger then MAX_PATH_METRIC (call it 
infinite metric), this prefix MUST NOT be considered during the normal SPF 
computation. This allows advertisement of a prefix for purposes other than 
building the normal IP routing table."

It only mandates that this prefix not be used in SPF computation, and leave the 
possibility of using it for other purposes, where "indicating the prefix is 
unreachable" could be one of the possible use cases.

According to these RFCs, a node which receives such a prefix with a metric 
larger than MAX_PATH_METRIC will not take it into consideration for SPF 
computation, but if there is another summary prefix which covers this one, this 
prefix will still be reachable based on the summary prefix.

To indicate this prefix is unreachable even if there is a summary prefix exist, 
additional behavior is required on the receiving node, and this needs to be 
indicated with some additional information in the prefix advertisement.

Secondly, section 2.1 of this document says

"...Such an advertisement can be interpreted by the receiver as a UPA."

And

 "Optionally, an implementation may use local configuration to limit the set of 
metric values which will be interpreted as UPA."

This shows that such an advertisement may be interpreted by the receiver as 
something else, and it is expected that not all of the metric values larger 
then MAX_PATH_METRIC will be interpreted as "prefix is unreachable".

To avoid possible mis-interpretation of the purpose of this prefix 
advertisement, and to save the effort of local configuration, a protocol 
mechanism is needed to carry the accurate indication of the purpose of this 
advertisement.

In summary,


1)   Treating such a prefix as unreachable is not the behavior defined in 
the existing RFCs, a standard track document would be needed for it.

2)   Additional information in the advertisement is needed to accurately 
reflect the purpose and the required behavior.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, July 28, 2022 2:27 PM
To: 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
Cc: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

Hello Authors,

Sharing some comments upfront on this draft given the packed LSR agenda.

1) There is currently no change in protocol encoding (see also further 
comment), however, there are protocol procedures at the ABR being specified 
using normative language. Specifically, the text related to the propagation of 
UPA across levels/areas/domains. Therefore, I believe that this draft should be 
moved to the standards track.

2) The document refers to "prefix reachability" in a generic sense. My 
understanding is that this refers to the "base" prefix reachability in the IGPs 
- i.e., Extended IP Reachability (TLV 135) and its MT & IPv6 siblings in ISIS, 
the OSPFv2 Type 3 LSA, and the OSPFv3 Inter-Area Prefix LSA (and its Extended 
LSA sibling). It would be good to specify these for clarity.

3) I also prefer (like some other WG members) that there is an explicit 
indication that is carried along with the UPAs. E.g., a UPA flag. This will 
help in more accurate monitoring and handling of these updates. It will also 
help differentiate the usual/existing max/infinite metric advertisements that 
may be triggered for other reasons from a UPA.

Thanks,
Ketan

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

Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

[Shraddha Hegde]

Les,

I am fine with the revised text and addresses my concern.

Rgds
Shraddha



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Tuesday, July 19, 2022 2:15 AM
To: Shraddha Hegde ; Les Ginsberg (ginsberg) 
; lsr@ietf.org
Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

[External Email. Be cautious of content]


Shraddha -



Please see {LES2:] inline.



> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Shraddha Hegde

> Sent: Monday, July 18, 2022 2:16 AM

> To: Les Ginsberg (ginsberg) 
> mailto:ginsberg=40cisco@dmarc.ietf.org>>;

> lsr@ietf.org<mailto:lsr@ietf.org>

> Subject: Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-

> 01.txt

>

> Les,

>

> Pls see inline [SH2]

>

>

> Juniper Business Use Only

>

> -Original Message-

> From: Les Ginsberg (ginsberg) 
> mailto:ginsberg=40cisco@dmarc.ietf.org>>

> Sent: Friday, July 15, 2022 10:21 PM

> To: Shraddha Hegde mailto:shrad...@juniper.net>>; 
> Shraddha Hegde

> mailto:shrad...@juniper.net>>; 
> lsr@ietf.org<mailto:lsr@ietf.org>

> Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

>

> [External Email. Be cautious of content]

>

>

> Shraddha -

>

> Top posting since there now seems to be only one open issue.

>

> 

> > [LES:] When Legacy routers are present, advertising different values

> > for link attributes in ASLA advertisements is an implementation bug.

> > That is clear from the previous statement in the same paragraph:

> >

> > "... routers that do not support the extensions defined in this

> > document will send and receive only legacy link attribute advertisements."

> >

> >  This statement says routers that are legacy will send and receive

> > legacy advertisement which is obvious. It does not say other routers

> > which are ASLA capable MUST NOT send ASLA with application bit set

> > having different values In the presence of legacy routers in the domain.



[LES2:]  I am struggling a bit with your concern because it suggests that you 
think someone reading the RFC might think it is OK to send two different 
advertisements for a given application/link/attribute. Such advertisements 
could be both legacy, both ASLA, or a mixture. Frankly, this interpretation 
never occurred to me - in large part because it seems obvious this would be 
ambiguous and cause operational problems - but also because such a thing is not 
discussed at all in existing specifications (such as RFC 5305) and this has 
never been a concern.



Nevertheless, clarity is a good thing. Here is a proposed rewording of the 
first part of Section 6.3.3:



Current Text:



For the applications defined in this document, routers that do not support the 
extensions defined in this document will send and receive only legacy link 
attribute advertisements. So long as there is any legacy router in the network 
that has any of the applications enabled, all routers MUST continue to 
advertise link attributes using legacy advertisements. In addition, the link 
attribute values associated with the set of applications supported by legacy 
routers (RSVP-TE, SR Policy, and/or LFA) are always shared since legacy routers 
have no way of advertising or processing application-specific values. Once all 
legacy routers have been upgraded, migration from legacy advertisements to ASLA 
advertisements can be achieved via the following steps:





Proposed  Revised Text:



For the applications defined in this document, routers that do not support the 
extensions defined in this document will send and receive only legacy link 
attribute advertisements. In addition, the link attribute values associated 
with the set of applications supported by legacy routers (RSVP-TE, SR Policy, 
and/or LFA) are always shared since legacy routers have no way of advertising 
or processing application-specific values. So long as there is any legacy 
router in the network that has any of the applications defined in this document 
enabled, all routers MUST continue to advertise link attributes for these 
applications using only legacy advertisements. ASLA advertisements for these 
applications MUST NOT be sent.  Once all legacy routers have been upgraded, 
migration from legacy advertisements to ASLA advertisements can be achieved via 
the following steps:





> >

> > Implementations which deviate from this haven't done adequate testing

> > of their product before shipping it.

> >  The scope of the discussion here is to get the specification

> > clear and unambiguous.

> 

>

> Taking individual sentences out of context from Section 6.3.3 prolongs this

> discussion and leads to erroneou

Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

[Shraddha Hegde]

Les,

Pls see inline [SH2]


Juniper Business Use Only

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Friday, July 15, 2022 10:21 PM
To: Shraddha Hegde ; Shraddha Hegde 
; lsr@ietf.org
Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

[External Email. Be cautious of content]


Shraddha -

Top posting since there now seems to be only one open issue.


> [LES:] When Legacy routers are present, advertising different values 
> for link attributes in ASLA advertisements is an implementation bug. 
> That is clear from the previous statement in the same paragraph:
>
> "... routers that do not support the extensions defined in this 
> document will send and receive only legacy link attribute advertisements."
>
>  This statement says routers that are legacy will send and receive 
> legacy advertisement which is obvious. It does not say other routers 
> which are ASLA capable MUST NOT send ASLA with application bit set 
> having different values In the presence of legacy routers in the domain.
>
> Implementations which deviate from this haven't done adequate testing 
> of their product before shipping it.
>  The scope of the discussion here is to get the specification 
> clear and unambiguous.


Taking individual sentences out of context from Section 6.3.3 prolongs this 
discussion and leads to erroneous conclusions.
The section says:


6.3.3.  Interoperability with Legacy Routers

   For the applications defined in this document, routers that do not
   support the extensions defined in this document will send and receive
   only legacy link attribute advertisements.  So long as there is any
   legacy router in the network that has any of the applications
   enabled, all routers MUST continue to advertise link attributes using
   legacy advertisements.


There is only one way to indicate - using ASLA - that legacy advertisements are 
to be used - which is to use the L-flag as defined in Section 4.2 - which 
states (in part):

[SH2] The statement you make above is not clear from the draft. Its very much 
valid to advertise attributes in TLV 22 and advertise ASLA with some 
application bit set as long as that application has been upgraded to support 
ASLA in entire network.
 Suggest below change

" all routers MUST continue to advertise link attributes using
   legacy advertisements . If ASLA is advertised with legacy application bit 
set then L-bit MUST be set  for that application"



When the L-flag is set in the Application Identifier Bit Mask, all of
   the applications specified in the bit mask MUST use the legacy
   advertisements for the corresponding link found in TLVs Advertising
   Neighbor Information.  Link attribute sub-sub-TLVs for the
   corresponding link attributes MUST NOT be advertised for the set of
   applications specified in the Standard or User-Defined Application
   Identifier Bit Masks, and all such sub-sub-TLVs MUST be ignored on
   receipt.


Taking all of the above text into account, this means that for a given 
application:

1)In the presence of legacy routers legacy advertisements MUST be used 2)ASLA 
link attribute sub-sub-TLVs for that application MUST NOT be advertised 3)If 
ASLA link attribute sub-sub-TLVs are advertised they MUST be ignored

So in the presence of legacy routers there is no possibility that a conforming 
implementation will use link attribute values that differ from the legacy 
values even if they were to be advertised (which in itself is forbidden).

This seems to me to cover the issue you raise very clearly. Ay additional 
statement would be redundant.

   Les


> -Original Message-
> From: Shraddha Hegde 
> Sent: Friday, July 15, 2022 9:20 AM
> To: Les Ginsberg (ginsberg) ; Shraddha Hegde 
> ; lsr@ietf.org
> Subject: RE: New Version Notification for 
> draft-ginsberg-lsr-rfc8919bis-01.txt
>
> Les,
>
> Pls see inline...
>
>
> Juniper Business Use Only
>
> -----Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Friday, July 15, 2022 9:11 PM
> To: Shraddha Hegde ; Shraddha 
> Hegde ; lsr@ietf.org
> Subject: RE: New Version Notification for 
> draft-ginsberg-lsr-rfc8919bis-01.txt
>
> [External Email. Be cautious of content]
>
>
> Shraddha -
>
> Please see inline.
>
> > -Original Message-
> > From: Shraddha Hegde 
> > Sent: Friday, July 15, 2022 5:43 AM
> > To: Les Ginsberg (ginsberg) ; Shraddha Hegde 
> > ; lsr@ietf.org
> > Subject: RE: New Version Notification for 
> > draft-ginsberg-lsr-rfc8919bis-01.txt
> >
> > Les,
> >
> > Thanks for the reply. Pls see inline..
> >
> >
> >
> >
> >
> > Juniper Business Use Only
> >
> > -Original Message-
> > From: Lsr  On Behalf Of Les Ginsberg 
> > (ginsb

Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

[Shraddha Hegde]

Les,

Pls see inline...


Juniper Business Use Only

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: Friday, July 15, 2022 9:11 PM
To: Shraddha Hegde ; Shraddha Hegde 
; lsr@ietf.org
Subject: RE: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

[External Email. Be cautious of content]


Shraddha -

Please see inline.

> -Original Message-
> From: Shraddha Hegde 
> Sent: Friday, July 15, 2022 5:43 AM
> To: Les Ginsberg (ginsberg) ; Shraddha Hegde 
> ; lsr@ietf.org
> Subject: RE: New Version Notification for 
> draft-ginsberg-lsr-rfc8919bis-01.txt
>
> Les,
>
> Thanks for the reply. Pls see inline..
>
>
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Thursday, July 14, 2022 2:32 AM
> To: Shraddha Hegde ; 
> lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for 
> draft-ginsberg-lsr-rfc8919bis- 01.txt
>
> [External Email. Be cautious of content]
>
>
> Shraddha -
>
> Thanx for your review and comments.
> Responses inline.
>
> > -Original Message-
> > From: Shraddha Hegde 
> > Sent: Tuesday, July 12, 2022 10:52 PM
> > To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> > Subject: RE: New Version Notification for 
> > draft-ginsberg-lsr-rfc8919bis-01.txt
> >
> > Authors,
> >
> > Thanks for the bis version of RFC 8919 and the clarifying text on errata.
> > The issues raised with respect to the errata have been addressed 
> > well in the bis version.
> > However, I believe that the bis version is also an opportunity for 
> > us to address any other ambiguities and clarifications and not just 
> > restrict it to the raised errata. RFC 8919 is going to serve as base 
> > document for many future applications /attributes and a clear 
> > definition and documentation is necessary for interoperable 
> > implementations as well as for future evolution of the protocol.
> >
> > I have below comments on the document
> >
> > 1. The definition of what constitutes an application in the scope of 
> > this document is not
> > clearly defined in the document.
>
> [LES:] Both documents have the same explicit definition in the Introduction:
>
> "For the purposes of this document, an application is a technology 
> that makes use of link attribute advertisements, examples of which are 
> listed in..."
>
> The term "application" may have other meanings in other contexts, but 
> those meanings are not relevant here.
> We have clearly defined what "application" means when used in this 
> document.
> The definition here is not sufficiently described and very vague.
> You didn't respond to my comment below that there is no clarity 
> whether
> SRv6 would ever  qualify for a separate application.

[LES:] Not sure what your point is here.
Neither SR-MPLS nor SRv6 is defined as an application by this document.
But perhaps my answer below will address your concern.

>
> > Currently RSVP,SR-TE, LFA, Flex-algo have been defined
> >   so it appears that any application that uses TE attributes can 
> > be defined as a separate application.
> >   The TE mechanisms like RSVP, SR-TE and flex-algo have been 
> > defined as separate applications
> >   and it appears features having significantly different
> >   forwarding plane is defined as new application. It is not 
> > clear if SRv6 would be
> >   qualified as a new application.
> >   LFA for different forwarding planes such as IP, MPLS, SRv6 are 
> > not separate applications
> >   but LFA is defined as a single application.
> >   I have also seen many drafts confusing application specific to 
> > be user application.
> >   I  suggest to add a section and describe what is an 
> > application clearly in the draft that should provide
> >   sufficient input on what can be defined as an application from 
> > ASLA context in future.
> >
> [LES:] I disagree.
> Such text would require clairvoyance. I do not pretend to know what 
> new technologies may be defined in the future which could benefit from 
> ASLA support.
>
> Note that for a new application to be included in the set of ASLA 
> supported standard applications, a draft must be written defining the 
> new application and this has to achieve WG consensus.
> So there is a thorough vetting procedure in place already.
>
>  This document defined the application bit SR-TE. It didn't 
> clarify whether SR-TE means mpls dataplane as well as SRv6 dataplane. 
> At a minimum it needs to be clarified in the d

Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

[Shraddha Hegde]

Les,

Thanks for the reply. Pls see inline..





Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, July 14, 2022 2:32 AM
To: Shraddha Hegde ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ginsberg-lsr-rfc8919bis-01.txt

[External Email. Be cautious of content]


Shraddha -

Thanx for your review and comments.
Responses inline.

> -Original Message-
> From: Shraddha Hegde 
> Sent: Tuesday, July 12, 2022 10:52 PM
> To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> Subject: RE: New Version Notification for 
> draft-ginsberg-lsr-rfc8919bis-01.txt
>
> Authors,
>
> Thanks for the bis version of RFC 8919 and the clarifying text on errata.
> The issues raised with respect to the errata have been addressed well 
> in the bis version.
> However, I believe that the bis version is also an opportunity for us 
> to address any other ambiguities and clarifications and not just 
> restrict it to the raised errata. RFC 8919 is going to serve as base 
> document for many future applications /attributes and a clear 
> definition and documentation is necessary for interoperable 
> implementations as well as for future evolution of the protocol.
>
> I have below comments on the document
>
> 1. The definition of what constitutes an application in the scope of 
> this document is not
> clearly defined in the document.

[LES:] Both documents have the same explicit definition in the Introduction:

"For the purposes of this document, an application is a technology that makes 
use of link attribute advertisements, examples of which are listed in..."

The term "application" may have other meanings in other contexts, but those 
meanings are not relevant here.
We have clearly defined what "application" means when used in this document.
The definition here is not sufficiently described and very vague. 
You didn't respond to my comment below that there is no clarity whether SRv6 
would ever  qualify for a separate application. 

> Currently RSVP,SR-TE, LFA, Flex-algo have been defined
>   so it appears that any application that uses TE attributes can 
> be defined as a separate application.
>   The TE mechanisms like RSVP, SR-TE and flex-algo have been 
> defined as separate applications
>   and it appears features having significantly different
>   forwarding plane is defined as new application. It is not clear 
> if SRv6 would be
>   qualified as a new application.
>   LFA for different forwarding planes such as IP, MPLS, SRv6 are 
> not separate applications
>   but LFA is defined as a single application.
>   I have also seen many drafts confusing application specific to 
> be user application.
>   I  suggest to add a section and describe what is an application 
> clearly in the draft that should provide
>   sufficient input on what can be defined as an application from 
> ASLA context in future.
>
[LES:] I disagree.
Such text would require clairvoyance. I do not pretend to know what new 
technologies may be defined in the future which could benefit from ASLA support.

Note that for a new application to be included in the set of ASLA supported 
standard applications, a draft must be written defining the new application and 
this has to achieve WG consensus.
So there is a thorough vetting procedure in place already.

 This document defined the application bit SR-TE. It didn't clarify whether 
SR-TE means mpls dataplane as well as SRv6 dataplane. At a minimum it needs to 
be clarified in the document.

>
> 2. "   When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
>applications specified in the bit mask MUST use the link attribute
>advertisements in the sub-TLV."
>Applications such as RSVP, SR-TE, LFA already use legacy advertisements.
>This document suggests that if any attribute is advertised with an 
> application bit set in ASLA
>ASLA advertisements MUST be used by that application.
>Implementations may support ASLA for only some applications.
>I suggest to add below text.
>
>Until all nodes upgraded to support ASLA for a particular 
> application, different values of link attributes
>MUST NOT be advertised for that application in legacy advertisement 
> and ASLA advertisements.
>
[LES:] Section 6 of RFC8919bis - and more specifically Section 6.3.3 - 
addresses this point in detail.
I do not see that new text is needed.

Comparable text can be found in RFC8920bis Section 12.3.3

 
"So long as there is any
   legacy router in the network that has any of the applications
   enabled, all routers MUST continue to advertise link attributes using
   legacy advertisements."

Sec 6.3.3 in 8919bis has above statement. 
It jus

Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

[Shraddha Hegde]

Authors,

Thanks for the bis version of RFC 8919 and the clarifying text on errata.
The issues raised with respect to the errata have been addressed well in the 
bis version.
However, I believe that the bis version is also an opportunity for us to
address any other ambiguities and clarifications and not just restrict it to 
the raised errata. RFC 8919 is going to serve as base document for many
future applications /attributes and a clear definition and documentation
is necessary for interoperable implementations as well as for future
evolution of the protocol.

I have below comments on the document

1. The definition of what constitutes an application in the scope of this 
document is not
clearly defined in the document. Currently RSVP,SR-TE, LFA, Flex-algo have 
been defined
so it appears that any application that uses TE attributes can be 
defined as a separate application.
The TE mechanisms like RSVP, SR-TE and flex-algo have been defined as 
separate applications
and it appears features having significantly different
forwarding plane is defined as new application. It is not clear if SRv6 
would be 
qualified as a new application. 
LFA for different forwarding planes such as IP, MPLS, SRv6 are not 
separate applications
but LFA is defined as a single application.
I have also seen many drafts confusing application specific to be user 
application.
I  suggest to add a section and describe what is an application clearly 
in the draft that should provide
sufficient input on what can be defined as an application from ASLA 
context in future.


2. "   When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
   applications specified in the bit mask MUST use the link attribute
   advertisements in the sub-TLV."
   Applications such as RSVP, SR-TE, LFA already use legacy advertisements. 
   This document suggests that if any attribute is advertised with an 
application bit set in ASLA
   ASLA advertisements MUST be used by that application.
   Implementations may support ASLA for only some applications. 
   I suggest to add below text.
   
   Until all nodes upgraded to support ASLA for a particular application, 
different values of link attributes
   MUST NOT be advertised for that application in legacy advertisement and ASLA 
advertisements.


Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, June 21, 2022 8:59 AM
To: lsr@ietf.org
Subject: [Lsr] FW: New Version Notification for 
draft-ginsberg-lsr-rfc8919bis-01.txt

[External Email. Be cautious of content]


Folks -

Please note V01 of the RFC8919bis draft has been posted.

This version incorporates comments received from Bruno.

   Les

-Original Message-
From: internet-dra...@ietf.org 
Sent: Monday, June 20, 2022 8:22 PM
To: John Drake ; Les Ginsberg (ginsberg) 
; Peter Psenak (ppsenak) ; Stefano 
Previdi ; Wim Henderickx 
Subject: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt


A new version of I-D, draft-ginsberg-lsr-rfc8919bis-01.txt
has been successfully submitted by Les Ginsberg and posted to the IETF 
repository.

Name:   draft-ginsberg-lsr-rfc8919bis
Revision:   01
Title:  IS-IS Application-Specific Link Attributes
Document date:  2022-06-20
Group:  Individual Submission
Pages:  25
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.txt__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlB5e_NMk$
Status: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlMHc2Gn4$
Html:   
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.html__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlABYFZnP$
Htmlized:   
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-rfc8919bis__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlJxHVgye$
Diff:   
https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ginsberg-lsr-rfc8919bis-01__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlEG5hZVF$

Abstract:
   Existing traffic-engineering-related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  Since the
   original RSVP-TE use case was defined, additional applications (e.g.,
   Segment Routing Policy and Loop-Free Alternates) that also make use
   of the link attribute advertisements have been defined.  In cases
   where multiple applications wish to make use 

Re: [Lsr] IETF 114 LSR Slot Request

[Shraddha Hegde]

Chairs,

Authors of draft-white-lsr-distoptflood would like to request a slot for 
presentation in IETF 114.

Draft: draft-white-lsr-distoptflood
Time duration: 10 mins



Rgds
Shraddha


Juniper Business Use Only
From: Lsr  On Behalf Of Yingzhen Qu
Sent: Tuesday, June 28, 2022 12:34 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: [Lsr] IETF 114 LSR Slot Request

[External Email. Be cautious of content]

Hi,

The preliminary agenda for IETF 114 has been posted: 
https://datatracker.ietf.org/meeting/114/agenda/

LSR will have one session:

Friday, July 29, 2022
12:30 - 14:30 Session II
Liberty B

Please send slot request to lsr-cha...@ietf.org. 
Please include draft name, presenter, slot length including Q

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

Re: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE: IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

[Shraddha Hegde]

>Calling RSVP-TE, SR, LFA or Flex-Algo as "applications" is confusing as those 
>are network forwarding paradigms and >not applications.
I totally agree with that. It is very confusing to call them applications . I 
do see new drafts that mistakenly assume ASLA can be used to advertise 
application specific values. What it also implies is that the way industry is 
evolving, it is required to advertise “User application” specific values and 
use them to build paths no-matter what network forwarding paradigms are used.
Having a protocol extension that allows for wildcarding the attributes for 
these forwarding paradigms is useful.

Looks like the other side of the argument is, it would have been useful if it 
was done in RFC 8919/RFC 8920 but since its an RFC now, we should carry that 
debt forever. I don’t agree with that argument and believe we still have 
opportunity to improve.

Rgds
Shraddha




Juniper Business Use Only
From: Robert Raszuk 
Sent: Sunday, March 27, 2022 5:22 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr ; Christian Hopps ; Shraddha Hegde 
; Martin Horneffer 
Subject: Re: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE: IETF13: 
Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

[External Email. Be cautious of content]

Hi Les,

Nope the abbreviation is not confusing.

Calling RSVP-TE, SR, LFA or Flex-Algo as "applications" is confusing as those 
are network forwarding paradigms and not applications.

Applications (read user applications which samples I provided) are running on 
top of them. What you call applications are merely different types of pipes to 
carry user applications.

And that alone if you just stay focused on IGP may be all fine. But the moment 
you need to carry user applications over your (network) applications each with 
set of different colors the picture becomes very confusing.

- - -

In any case - aside from the above - even considering your terminology, 
physical properties of the links are not application dependent. Irrespective of 
what encapsulation you use for your traffic for example the value of 
propagation delay of the link will always be application independent. Hence it 
does make sense to advertise it with ANY wildcard notion.

Especially that you always have the ability within each such "application" 
algorithm definition or with use of link affinities to further select which 
specific links and link attributes to use to compute an instance of a  
forwarding paradigm.

Thx,
R.


On Sun, Mar 27, 2022 at 12:21 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert –

The complete name (as reflected in the referenced registry name) is:  Link 
Attribute Application Identifiers

In the context of ASLA we tend to abbreviate that as “Application”. If you find 
that confusing, we can all try to use the more complete name.
But whatever name we use, that is what is being referenced when we discuss the 
use of ASLA.

   Les

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Saturday, March 26, 2022 3:16 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: lsr mailto:lsr@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Martin Horneffer 
mailto:m...@lab.dtag.de>>
Subject: Re: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE: IETF13: 
Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

Hi Les,

What you call "an application" is simply counter intuitive and not what 99.9% 
of people understand by this term. Application to me is a web server running on 
the host waiting for user requests, SIP gateway providing VoIP connections, 
database instance running on some specific port and responding to SQL queries, 
multicast streaming etc ...

Each of these real applications may benefit from different network 
transport/forwarding class.

Calling a network forwarding class as "an application" only generates huge 
confusion. Networks are servants to the user applications. Networks are not the 
applications itself.

As each user application may benefit from different treatment it can be mapped 
to different network transport or network color. So again network color could 
be seen as a network behaviour constructed in an optimal way to the user 
application it is designed to carry.

When you say "You also can – using the algo specific FAD – specify which colors 
are to be used by a given algo." to me means that you are also overloading the 
term "color" - at least from the notion of how CAR or CT proposal are defining 
it. And what CAR/CT proposals call a transport color is actually in line with 
network forwarding class and very intuitive.

As you recall a few months back I defined an IP TE solution where we can steer 
packets between nodes without any stack of labels or segments imposed on them 
u

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

[Shraddha Hegde]

I believe we still have an opportunity to simplify ASLA as it is not that 
widely deployed.
The inter-operability issues are almost always due to unclear and ambiguous 
documentation
of standards. All we need is to ensure is that the protocol  extensions have 
unambiguous documentation.

The two main advantages of Any app are efficiency and simplicity.
The encoding efficiency of any app for common cases has been demonstrated in 
the presentation.
The one byte overhead that Les brings about is a distraction. It's a always a 
fixed additional one byte 
for all vs any ,which is negligible whereas the benefits demonstrated for any 
can be more if 
more attributes fall in the same category.

Rgds
Shraddha



Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, March 24, 2022 9:28 PM
To: Martin Horneffer ; lsr@ietf.org
Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute 
(ASLA) Any Application Bit

[External Email. Be cautious of content]


Martin -

I hear you.

The reality is that ASLA need not be that complex.

In many deployments life is simple. There are a small number of applications 
using the same set of values on each link.
>From an encoding standpoint, all that needs to be done is to send a single 
>ASLA sub-TLV that lists the applications and the link attributes.

The use of ALL applications is only an encoding optimization - it isn't 
required. In hindsight, maybe we should never have defined it - but it seemed 
like a nice optimization at the time.
But certainly,  we should not further complicate things - both for 
implementations and deployments - by defining yet another encoding option. As 
you suggest below, this increases the possibility of interoperability issues 
w/o providing significant benefit.

ASLA is needed. There are real world examples where it is necessary to identify 
on each link which applications are using the advertised link attribute values.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Martin Horneffer
> Sent: Thursday, March 24, 2022 8:18 AM
> To: lsr@ietf.org
> Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link 
> Attribute
> (ASLA) Any Application Bit
>
> Dear WG,
>
> as we just had this discussion and acoustics in the room didn't appear 
> to be good I was asked to post my comment to the list:
>
> Not a comment on the idea of the ANy Application bit per se, nor on Les'
> discussion. Rather a ceterum censeo on ASLA in general:
> In my opinion this discussion shows that ASLA itself is overly complex.
>
> Let's just hope this discussion gets resolved quickly, and doesn't 
> provide yet another source for interoperability issues between vendors.
> We already have more than enough of them.
>
> Best regards,
> Martin
>
>
> Am 24.03.22 um 06:05 schrieb Les Ginsberg (ginsberg):
> > Folks -
> >
> >
> >
> > Now that the slides have been posted for this presentation, I am 
> > going to
> send some early comments.
> >
> > I do this because - as usual - the agenda for the meeting is packed 
> > and it is
> likely there will be little time for discussion during the meeting.
> >
> > Also my comments are lengthy, it would be difficult to present them 
> > during
> the meeting.
> >
> >
> >
> > As always, discussion can occur on the list, but if Shraddha has a 
> > chance to
> review these comments in the limited time before the meeting and has a 
> chance to respond to them during her presentation so much the better, 
> but I am not expecting that.
> >
> >
> >
> > COMMENT 1
> >
> >
> >
> > Existing encoding defined in RFCs 8919/8920 is fully functional 
> > i.e., the
> introduction of ANY application does not add support for deployment 
> scenarios that could not otherwise be supported.
> >
> >
> >
> > COMMENT 2
> >
> >
> >
> > The argument in the presentation is that ANY application encoding 
> > adds a
> significant amount of efficiency to the encoding. But this requires 
> closer scrutiny.
> >
> >
> >
> > (Aside: The example discussed in the presentation includes the use 
> > of link
> attributes Maximum reservable link bandwidth(10) and Unreserved
> bandwidth(11) - which are link attributes only usable by RSVP-TE application.
> >
> > As such, they are not candidates to be advertised using either the 
> > ANY bit
> or the ALL encoding defined in RFCs 8919/8920.
> >
> > In the examples below I assume the attributes being used are 
> > potentially
> usable by all applications.)
> >
> >
> >
> > Assume we have the following applications:  APP1 APP2 APP3
> >
> > Assume we have the following link attributes: ATTR1 ATTR2 ATTR3
> >
> >
> >
> > Example 1 (analogous to the example in Shraddha's presentation)
> >
> >
> >
> > ATTR1 and ATTR2 have a value usable by all applications.
> >
> > ATTR3 has two values:
> >
> > One usable by APP1 and APP2 - call it ATTR3-12
> >
> > One usable only by APP3 - call it ATTR3-3
> >
> >
> >
> > Encoding using ANY requires two ASLA 

Re: [Lsr] Question on "Advertisement of Dedicated Metric for Flexible Algorithm in IGP"

[Shraddha Hegde]

Hi,

The draft 
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-02.txt 
introduced generic metric
which has the metric-type and metric-value fields. It is possible that 
metric-type 128 and metric type 129 are advertised for the link and FAD 
definition for Flex-algo 128 uses metric-type 128 and flex-algo 129 uses 
metric-type 129.
It appears to me that the usecase you describe can be solved with generic 
metric.

Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of linchangwang
Sent: Wednesday, March 23, 2022 7:42 PM
To: Acee Lindem (acee) ; Chenmengxiao 
; Aijun Wang ; 
draft-lin-lsr-flex-algo-met...@ietf.org
Cc: lsr@ietf.org
Subject: Re: [Lsr] Question on "Advertisement of Dedicated Metric for Flexible 
Algorithm in IGP"

[External Email. Be cautious of content]


Hi Acee

Very much appreciated- especially in the middle of the busy IETF week.
Thanks for your guidance with the text. We will  post  an update to the draft 
after the IETF week.


Best Regards
Changwang Lin


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 23, 2022 5:31 PM
To: chenmengxiao (RD); Aijun Wang; 
draft-lin-lsr-flex-algo-met...@ietf.org
Cc: lsr@ietf.org
Subject: Re: [Lsr] Re: Question on "Advertisement of Dedicated Metric for 
Flexible Algorithm in IGP"

Hi Mengxiao, Aijun,

Thanks for the clarification of the purpose of the and use case. It would be 
good to state that this document adds algorithm-specific link metrics as 
opposed to a dedicated metric in the title, abstract, and introduction. Will 
follow up but task multiplexing right now so it isn’t a good time to suggest 
text.

Thanks,
Acee

From: Chenmengxiao mailto:chen.mengx...@h3c.com>>
Date: Wednesday, March 23, 2022 at 12:26 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>, 
Acee Lindem mailto:a...@cisco.com>>, 
"draft-lin-lsr-flex-algo-met...@ietf.org"
 
mailto:draft-lin-lsr-flex-algo-met...@ietf.org>>
Cc: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: 答复: [Lsr] Question on "Advertisement of Dedicated Metric for Flexible 
Algorithm in IGP"

Hi, Aijun:

Thank you for the clarification of FAPM sub-TLV. Really helpful :-)


Hi, Acee:

Thank you for the review and comment.

why you couldn’t just use the algorithm-specific metric in section 8 and 9 and 
draft-ietf-lsir-flex-algo
 About the FAPM sub-TLV, I agree with Aijun that it’s used for Prefix 
 Metric, not for Link Metric. According to draft-ietf-lsr-flex-algo, it is 
 usually used in multi-area and multi-domain scenarios. IMHO, FAPM may be 
 not a good solution for our case.

It seems to me that the use case is fairly obscure
 Sorry for that we did not make it clear in the draft. We have revised the 
 use case in the slide, and will update the draft later (maybe after the 
 meeting).

Case 1:

   A--C
   |  |
   |  |
   |  |
   B--D

We have two network slices for the traffic from A to D. For slice 1, the 
network operator expects to use A-B-D as the primary path and A-C-D as the 
backup path. For slice 2, A-C-D is the primary path and A-B-D is the backup 
path.
Bandwidth resources are reserved along the primary paths for slices. On the 
backup path, no dedicated resources are reserved, and the bandwidth is shared 
with BE traffics.
The metric-type of the two Flex-Algorithms are the same since they both care 
about the bandwidth resources.
For Flex-Algo 128, we hope that metrics of link A-B and B-D are smaller than 
link A-C and C-D. But for Flex-Algo 129, we hope link A-C and C-D have smaller 
metrics.

Case 2:

A--C
   /|* |
  / |  *   |
 /  |* |
E---B--D

There is TE-tunnel (or SR Policy) between A and D. A uses the tunnel as a 
short-cut path to D.
In Flex-Algo 128 and 129, forward adjacency is enabled for the tunnel A-D to 
allow other nodes to see it.
The metric of tunnel A-D is different in Flex-Algo 128 and 129 (for example, 
the physical path in Flex-Algo 128 is A-B-D, in Flex-Algo 129 is A-C-D).
So, we hope A can advertise the virtual link A-D with different metrics for 
Flex-Algo 128 and 129.


Best Regards

Mengxiao Chen


发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Aijun Wang
发送时间: 2022年3月23日 9:22
收件人: 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>; 
draft-lin-lsr-flex-algo-met...@ietf.org
抄送: lsr@ietf.org
主题: Re: [Lsr] Question on "Advertisement of Dedicated Metric for Flexible 
Algorithm in IGP"

Hi, Acee:

The Sub-TLV described in Section 8 and section 9 of the 
draft-ietf-lsr-flex-algo is for Prefix Metric, not for Link Metric.
Such sub-TLV is carried with the prefix advertisement. Will you change the name 
and application scope of such Sub-TLV?

Currently, the name is “IS-IS Flexible Algorithm Prefix Metric Sub-TLV”, its 
application 

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Shraddha Hegde]

Hello,

I read this document and have two basic questions.

1.  The advertisement of inter-AS TE LSA in OSPFV2/V3 itself indicates that the 
link is outside IGP domain.
  This information is good enough to apply special treatment to these 
links. 
  Why is it necessary to advertise additional stub-link TLV to indicate 
this same information?
2. The inter-As TE LSAs in OSPF carry the link TLV. All the TE attributes 
related to the link can be
 Advertised as part of this link TLV including interface addresses (in 
local interface address sub-TLV).
It is not clear reading the draft what additional value this new TLV is 
bringing in.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: Tuesday, January 4, 2022 12:29 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; 
draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/__;!!NEt6yMaO-gk!T4jYJBqpTXVICbt3k4d93C7fz-81ikudKyYJpnLHoGUxYTQDjMV428Z-gGZ1XObC$

Please indicate your support or objections by January 18th, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to these drafts.

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!T4jYJBqpTXVICbt3k4d93C7fz-81ikudKyYJpnLHoGUxYTQDjMV428Z-gEw6hnV4$

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

Re: [Lsr] WG Last Call for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-06

[Shraddha Hegde]

This is a very useful feature for large L2 networks and I support the 
publication of this
document.


I have below nits/suggestions on the document.


1. Figure 1: Example Topology of L1 with L2 Borders
The diagram is not legible. The connections between L1 routers
can be removed from the diagram and a description can be added that
R1 layer routers are all connected to R2 layer and so on.
>From the diagram it appears that there is connectivity between R10 and R11
and R11 and R12. If so that link can flood L2 domains and L2 is not
fully disjoint. I would suggest to remove the R10->R11 link to show a pure clos 
topology
in L1.

2.
4.1 Flood reflection TLV
"On a given router, the same value
  of the Flood Reflection Cluster ID MUST be advertised across all
  interfaces advertising the Flood Reflection TLV in IIHs. "

Do we really need this restriction of one single cluster-id on a router?
I am imagining, this cluster-id mechanism can be used to segregate a single 
fabric
into two or more clusters if the fabric size becomes too huge.
The usecase itself is described out of scope for this document elsewhere
which is fine but too restrictive statements like above would discourage further
enhancements so may be worth considering these restrictions to be removed.

3.
4.2.  Flood Reflection Discovery Sub-TLV
" A router receiving multiple Flood Reflection
   Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
   TLV"

   first sub-TLV is not deterministic as multiple TLV 242 can come is different 
fragments.
   Suggest to change as below.
   " A router receiving multiple Flood Reflection
   Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
   TLV of the lowest numbered fragment"

   4.
   "flood reflection tunnel endpoint" and "L1 shortcut"
   terminology should be added to the glossary. These terms are used in sec 4.3
   and reader may not get the context of these terms.



   5. section 4.3

   do we need the F bit? Looks like this info can be derived from the
   C bit in Flood Reflection Discovery Sub-TLV. The ones with C bit set are 
possible shortcut endpoints.
   The ones with C bit cleared are the flood reflector tunnel endpoints.


   6. The tunnel encapsulation attribute has use outside of flood reflector
   (such as RFC 8663). I am more in favor of getting rid of the F bit from this 
sub-TLV
   as to avoid the confusions that may arise when it is used in the absence of 
flood reflectors.

   7.
   " A flood reflector receiving multiple Flood Reflection Discovery
   Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F
   flag set SHOULD use one or more of the specified tunnel endpoints to
   automatically establish one or more tunnels that will serve as flood
   reflection adjacency(-ies)."

   A flood reflector should establish tunnels with clients only and not with
   other flood reflectors. also the cluster id needs to match.
   This text as well as next para needs revision.

   8. sec 4.4

   "The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than
   once in a given TLV.  A router receiving multiple Flood Reflection
   Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV
   and it SHOULD adequately log such violations subject to rate
   limiting."

   IMO should talk abt possibility of same TLV 22 in multiple fragments and
   MUST use first sub-TLV from lowest numbered fragment.

   9.

   "If the clients have a
   direct L2 adjacency they SHOULD use it instead of instantiating a new
   tunnel."

   above statement seems to contradict statement below in sec 4.5
   " A router acting as a flood reflector MUST NOT have any traditional L2
   adjacencies. "





Juniper Business Use Only
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Friday, December 3, 2021 9:22 PM
To: Antoni Przygienda 
Cc: lsr@ietf.org
Subject: [Lsr] WG Last Call for "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-06

[External Email. Be cautious of content]

Speaking as WG member:

I have already supported publication. I have a couple comments:


  1.  Can you add "leave" to the glossary in section 2?
  2.  Section 5.2 is a bit hard to read. I have some suggested changes in my

editorial comments but it would be good to expand the cases into smaller

chunks and make state the overall goals ahead rather than after the details.
  Your call though.

  1.  In section 7, would an IS-IS router really set the overload-bit in L1 but 
not L2?


I've also attached some suggested editorial changes. Some of these are very 
subjective
and I won't feel bad if you don't include them all.

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

Re: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[Shraddha Hegde]

I support the adoption of this work.

I would prefer this to be an experimental track document as the deployment 
experiences are expected to
provide a lot of insight and changes to the algorithms being proposed in the 
document.

I have below comments on the document


  1.  Section 4.6 talks about flooding parameter values accounting for the 
number of adjacencies on LAN interface. I think that the flooding parameters  
should account for total number of ISIS adjacencies on the device as well due 
to the common queues/buffers shared by all adjacencies. This is applicable to 
all the flooding enhancements where receiver is advertising the flooding 
parameters. I think this aspect deserves its own section in the document.





Rgds

Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, November 23, 2021 9:57 PM
To: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - 
draft-decraeneginsberg-lsr-isis-fast-flooding-00

[External Email. Be cautious of content]

Speaking as WG member:

I support WG adoption. My inclination is that this should be experimental track 
and this feel this will allow for faster publication.

Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>
Date: Monday, November 22, 2021 at 9:12 AM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - 
draft-decraeneginsberg-lsr-isis-fast-flooding-00

We indicated the intent to adopt of 
draft-decraeneginsberg-lsr-isis-fast-flooding-00 as an LSR WG document at the 
IETF 112 LSR WG meeting.
We are now confirming WG consensus on this action. Please indicate your support 
or objection on this list by 12:00 AM UTC on December 7th, 2021.

Another question that came to light is whether the document should be standards 
track or experimental. If you have an opinion on this matter, please chime in 
along with your arguments for one track or the other. We probably won't make a 
final decision on this now but let's get the discussion started.

Here is a link for your convenience:

https://datatracker.ietf.org/doc/draft-decraeneginsberg-lsr-isis-fast-flooding/

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Shraddha Hegde]

Huzhibo,

Local protection is always executed on the node where failure occurs (for link 
protection) and the previous node
(for node failure). You don’t really require the failure event to propagate to 
another domain to trigger local protection.

Rgds
Shraddha



Juniper Business Use Only
From: Huzhibo 
Sent: Thursday, November 25, 2021 3:04 PM
To: Shraddha Hegde ; Aijun Wang 
; 'Tony Li' 
Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
; 'Christian Hopps' ; 'lsr' 
; 'Acee Lindem (acee)' ; 'Tony Przygienda' 

Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]

Hi, Shraddha:

If you punch a hole in the summary, the other area nodes come to know about the 
mid-point failure.---> Yes, you're right. Once any node knows about the 
mid-point failure，It can execution local protection by looking up next sid to 
fix SRv6 Policy reachability.

Thanks

Zhibo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Thursday, November 25, 2021 12:11 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
'Tony Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

Aijun,

There are multiple possible solutions for the SR-Policy mid-point failure 
scenario

  1.  Use anycast SID as mid-points for redundancy
  2.  Mid-point failure local protection by looking up next sid (This is 
probably the one you pointed out)
  3.  E2E S-BFD for SR-Policy  path liveness detection

If you punch a hole in the summary, the other area nodes come to know about the 
mid-point failure
and remove the failed node reachability. It is not clear how that is solving 
the SR-Policy liveness problem.

Rgds
Shraddha



Juniper Business Use Only
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; 'Tony 
Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]

Hi, Shraddha:

If the traffic is steered via the SRv6 policy, the intermediate points should 
also be protected. There are already one draft to propose the solution( please 
refer to 
https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05__;!!NEt6yMaO-gk!SSAVRO90Q62ieX5DTTgZBW4FKiC_YHXU9biL8pK-jEOUv7jmUHGUaHAt89kXBaSb$>.)
  In such situation, if the intermediate points located in different areas, how 
then know the liveness of each other if ABR has the summary address advertised? 
We will not consider to configure BFD on every intermediate points.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li mailto:tony...@tony.li>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

WG,

MPLS egress protection framework RFC 8679 provides a mechanism to locally 
protect the traffic during
PE failures. The concepts can be applied to SRv6 as well. This mechanism is 
much more efficient and quick because it locally provides fast protection
And switchover to the other PE.
If you compare this  to  the mechanisms being discussed in this thread where 
the failure information is being
propagated by the egress PE to ABR and then  ABR to the ingress, the failover 
is going to be much slower.
The egress protection technology does not flood any information outside of the 
domain and hence does not
affect the IGP scale.

This is a valid alternate solution to solve the problem at hand IMO.
I would be interested to see if people have use cases where egress protection 
can’t be applied.

Rgds

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Shraddha Hegde]

Aijun,

There are multiple possible solutions for the SR-Policy mid-point failure 
scenario

  1.  Use anycast SID as mid-points for redundancy
  2.  Mid-point failure local protection by looking up next sid (This is 
probably the one you pointed out)
  3.  E2E S-BFD for SR-Policy  path liveness detection

If you punch a hole in the summary, the other area nodes come to know about the 
mid-point failure
and remove the failed node reachability. It is not clear how that is solving 
the SR-Policy liveness problem.

Rgds
Shraddha



Juniper Business Use Only
From: Aijun Wang 
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde ; 'Tony Li' 
Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
; 'Christian Hopps' ; 'lsr' 
; 'Acee Lindem (acee)' ; 'Tony Przygienda' 

Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]

Hi, Shraddha:

If the traffic is steered via the SRv6 policy, the intermediate points should 
also be protected. There are already one draft to propose the solution( please 
refer to 
https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05__;!!NEt6yMaO-gk!SSAVRO90Q62ieX5DTTgZBW4FKiC_YHXU9biL8pK-jEOUv7jmUHGUaHAt89kXBaSb$>.)
  In such situation, if the intermediate points located in different areas, how 
then know the liveness of each other if ABR has the summary address advertised? 
We will not consider to configure BFD on every intermediate points.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li mailto:tony...@tony.li>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

WG,

MPLS egress protection framework RFC 8679 provides a mechanism to locally 
protect the traffic during
PE failures. The concepts can be applied to SRv6 as well. This mechanism is 
much more efficient and quick because it locally provides fast protection
And switchover to the other PE.
If you compare this  to  the mechanisms being discussed in this thread where 
the failure information is being
propagated by the egress PE to ABR and then  ABR to the ingress, the failover 
is going to be much slower.
The egress protection technology does not flood any information outside of the 
domain and hence does not
affect the IGP scale.

This is a valid alternate solution to solve the problem at hand IMO.
I would be interested to see if people have use cases where egress protection 
can’t be applied.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Tony 
Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]


Hi Aijun,

I object to adding negative liveness to the LSDB because of the scale and 
because it adds scale during failures.
[WAJ] If we have no such mechanism, operator should either advertise the host 
routes across areas(which has scale problem), or lose the fast convergences for 
some overlay services(which defeat the user experiences).
Within the real network, there is very rare chance for the massive failure. And 
even such thing happen accidently, the information about node liveness is 
countable, is there any router can’t process such information?
The received unreachable information does not trigger the SPF calculation. Will 
they influence intensively the performance of the router?


If the scale is equal, then I would prefer to see flooding positive information 
rather than negative information.  Operationally this is key: if there is a 
failure and positive information doesn’t propagate, then it’s a bug that will 
be found in due course and the operator can react outside of a failure scenario.

Having a scale failure on top of a topology failure is a far more painful 
scenario.

The odds of a mass failure may be low. The fact of the matter is that they 
still happen. It is our job to ensure that the IGP

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Shraddha Hegde]

WG,

MPLS egress protection framework RFC 8679 provides a mechanism to locally 
protect the traffic during
PE failures. The concepts can be applied to SRv6 as well. This mechanism is 
much more efficient and quick because it locally provides fast protection
And switchover to the other PE.
If you compare this  to  the mechanisms being discussed in this thread where 
the failure information is being
propagated by the egress PE to ABR and then  ABR to the ingress, the failover 
is going to be much slower.
The egress protection technology does not flood any information outside of the 
domain and hence does not
affect the IGP scale.

This is a valid alternate solution to solve the problem at hand IMO.
I would be interested to see if people have use cases where egress protection 
can’t be applied.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr  On Behalf Of Tony Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Christian Hopps ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

[External Email. Be cautious of content]


Hi Aijun,

I object to adding negative liveness to the LSDB because of the scale and 
because it adds scale during failures.
[WAJ] If we have no such mechanism, operator should either advertise the host 
routes across areas(which has scale problem), or lose the fast convergences for 
some overlay services(which defeat the user experiences).
Within the real network, there is very rare chance for the massive failure. And 
even such thing happen accidently, the information about node liveness is 
countable, is there any router can’t process such information?
The received unreachable information does not trigger the SPF calculation. Will 
they influence intensively the performance of the router?


If the scale is equal, then I would prefer to see flooding positive information 
rather than negative information.  Operationally this is key: if there is a 
failure and positive information doesn’t propagate, then it’s a bug that will 
be found in due course and the operator can react outside of a failure scenario.

Having a scale failure on top of a topology failure is a far more painful 
scenario.

The odds of a mass failure may be low. The fact of the matter is that they 
still happen. It is our job to ensure that the IGP performs well when it does.

Increasing the size of the LSDB always affects performance. It slows flooding. 
Some nodes may not realize that SPF is not needed.  When LSP fragments are 
rearranged, inferring that SPF is not necessary is non-trivial. Impacting 
router and network performance is a given.


My understanding is that N node failures would result in O(N) bytes added to 
the LSDB.  If someone has a way to compress that information to O(1), I (and 
Claude Shannon) would be interested.
[WAJ] Do you have other determined solutions except the PUB/SUB mechanism that 
does not exist in current IGP?


None of the mechanisms being discussed currently exist.

I have no objections to Robert’s BGP propagation ideas if that’s workable.

This is simply not the IGP’s job and the IGP is not a dump truck.

Tony


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

Re: [Lsr] Clarification on RFC 7794

[Shraddha Hegde]

Les,

Thank you for the clarification.

Rgds
Shraddha



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Thursday, November 18, 2021 8:36 PM
To: Shraddha Hegde ; lsr@ietf.org
Subject: RE: Clarification on RFC 7794

[External Email. Be cautious of content]

Shraddha -

In the case you mention (redistribution from another protocol), the advertised 
router-id would be the ID of the originating router in the source protocol for 
redistribution.
In your example, this ID would come from OSPF. However, the term "router-id" 
means something different in OSPF. The corresponding identifier would come from 
the OSPF "Router Address TLV" defined in RFC 3630.

I am trying to be precise here. I wasn't certain when you used the term 
"redistributing router" whether you were referring to the source protocol or 
the destination protocol for redistribution.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Thursday, November 18, 2021 12:37 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] Clarification on RFC 7794

WG,


I am looking for clarification on below text in RFC 7794 sec 2.2


"Note that the Router ID advertised is always the Router ID of the

   IS-IS instance that originated the advertisement.  This would be true

   even if the prefix had been learned from another protocol (i.e., with

   the X-flag set as defined in Section 
2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7794*section-2.1__;Iw!!NEt6yMaO-gk!TsPnm1bOgtMrsa_zhSpVlUmP8Gzlx5OYh6JYnHw9hS2XuHuZx-YXZcsM-Q7O46xQ$>)"


If a router is re-distributing a prefix from another ISIS instance it would put 
the source router-id of the
Originating router. If the prefix is being redistributed from another protocol 
(say OSPF) the source router-id of the
Prefix would be set to the router-id of the redistributing router. Is this the 
correct interpretation?

Rgds
Shraddha


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Clarification on RFC 7794

[Shraddha Hegde]

WG,


I am looking for clarification on below text in RFC 7794 sec 2.2


"Note that the Router ID advertised is always the Router ID of the

   IS-IS instance that originated the advertisement.  This would be true

   even if the prefix had been learned from another protocol (i.e., with

   the X-flag set as defined in Section 
2.1)"


If a router is re-distributing a prefix from another ISIS instance it would put 
the source router-id of the
Originating router. If the prefix is being redistributed from another protocol 
(say OSPF) the source router-id of the
Prefix would be set to the router-id of the redistributing router. Is this the 
correct interpretation?

Rgds
Shraddha


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Is it necessary for OSPF and ISIS to have different FAD Constraint Sub-TLV in draft-ietf-lsr-flex-algo-bw-con-1?

[Shraddha Hegde]

Linda,

The ISIS and OSPF sub-TLVs are following the base ISIs and OSPF su-TLV 
structures.
In ISIS it's always 1 octet for type and length each and in OSPF it is 2 
otctets each.
This will help maintain the consistency of protocol processing.

Hope that clarifies
Rgds
Shraddha



Juniper Business Use Only
From: Linda Dunbar 
Sent: Tuesday, October 5, 2021 8:29 AM
To: draft-ietf-lsr-flex-algo-bw-...@ietf.org
Cc: lsr@ietf.org
Subject: Is it necessary for OSPF and ISIS to have different FAD Constraint 
Sub-TLV in draft-ietf-lsr-flex-algo-bw-con-1?

[External Email. Be cautious of content]

Shraddha, Bill, Rajesh, Bruno, Peter, and Tony:

draft-ietf-lsr-flex-algo-bw-con-1 has two different sub-TLVs for ISIS FAD 
Constraint and OSPF FAD constraint. But the only differences are:

  *   ISIS Exclude Minimum Bandwidth sub-TLV has one octet for Type and Length
  *   OSPF Exclude Minimum Bandwidth sub-TLV has two octets for Type and Length

Why can't just have one Exclude Minimum Bandwidth sub-TLV to be used for both 
ISIS and OSPF FlexAlgo?

Thank you very much,
Linda Dunbar
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

[Shraddha Hegde]

Hi Linda,

Pls see inline..



Juniper Business Use Only
From: Linda Dunbar 
Sent: Thursday, September 23, 2021 8:39 PM
To: Shraddha Hegde ; Acee Lindem (acee) ; 
Tony Li ; Peter Psenak (ppsenak) 
Cc: lsr@ietf.org; bruno.decra...@orange.com; Acee Lindem (acee) 

Subject: RE: questions about draft-ietf-lsr-flex-algo-bw-con-01

[External Email. Be cautious of content]

Shraddha,

Thank you very much for the suggestion.

Should the "Edge computing metric" be a value in Metric-Type of the FlexAlgo 
Sub-TLV?
 metric-type is carried in Flex-algo Definition FAD sub-TLV.

Can multiple sub-sub-TLV carried by the  FlexAlgo SubTLV indicate different 
metric-types?
 For one flex-algo there can be only  FAD sub-TLV and one metric-type.
Flex-algo SPF will be computed based on that metric-type.

If YES, the individual metrics sub-subTLV has its own Metrics Type, which can 
be different from the Metric-Type of the FlexAlgo Sub-TLV.  Is it a problem?
 No. Multiple metric-types in one flex-algo is not allowed.
Why would you want to send multiple metric-types?

I am still not clear the different purpose of "Flex-Algorithm" and "Calc-Type". 
Can someone give an example?
 Flex-algo basically runs an algorithm on a given topology to find 
paths. The algorithm is identified by
Calc-type. Currently only SPF algorithm is supported. If you want to run any 
different algorithm you have to
Define new calc-type. From your draft it appeared to me that you will be 
running SPF algorithm on this new type of metric. Is that right?

We will update the draft per Acee's and your suggestion to encode the 5G EC 
servers running environment metrics in the Flexalgo advertisement.

Thank you.

Linda

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: Thursday, September 23, 2021 5:39 AM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Acee Lindem 
(acee) mailto:a...@cisco.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: RE: questions about draft-ietf-lsr-flex-algo-bw-con-01

Hi Linda,

I read your draft draft-dunbar-lsr-5g-edge-compute.
>From my understanding you are using various parameters such as capacity index, 
>preference,network delay etc
To derive a metric. You want to use this derived metric for SPF computation.

My suggestion would be to define new standard metric under generic metric called
"Edge computing metric". This metric would be similar to "bandwidth metric " 
defined in
draft-ietf-lsr-flex-algo-bw-con. This edge computing metric will be computed 
based on various advertised
parameters (similar to bandwidth metric which is computed based on 
link-bandwidth).
A flex-algo can then be used to compute using metric-type "Edge computing 
metric".

Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Linda Dunbar
Sent: Friday, September 17, 2021 12:58 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

[External Email. Be cautious of content]

Shraddha, Bill, Rajesh, Bruno, Peter, and Tony,

Is it correct that the intent of the draft is to prevent some "elephant flows" 
from being placed over certain links?

Section 2.1 listed the TLV for the ISIS Generic Metric

Is the property of preventing some flows being placed on a link to be encoded 
in the Value field of the ISIS Generic Metric  in Section 2.1?

Why not directly included in the value field of Flex Algo TLV?  Section 2.3 
says that using FAPM sub-TLV to indicate Flex Algo needs to use the Generic 
Metric. But this property of preventing some flows to be placed on certain 
links doesn't need to be generic, does it?

How does an IGP node know which link to advertise this property? Is it by 
configuration?

Linda Dunbar



From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, September 15, 2021 4:30 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, Tony,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Wednesday, September 15, 2021 at 3:45 PM
To: Tony Li mailt

Re: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

[Shraddha Hegde]

Hi Linda,

I read your draft draft-dunbar-lsr-5g-edge-compute.
>From my understanding you are using various parameters such as capacity index, 
>preference,network delay etc
To derive a metric. You want to use this derived metric for SPF computation.

My suggestion would be to define new standard metric under generic metric called
"Edge computing metric". This metric would be similar to "bandwidth metric " 
defined in
draft-ietf-lsr-flex-algo-bw-con. This edge computing metric will be computed 
based on various advertised
parameters (similar to bandwidth metric which is computed based on 
link-bandwidth).
A flex-algo can then be used to compute using metric-type "Edge computing 
metric".

Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Linda Dunbar
Sent: Friday, September 17, 2021 12:58 AM
To: Acee Lindem (acee) ; Tony Li ; Peter 
Psenak (ppsenak) 
Cc: lsr@ietf.org; bruno.decra...@orange.com; Acee Lindem (acee) 

Subject: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

[External Email. Be cautious of content]

Shraddha, Bill, Rajesh, Bruno, Peter, and Tony,

Is it correct that the intent of the draft is to prevent some "elephant flows" 
from being placed over certain links?

Section 2.1 listed the TLV for the ISIS Generic Metric

Is the property of preventing some flows being placed on a link to be encoded 
in the Value field of the ISIS Generic Metric  in Section 2.1?

Why not directly included in the value field of Flex Algo TLV?  Section 2.3 
says that using FAPM sub-TLV to indicate Flex Algo needs to use the Generic 
Metric. But this property of preventing some flows to be placed on certain 
links doesn't need to be generic, does it?

How does an IGP node know which link to advertise this property? Is it by 
configuration?

Linda Dunbar



From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, September 15, 2021 4:30 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
bruno.decra...@orange.com; 
lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, Tony,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Wednesday, September 15, 2021 at 3:45 PM
To: Tony Li mailto:tony...@tony.li>>, "Peter Psenak (ppsenak)" 
mailto:ppse...@cisco.com>>
Cc: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, Acee 
Lindem mailto:a...@cisco.com>>, Bruno Decraene 
mailto:bruno.decra...@orange.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] draft-ietf-lsr-flex-algo

Tony,

Answers are inserted below:




From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, September 15, 2021 1:26 PM
To: Peter Psenak mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; Acee 
Lindem (acee) mailto:a...@cisco.com>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
bruno.decra...@orange.com; 
lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo



On Sep 15, 2021, at 11:17 AM, Peter Psenak 
mailto:ppse...@cisco.com>> wrote:

So, if someone wants to define new constraints (e.g., Linda's 
server/application metrics), they would need to define the semantics and 
encodings similar to what is being done for bandwidth metrics in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
 . Then the flex algos could be defined using these metrics. Correct?

yes, they would need to define a new FAD constraint and/or metric only.


I agree that if the goal is a new metric, then that's sufficient.  [Plug for 
generic metrics.]

It sounded a bit like Linda was wanting a fundamental change to the SPF 
algorithm.  If, so, I believe that would require a new Calc-Type. Linda, could 
you please clarify?
[Linda] I don't think so. We want a constrained SPF algorithm that take into 
additional metrics. Just like TE being added into the SPF.

I was thinking that as well. These metrics would be defined to have precedence 
over the path cost - sort of like OSPF Type 2 external metrics do for OSPF AS 
External routes.

Thanks,
Acee

Linda Dunbar

Tony

___
Lsr mailing list
Lsr@ietf.org

Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

[Shraddha Hegde]

Les,


--
> But there is a second dimension – which is that the existence of an 
> “all-APPs” advertisement on a given
>link implicitly means that all applications which have been enabled in the 
>network are using that link.
--

It seems to me that this statement illustrates a disconnect.
Which links are included/excluded from application’s topology is defined by 
applications.
It has been discussed in this list multiple times that the existing 
applications (RSVP, SR-TE, LFA)
use admin-groups/link-affinities to include/exclude links.
Flex-algo is a new application and it has been discussed in this thread that 
admin-group/link-affinities is the
best way to include/exclude links from different flex-algo topologies.

You are arguing that applications will use advertisement of ASLA attributes as 
indication
to include/exclude links from the
Topology. Are you referring to new applications that are going to be invented 
in future?
If so, it would be good to get concrete examples of those future applications.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, August 21, 2021 8:11 PM
To: Tony Przygienda 
Cc: Ron Bonica ; Robert Raszuk ; 
lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-hegde-lsr-asla-any-app-00.txt

[External Email. Be cautious of content]

Tony –

There already is a way to advertise link attributes to be used by “all/any 
application” defined in RFC 8919/8920: Use a zero length ABM.
However, it comes with a restriction: if there exists any ASLA advertisement of 
link attributes with a non-zero ABM that includes a given application bit, that 
application MUST NOT use any attributes advertised in the zero length ABM 
advertisement.

It is that restriction which the authors of draft-hegde-lsr-asla-any-app wish 
to avoid – so they have proposed an alternate way of advertising “any/all 
applications” – which is to use the new A-bit.

Why did we introduce the restriction that if there were application specific 
advertisements for a link for application X that it MUST NOT use the “all-APPs” 
advertisements? We did this because once there were some attributes advertised 
specific to a given application, we thought it became significantly less 
probable that it was safe to assume that the other attributes advertised in 
“all-APPs” applied to application X. We thought that it was less ambiguous to 
say – for a given application – either you use the attributes advertised in 
“all-APPs” – or you use the attributes in the advertisements which explicitly 
mention X – but not both. (This, BTW, implicitly resolves the question of what 
happens when the same attribute is advertised in both forms.)

The more important point is that there are two “dimensions” to consider when 
using an “all-APPs” style advertisement.
Dimension #1 is the more obvious one: the values associated with the attributes 
advertised MUST be the same for all of the apps.
But there is a second dimension – which is that the existence of an “all-APPs” 
advertisement on a given link implicitly means that all applications which have 
been enabled in the network are using that link.
It is this second dimension which has to be considered carefully before using 
an “all-APPs” advertisement.
It is easy to come up with examples of link attributes whose value is expected 
to be the same for any application using that link – maximum link bandwidth is 
an obvious one which exists today. But Ron has suggested other possible 
attributes which can easily be seen as falling into the same category.
But, as I explained in one of my replies to Robert, assuming that a new 
application introduced into the network is intended to use the exact same set 
of links that are being used by the already deployed applications is much more 
problematic.

I believe the authors of draft-hegde-lsr-asla-any-app are focused on the first 
dimension and have not fully considered the second dimension.

One could debate whether the existing “all-APPs” using zero length ABM defined 
in RFC 8919/8920 is better or worse than the proposed “any-APPs” using A-bit. 
But given the extremely limited differences in actual usage between the two 
(please see my original reply on this thread) I don’t think this is worth the 
time. And as introduction of A-bit would require implementations to handle the 
various combinations of possible deployments (only zero ABM, mix of zero-ABM 
and A-bit, all A-bit) I do not see that ROI is worth it.

A few more responses inline.

From: Tony Przygienda mailto:tonysi...@gmail.com>>
Sent: Saturday, August 21, 2021 12:04 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Robert Raszuk 

Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

[Shraddha Hegde]

ion - which is likely to break the deployment of that 
application.

   Les




> -Original Message-
> From: Lsr  On Behalf Of Ron Bonica
> Sent: Thursday, August 19, 2021 8:35 PM
> To: lsr@ietf.org
> Subject: [Lsr] FW: New Version Notification for 
> draft-hegde-lsr-asla-any-app- 00.txt
>
> Folks,
>
> Please review and comment.
>
> Ron
>
>
>
> Juniper Business Use Only
>
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Thursday, August 19, 2021 11:31 PM
> > To: Chris Bowers ; Robert Raszuk 
> > ; Ron Bonica ; Shraddha
> Hegde
> > ; Zhenbin Li 
> > Subject: New Version Notification for 
> > draft-hegde-lsr-asla-any-app-00.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > A new version of I-D, draft-hegde-lsr-asla-any-app-00.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF 
> > repository.
> >
> > Name:   draft-hegde-lsr-asla-any-app
> > Revision:   00
> > Title:  The Application Specific Link Attribute (ASLA) Any 
> > Application Bit
> > Document date:  2021-08-19
> > Group:  Individual Submission
> > Pages:  6
> > URL:
> > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-he
> > gde-lsr-asla-any-app-00.txt__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1
> > D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geAxsITdt$
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-h
> > egde-lsr-asla-any-app__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvT
> > kV3P5eLay-Idc_l_ZIaEFgbm5geNWXUEXS$
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
> > aft-hegde-lsr-asla-any-app__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D
> > 0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geFUeB-LY$
> >
> >
> > Abstract:
> >RFC 8919 and RFC 8920 define Application Specific Link Attributes
> >(ASLA).  Each ASLA includes an Application Identifier Bit Mask.  The
> >Application Identifier Bit Mask includes a Standard Application Bit
> >Mask (SABM) and a User Defined Application Bit Mask (UDABM).  The
> >SABM and UDABM determine which applications can use the ASLA as an
> >input.
> >
> >This document introduces a new bit to the Standard Application
> >Identifier Bit Mask.  This bit is called the Any Application Bit
> >(i.e., the A-bit).  If the A-bit is set, the link attribute can be
> >used by any application.  This includes currently defined
> >applications as well as applications to be defined in the future.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm
> 5geLZeit_R$

___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geLZeit_R$

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

Re: [Lsr] Generic metric: application-specific vs application-independent

[Shraddha Hegde]

Peter,

>no, I don't want to use affinities to do that. That's the whole point.
>ASLA gives you per link per application signaling. No need to use affinities.

The usecase you are describing to exclude links from an application topology is 
very straight 
forward and how this is done is defined by applications.
TE applications have defined a topology filter data model that uses 
link-affinities to Include/exclude links from topology 
 
https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-topology-filter-00.
 
 In your example if application B is any TE application it would be natural to 
use link-affinities.

If application B is LFA, RFC 7916 defines link-coloring and include exclude 
policies to be used (Refer sec 6.2.3).
so it cannot use application bits on metric to exclude links.

If we assume application A and B are both Flex-algos, ASLA  
natively doesn't support Per flex-algo attribute advertisement 
and it is extremely complex to define user-defined bit masks for Each 
flex-algo and assign the bit masks on the metric on every router. 
Operator could use link-affinities to Exclude links 
from flex-algo topology which is much simpler.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Saturday, July 31, 2021 1:07 AM
To: Shraddha Hegde ; Robert Raszuk ; 
Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: Les Ginsberg (ginsberg) ; Tony Li ; 
lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent

[External Email. Be cautious of content]


Shraddha,

On 30/07/2021 18:45, Shraddha Hegde wrote:
> Peter,
>
>> imagine you have an application A and B and a link X. You advertise 
>> application independent metric M on that link X >because you want 
>> application A to use it.
>
>> Application B is also enabled to use the metric M, but you do not want 
>> application B to use metric M on the link X >(because you do not want 
>> application B to include the link X in its topology). How do you do that 
>> without ASLA? The >answer is you can't.
>
> This is very straight forward to do without ASLA.
>   I would define an admin-group and assign that admin group on link X and
>   exclude that admin-group from Application B.
>   This is much common way how
>   operators exclude links from the topology.

no, I don't want to use affinities to do that. That's the whole point.
ASLA gives you per link per application signaling. No need to use affinities.

>
>   The alternative being proposed with ASLA is much more fragile.
>   An operator would have to set the bits for application A and Application B
>   for metric M on every link that he wants to include and reset the
>   application bit B on links that he wants to exclude for application B.

sorry, but setting affinities is not any easier, so the above argument is not 
valid.


Peter



>   Imagine what would happen if he missed setting the bit or resetting
>   the bit on some of the links and how difficult it would be to debug.
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Peter Psenak 
> Sent: Friday, July 30, 2021 7:09 PM
> To: Shraddha Hegde ; Robert Raszuk 
> ; Van De Velde, Gunter (Nokia - BE/Antwerp) 
> 
> Cc: Les Ginsberg (ginsberg) ; Tony Li 
> ; lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs 
> application-independent
>
> [External Email. Be cautious of content]
>
>
> Shraddha,
>
>
> On 30/07/2021 15:22, Shraddha Hegde wrote:
>> Robert,
>>
>>   > Can anyone explain how do I map generic metric to selected 
>> network applications I am to run in the network ?
>>
>> Which application uses which metric type is defined by the application.
>
> imagine you have an application A and B and a link X. You advertise 
> application independent metric M on that link X because you want application 
> A to use it.
>
> Application B is also enabled to use the metric M, but you do not want 
> application B to use metric M on the link X (because you do not want 
> application B to include the link X in its topology). How do you do that 
> without ASLA? The answer is you can't.
>
> thanks,
> Peter
>
>>
>> For example in flex-algo FAD defines which metric-type its going to use.
>>
>> In SR-TE, the constraint list specifies which metric-type it is going 
>> to use.
>>
>> Rgds
>>
>> Shraddha
>>
>> Juniper Business Use Only
>>
>> *From:* Robert Raszuk 
>> *Sent:* Friday, July 30, 2021 6:20 PM
>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
>> 
>> *Cc:* Peter Psenak ; Shraddha Hegde 
>> ; Les Ginsberg (ginsberg) ; 
>> Tony Li ; lsr@ietf.org
&

Re: [Lsr] draft-ietf-lsr-flex-algo-17 (was: I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt)

[Shraddha Hegde]

WG,

This is proposed text change for flex-algo draft.
Any comments on this?

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Shraddha Hegde  
Sent: Wednesday, July 28, 2021 11:47 PM
To: Peter Psenak ; Ron Bonica ; Acee 
Lindem (acee) ; Les Ginsberg (ginsberg) 
; gregory.mir...@ztetx.com; lsr@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
Subject: RE: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: 
draft-ietf-lsr-flex-algo-bw-con-01.txt)

Peter,

  There is an agreement to open the Flex-algo draft and clarify the text
   and here is a proposal for the modified text.
   We can discuss about generic-metric in another thread. 
   
   New text for section "12.  Advertisement of Link Attributes for 
Flex-Algorithm  " 2 nd
And 3rd paragraph.   

  " Link attribute advertisements that are to be used during Flex-
   Algorithm calculation MUST use the Application-Specific Link
   Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920],
   except for the following exceptions.
   
   1. In the case of IS-IS, the L-Flag is set in the ASLA
  advertisement.  If the L-Flag is set, as defined in [RFC8919]
  Section 4.2 subject to the constraints discussed in Section 6 of the
  [[RFC8919], then legacy advertisements MUST be used instead.
   2. There is no way to advertise igp-metric in ASLA advertisements. 
  The Flex-Algorithm calculation MUST use igp-metric
  from legacy advertisements in ISIS and OSPF.
   3. In OSPF, application-independent attributes such as maximum-link-bandwidth
  are advertised in non-ASLA advertisements.
  The Flex-Algorithm calculation in OSPF MUST use non-ASLA advertisements
  for application-independent attributes.
   4. In IS-IS, application-independent attributes such as 
maximum-link-bandwidth
  can be advertised in both ASLA advertisements and legacy advertisements.
  The Flex-Algorithm calculation in IS-IS MAY use legacy advertisements
   for application-independent attributes.

   The mandatory use of ASLA advertisements applies to link attributes
   specifically mentioned in this document (Min Unidirectional Link
   Delay, TE Default Metric, Administrative Group, Extended
   Administrative Group and Shared Risk Link Group) and any other 
   application-specific link
   attributes that may be used in support of Flex-Algorithm in the
   future."


Rgds
Shraddha

Juniper Business Use Only

-Original Message-
From: Peter Psenak 
Sent: Wednesday, July 28, 2021 8:21 PM
To: Ron Bonica ; Acee Lindem (acee) 
; Les Ginsberg (ginsberg) 
; Shraddha Hegde ; 
gregory.mir...@ztetx.com; lsr@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
Subject: Re: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: 
draft-ietf-lsr-flex-algo-bw-con-01.txt)

[External Email. Be cautious of content]


Ron,

the problem in hand is whether Generic Metric should be defined as an 
application specific attribute or not. I have explained several times why 
making it application specific makes sense and also provided examples of other 
metrics that are defined as application specific (TE metric, Delay). There also 
seems to be sufficient support from the WG to make Generic Metric an 
application specific link attribute.

If Generic Metric is defined as an application specific attribute, it MUST be 
advertised in ASLA and only ASLA advertisement MUST be used by flex-algo 
application.

The discussion about application specific nature of Generic Metric is 
orthogonal to what draft-ietf-lsr-flex-algo-17 says.

If you feel the text in draft-ietf-lsr-flex-algo-17 needs to be improved, we 
can do that once the discussion about the Generic Metric being application 
specific or not is closed.

thanks,
Peter


On 27/07/2021 19:32, Ron Bonica wrote:
> Peter,
>
> I agree that we will need to update the flexago draft. But before we do that, 
> can you explain why we need to maintain mandatory use of ASLA?
>
> AFAIKS, by their nature, some attributes are generic while others are 
> application specific. For example, a link's total physical bandwidth is 
> generic, by nature. It will always be the same for all applications. By 
> contrast, the amount of bandwidth available to a specific application is 
> application specific, by nature. It can be different for each application.
>
>Ron
>
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Peter Psenak 
> Sent: Monday, July 26, 2021 2:45 PM
> To: Ron Bonica ; Acee Lindem (acee) 
> ; Les Ginsberg (ginsberg) 
> ; Shraddha Hegde ; 
> gregory.mir...@ztetx.com; lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: Re: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: 
> draft-ietf-lsr-flex-algo-bw-con-01.txt)
>
> [External Email. Be cautious of content]
>

Re: [Lsr] Generic metric: application-specific vs application-independent

[Shraddha Hegde]

Robert,

> Can anyone explain how do I map generic metric to selected network 
> applications I am to run in the network ?

Which application uses which metric type is defined by the application.
For example in flex-algo FAD defines which metric-type its going to use.
In SR-TE, the constraint list specifies which metric-type it is going to use.



Rgds
Shraddha



Juniper Business Use Only
From: Robert Raszuk 
Sent: Friday, July 30, 2021 6:20 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: Peter Psenak ; Shraddha Hegde ; 
Les Ginsberg (ginsberg) ; Tony Li ; 
lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent

[External Email. Be cautious of content]

Hey Gunter,

> It doesn't make sense to have Application specific values if a particular 
> metric is obtained only dynamically,

It sure does.

Please notice what ASLA RFCs say up front in the abstract. ASLA is useful for:

A) application- specific values for a given attribute

AND

B) indication of which applications are using the advertised value for a given 
link.


It does not matter if the value is same or different ... what matters is 
automated and consistent indication which of my applications given new metric 
applies to.

I already mentioned this to Ron here:  
https://mailarchive.ietf.org/arch/msg/lsr/OgGLI8yezUDWU-EZePoIj6y6ENk/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!Tny8sU7cmjqLAbDVnliN7lck7J4tCBAHr10i3CW2G9oviUWo8b2RTJxCXc0gvWOz$>

Can anyone explain how do I map generic metric to selected network applications 
I am to run in the network ?

Thx,
Robert.


On Fri, Jul 30, 2021 at 11:05 AM Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>> wrote:
A little late in the discussion... (PTO events do happen)

a quick opinion on the below discussion on whether Generic metric sub-tlv 
should be encoded on a ASLA or not.
For me, it depends on how the metric for the corresponding metric-type is 
obtained and if it can be configured (static).
It doesn't make sense to have Application specific values if a particular 
metric is obtained only dynamically, for eg, dynamically measured delay is 
going to be same for all applications.
On the contrary, te-metric can be configured, and we can in principle configure 
different values for different applications.

My opinion is that if any of the metric-types in the Generic metric sub-tlv can 
be configured, it should be inside the ASLA.

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

Re: [Lsr] Generic metric: application-specific vs application-independent

[Shraddha Hegde]

Operators have built their networks with link attributes
being configured and used by any application. For example
igp-metric is used by ISIS, then came LDP that used same igp-metric,
RSVP could also use igp-metric. Then came ISIS-SR and SR-TE
and even flex-algo. All these applications could use the same igp-metric.
The networks have evolved like this for 20-30 years.
If an operator wants to design his network for this kind of
network evolution with generic metric going forward, ASLA does not
currently provide an effective solution. ASLA currently has limitations
that make it more complex than necessary for operators who want to
evolve their networks this way.

I am working on a draft to propose improvements to ASLA to
make this kind of evolution less complex. I'll post a draft
soon that will describe limitations of ASLA in its current form
along with proposed improvements.

I would still like to hear about use cases that require
generic metric to be applications-specific and cannot be solved with
application-independent generic metric.


Rgds
Shraddha



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Thursday, July 29, 2021 2:00 AM
To: Tony Li 
Cc: lsr@ietf.org; Shraddha Hegde 
Subject: RE: [Lsr] Generic metric: application-specific vs 
application-independent

[External Email. Be cautious of content]

Tony -

You ask very important questions - but - as Acee has answered in a subsequent 
email - all of these questions were openly debated in the WG during the work on 
what became RFC8919/8920. This debate was contentious, took years, and the WG 
eventually reached consensus on what became the two RFCs.

If every time a new attribute is defined we reopen the original debate, then we 
will never move forward and we will have great difficulty in deploying 
interoperable implementations.

I can respect that you might have preferred a different conclusion on the part 
of the WG - but I hope you will also acknowledge that this is now a resolved 
issue and we need to move forward following the existing RFCs.

Parenthetically, I do believe that answers to your questions can be found in 
the RFCs. The answers may not satisfy you - but we did attempt to include the 
context which drove the ASLA solution.
Thanx.

Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Tony 
Li
Sent: Wednesday, July 28, 2021 1:06 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Shraddha Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent


Les,

ASLA exists to support the advertisement of attributes which can be used in 
application specific ways.


Why do we need separate and different copies of attributes for different 
applications?

The SRLG tries to capture the risk relationships between multiple links. Those 
relationships don't change depending on the application.

Link attributes don't require the variability that ASLA provides, and the 
overhead is high.  How does this cost/benefit ratio make sense?


In any particular deployment case, a given attribute advertisement might be 
used by one app, multiple apps, or all apps.
ASLA allows to unambiguously support all of these cases with a single 
advertisement encoding format.

The correct question to be resolving here is indeed the question which has been 
discussed in an earlier thread: Is Generic Metric a link attribute which can 
have application specific use cases? I think the question to that is 
unquestionably "yes".
That should be enough (IMO of course) to close the discussion.


Well, one nice thing is that there is an entire space of metrics available.  If 
application A wants to use metric 16 and application B wants to use metric 122, 
that's already doable.

Why do we need a separate space per application

Tony

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

[Lsr] Generic metric: application-specific vs application-independent

[Shraddha Hegde]

WG,

   Generic metric as described in 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con
   can advertise multiple metric-types and values and be used
   by any application. All the use cases that I heard from network
   operators while writing the draft could be solved
   using generic-metric advertised in an application-independent way.

   I am looking for clear description of use cases that would benefit from 
advertising
   generic metric in an application specific way. Can any one provide such a 
usecase?

Rgds
Shraddha


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ietf-lsr-flex-algo-17 (was: I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt)

[Shraddha Hegde]

Peter,

  There is an agreement to open the Flex-algo draft and clarify the text
   and here is a proposal for the modified text.
   We can discuss about generic-metric in another thread. 
   
   New text for section "12.  Advertisement of Link Attributes for 
Flex-Algorithm  " 2 nd
And 3rd paragraph.   

  " Link attribute advertisements that are to be used during Flex-
   Algorithm calculation MUST use the Application-Specific Link
   Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920],
   except for the following exceptions.
   
   1. In the case of IS-IS, the L-Flag is set in the ASLA
  advertisement.  If the L-Flag is set, as defined in [RFC8919]
  Section 4.2 subject to the constraints discussed in Section 6 of the
  [[RFC8919], then legacy advertisements MUST be used instead.
   2. There is no way to advertise igp-metric in ASLA advertisements. 
  The Flex-Algorithm calculation MUST use igp-metric
  from legacy advertisements in ISIS and OSPF.
   3. In OSPF, application-independent attributes such as maximum-link-bandwidth
  are advertised in non-ASLA advertisements.
  The Flex-Algorithm calculation in OSPF MUST use non-ASLA advertisements
  for application-independent attributes.
   4. In IS-IS, application-independent attributes such as 
maximum-link-bandwidth
  can be advertised in both ASLA advertisements and legacy advertisements.
  The Flex-Algorithm calculation in IS-IS MAY use legacy advertisements
   for application-independent attributes.

   The mandatory use of ASLA advertisements applies to link attributes
   specifically mentioned in this document (Min Unidirectional Link
   Delay, TE Default Metric, Administrative Group, Extended
   Administrative Group and Shared Risk Link Group) and any other 
   application-specific link
   attributes that may be used in support of Flex-Algorithm in the
   future."


Rgds
Shraddha

Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Wednesday, July 28, 2021 8:21 PM
To: Ron Bonica ; Acee Lindem (acee) 
; Les Ginsberg (ginsberg) 
; Shraddha Hegde ; 
gregory.mir...@ztetx.com; lsr@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
Subject: Re: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: 
draft-ietf-lsr-flex-algo-bw-con-01.txt)

[External Email. Be cautious of content]


Ron,

the problem in hand is whether Generic Metric should be defined as an 
application specific attribute or not. I have explained several times why 
making it application specific makes sense and also provided examples of other 
metrics that are defined as application specific (TE metric, Delay). There also 
seems to be sufficient support from the WG to make Generic Metric an 
application specific link attribute.

If Generic Metric is defined as an application specific attribute, it MUST be 
advertised in ASLA and only ASLA advertisement MUST be used by flex-algo 
application.

The discussion about application specific nature of Generic Metric is 
orthogonal to what draft-ietf-lsr-flex-algo-17 says.

If you feel the text in draft-ietf-lsr-flex-algo-17 needs to be improved, we 
can do that once the discussion about the Generic Metric being application 
specific or not is closed.

thanks,
Peter


On 27/07/2021 19:32, Ron Bonica wrote:
> Peter,
>
> I agree that we will need to update the flexago draft. But before we do that, 
> can you explain why we need to maintain mandatory use of ASLA?
>
> AFAIKS, by their nature, some attributes are generic while others are 
> application specific. For example, a link's total physical bandwidth is 
> generic, by nature. It will always be the same for all applications. By 
> contrast, the amount of bandwidth available to a specific application is 
> application specific, by nature. It can be different for each application.
>
>Ron
>
>
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Peter Psenak 
> Sent: Monday, July 26, 2021 2:45 PM
> To: Ron Bonica ; Acee Lindem (acee) 
> ; Les Ginsberg (ginsberg) 
> ; Shraddha Hegde ; 
> gregory.mir...@ztetx.com; lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: Re: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: 
> draft-ietf-lsr-flex-algo-bw-con-01.txt)
>
> [External Email. Be cautious of content]
>
>
> Hi Ron,
>
> On 26/07/2021 20:30, Ron Bonica wrote:
>> Peter,
>>
>> I think that we are using the term "link attribute" differently. IMO, a link 
>> attribute is any attribute of a link, regardless of whether it is advertised 
>> in the fixed portion of a link advertisement or in a TLV.
>>
>> Are you assuming otherwise? If so, why?
>
> when we are talking about the advertisement of the link attributes, we are 
>

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Shraddha Hegde]

) TE-metric is defined as application specific attribute by RFC 8919/8920 and 
can be advertised in ASLA. The application specific value advertisement of 
TE-metric has been already proved in the field.
Generic Metric is semantically very similar to TE-metric, so I see no reason 
why application specific encoding should not be supported.
3) Flex-algo specification mandates the usage of the ASLA attributes and all of 
the attributes that we are using for flex-algo so far are encoded in ALSA. 
Encoding the Generic Metric outside of ALSA violates that principle.
4) RFC 8919/8920 violation brought by Les below.
thanks,
Peter
On 13/07/2021 17:39, Les Ginsberg (ginsberg) wrote:
> Draft authors -
>
> I note that the new version has altered the advertisement of the Generic 
> Metric sub-TLV so that it is no longer supported in the ASLA sub-TLV.
> This is in direct violation of RFC 8919/8920.
>
> For example, 
> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8919.html*section-6.1__;Iw!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx4pA8WB0$
>   states:
>
> "New applications that future documents define to make use of the 
> advertisements defined in this document MUST NOT make use of legacy 
> advertisements."
>
> Flex-algo is a "new application" in the scope of these RFCs.
>
> Please correct this error.
>
> Thanx.
>
> Les
>
>
>> -Original Message-
>> From: Lsr  On Behalf Of internet-dra...@ietf.org
>> Sent: Monday, July 12, 2021 9:12 AM
>> To: i-d-annou...@ietf.org
>> Cc: lsr@ietf.org
>> Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Link State Routing WG of the IETF.
>>
>>  Title   : Flexible Algorithms: Bandwidth, Delay, Metrics and
>> Constraints
>>  Authors : Shraddha Hegde
>>William Britto A J
>>Rajesh Shetty
>>Bruno Decraene
>>Peter Psenak
>>Tony Li
>> Filename: draft-ietf-lsr-flex-algo-bw-con-01.txt
>> Pages   : 27
>> Date: 2021-07-12
>>
>> Abstract:
>> Many networks configure the link metric relative to the link
>> capacity.  High bandwidth traffic gets routed as per the link
>> capacity.  Flexible algorithms provides mechanisms to create
>> constraint based paths in IGP.  This draft documents a generic metric
>> type and set of bandwidth related constraints to be used in Flexible
>> Algorithms.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
>> tf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2Ku
>> E9gbrUscAHAlbWXMsiRouKOFbEWkxyFWi9bo$
>>
>> There is also an htmlized version available at:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
>> ft-ietf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd
>> 2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkxwbtJYtY$
>>
>> A diff from the previous version is available at:
>> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-i
>> etf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo
>> 2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_rX175v$
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!N
>> Et6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx6
>> GQqw0z$
>>
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>> __;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOF
>> bEWkx_ne0I9C$
>
>
___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_ne0I9C$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[Shraddha Hegde]

I support progressing this draft.

I have a minor comment on the Flags sub-TLV.

In section "ISIS Flexible Algorithm Definition Flags Sub-TLV"
And  "OSPF Flexible Algorithm Definition Flags Sub-TLV"

We should add an explicit statement that

" If any undefined flag is set and that flag is not
Understood by the node it MUST stop participating in the flex-algorithm"

While this information can be derived from previous sections, adding an explicit
Statement in the flags section will help implementors to honor that statement.
If implementations miss this, it would be difficult to deploy features that 
need new flags
In future.

Rgds
Shraddha




Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Thursday, June 24, 2021 10:56 AM
To: Acee Lindem (acee) ; lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; 
draft-ietf-lsr-flex-algo@ietf.org
Subject: RE: Second Working Last Call for draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]

I support progressing this document.
Flex-algo has already been demonstrated to be useful with a number of 
implementations/deployments.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Wednesday, June 16, 2021 7:01 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps 
mailto:cho...@chopps.org>>; 
draft-ietf-lsr-flex-algo@ietf.org
Subject: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

After the first successful WG last call, the authors discovered that some 
re-work was needed for OSPF AS External route calculation - specifically with 
respect to the Flex Algorithm ASBR metrics and calculation. This was fixed and 
there were clarifications in the IANA section (see versions -14 and -15). The 
draft has been stable since April and we are now ready to WG last call the 
updated version.


Without further ado, this begins a 2 week WG Last Call, ending on July 1st, 
2021, for draft-ietf-lsr-flex-algo

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

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  
https://datatracker.ietf.org/ipr/3910/
  
https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.


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

Re: [Lsr] Proposed Errata for RFCs 8919/8920

[Shraddha Hegde]

Les,

> Whether ASLA sub-TLV is present in IS-Neighbor TLV and whether it has 
> zero-length ABM on non-zero-length ABM is irrelevant to the use of ASLA SRLG 
> TLV - and vice versa.

Can you state this explicitly in the document?

Rgds
Shraddha



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Wednesday, June 16, 2021 10:31 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Shraddha Hegde ; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN 
Subject: RE: Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]

Gunter -

There is no relationship between the ASLA SRLG TLV and IS-Neighbor TLV.
I do not understand why you would think that there is.

Whether ASLA sub-TLV is present in IS-Neighbor TLV and whether it has 
zero-length ABM on non-zero-length ABM is irrelevant to the use of ASLA SRLG 
TLV - and vice versa.

   Les


From: Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Sent: Wednesday, June 16, 2021 9:07 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>
Subject: RE: Proposed Errata for RFCs 8919/8920

Another item of ambiguity is whether "wildcarding" applies also to the ISIS 
TE-Appl-Spec-SRLG TLV.
It seems that the RFC8919 does not specify it.
Note: for OSPF the wildcarding also applies to SRLG info because it is 
transported via the same container TLV as the other TE attributes.

Example 1
TE-IS-NBRs TLV
 Link x
  ASLA TLV
  SABML 0, UDABML 0 (= All Appl)
  TE-Metric 20
TE-Appl-Spec-SRLG TLV
Link x
SABML 1, UDABML 0, Bitmap Flex-Algo
   SRLG 1 2 3

Should TE-Metric 20 be used for Flex-Algo or not ?
In other words, is the wildcard ASLA TLV overruled by the specific 
TE-Appl-Spec_SRLG TLV or not ?

Example 2
Maybe this is an invalid example if wildcarding does not apply for the 
TE-Appl-SRLG TLV.
TE-IS-NBRs
 Link x
  ASLA TLV
  SABML 1, UDABML 0, Bitmap Flex-Algo
  TE-Metric 20
TE-Appl-Spec-SRLG
Link x
SABML 0, UDABML 0 (= All Appl)
   SRLG 1 2 3

Should SRLG 1 2 3 be used for Flex-Algo or not ?

What is your opinion ?

G/


From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: Wednesday, June 16, 2021 4:46 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: RE: Proposed Errata for RFCs 8919/8920

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."


For example, If max link bandwidth attribute comes in a
Zero length SABM & UDABM and we have a Flex-algo specific ASLA
that does not have the max-link-bandwidth advertised, can
Flex-algo use max-link-bandwidth attribute?

My interpretation from modified text for ISIS is that,  it cannot use it.
I think there is no harm in re-iterating in order to avoid people reading is 
differently.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Tuesday, June 15, 2021 8:55 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com&

Re: [Lsr] Proposed Errata for RFCs 8919/8920

[Shraddha Hegde]

Hi Les,

I am proposing to include the text I sent along with your text.

You basically want to imply that when there is an ASLA advertised with an 
application bit set
That application MUST use all link attributes that can appear in ASLA from only 
ASLAs
having the specific application bit set and MUST NOT use from zero ABM ASLAs. I 
agree it is possible to
Derive this from your latest text but I would prefer re-iterating this fact 
more directly than
Let the readers derive this information from current text.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised for a link 
with one or more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set for 
that link.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.

Rgds
Shraddha



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Wednesday, June 16, 2021 10:26 PM
To: Shraddha Hegde ; Les Ginsberg (ginsberg) 
; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: RE: Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]

Shraddha -

I believe we are in agreement on when zero length ABM ASLA sub-TLVs can be used 
and when they cannot.

The new text we proposed is:

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

This states both when zero-length ABM advertisements MUST be used and when they 
MUST NOT be used.

You have proposed different text:

"When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length."

This states when zero-length ABM advertisements MUST NOT be used - but it does 
not state when they MUST be used.
Instead, it states when non-zero length ABM advertisements MUST be used.
So this does not seem to be as complete as regards zero length ABM.

You seem to feel that there is confusion as to when non-zero ABM ASLA 
advertisements MUST be used - but I do not understand why that is the case.
You mention Maximum-Link-Bandwidth - for which there is a dedicated Section 
(4.2.1). The need for that section arises in order to make clear that different 
values for maximum-link-bandwidth are nonsensical and if they occur they all 
should be ignored.
But Section 4.2.1 also references Sections 4.2 and 6.2 to make clear that the 
same constraints regarding the use of zero length ABM advertisements apply to 
maximum-link-bandwidth.

So, I am not clear on what text is currently confusing, nor do I understand how 
your proposed text clarifies this confusion.

I am open to revising the proposed text - but I need more help from you to 
understand the source of confusion.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Wednesday, June 16, 2021 7:46 AM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Proposed Errata for RFCs 8919/8920

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advert

Re: [Lsr] Proposed Errata for RFCs 8919/8920

[Shraddha Hegde]

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."


For example, If max link bandwidth attribute comes in a
Zero length SABM & UDABM and we have a Flex-algo specific ASLA
that does not have the max-link-bandwidth advertised, can
Flex-algo use max-link-bandwidth attribute?

My interpretation from modified text for ISIS is that,  it cannot use it.
I think there is no harm in re-iterating in order to avoid people reading is 
differently.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, June 15, 2021 8:55 PM
To: lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: [Lsr] Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

OLD

"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications,
then any standard application and/or any user-defined application is permitted 
to use that set of link attributes so long as there is not another set of 
attributes
advertised on that same link that is associated with a non-zero-length 
Application Identifier Bit Mask with a matching Application Identifier Bit set."

NEW

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."

RFC 8919 Section 6.2

OLD

"Link attribute advertisements associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications are usable
by any application, subject to the restrictions specified in Section 4.2. If 
support for a new application is introduced on any node in a network in the 
presence of such
advertisements, these advertisements are permitted to be used by the new 
application. If this is not what is intended, then existing 

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Hi Ketan,

Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Monday, May 31, 2021 1:14 PM
To: Shraddha Hegde ; Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

When you refer to "a single TE application", it is not clear which one you are 
referring to : RSVP-TE or SR Policy?
 It could be either of them

I believe, for ISIS, you are referring to this specific section of RFC8919 : 
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-6.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdZHekgKS$>

There is no ambiguity here. This section is about use of "legacy" 
advertisement. The Generic Metric is a new TLV and hence cannot be considered 
as "legacy" by any interpretation of the word.
 For ISIS, I hope you agree that generic metric sub-TLV is allowed to 
get advertised under TLV 22.

Coming to OSPF, the considerations are similar. Additionally we also have to 
deal with different LSA types here.

Please refer to 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_Adc5YCVr4$>
 for the equivalent discussion for OSPF. This section is about "legacy" 
advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you 
were referring to was RSVP-TE, then there is also additional guidance provided 
here : 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.2.4__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdRkvFDI2$>


Please clarify where RFC8920 describes advertisement of application-specific 
attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.
 From what I understand, you agree that the generic metric sub-TLV 
should be allowed in TE Opaque LSA.
You have concerns only on it being allowed in Extended Link opaque LSA top 
level Extended Link TLV right?



Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ie

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde ; Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of 
generic metric.



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Tony,

Please check inline below.

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


Hi Ketan,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of 
the proposal to adopt and/or to split documents. I have seen this in recent 
past in other WGs. In any case, it is not a poi

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of 
generic metric.



Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Tony,

Please check inline below.

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


Hi Ketan,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of 
the proposal to adopt and/or to split documents. I have seen this in recent 
past in other WGs. In any case, it is not a point that I wish to argue or 
debate on - especially in the context of this document. My point (8) was 
clarified and hence I fall in the binary YES in this instance.


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it's just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don't know what use-cases might arise. It doesn't seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.

[KT] Regarding metric overflow, I think it would be better to leave it to 
implementations on how to deal with it. A guidance similar to below (from 
draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does 
not cause interop issues. Theoretically, it is something that is independent of 
the size of the metric.

   During the route computation, it is possible for the Flex-Algorithm
   specific metric to exceed the maximum value that can be stored in an
   unsigned 32-bit variable.  In such scenarios, the value MUST be
   considered to be of value 4,294,967,295 during the computation and
   advertised as such.


  1.
  2.  Would be good to cover the max-metric considerations for the Generic 
Metric. Similar to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3


Fair



  1.
  2.  Since the draft is covering FlexAlgo, I would have expected that Generic 

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Snipped..


5.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints, 
I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA 
- 
https://datatracker.ietf.org/doc/html/rfc8920#section-7,
 in case of ISIS also, it is not really appropriate for use within ASLA 
-https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1?


I'm sorry, I don't understand this comment.
[KT] In 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1


The Maximum Link Bandwidth as advertised by the sub-sub-

   TLV 23 of ASLA [RFC 
8920]
 MUST be compared against the Minimum

   bandwidth advertised in FAEMB sub-TLV.

And in the 
https://datatracker.ietf.org/doc/html/rfc8920#section-7


Maximum link bandwidth is an application-independent attribute of the

   link that is defined in 
[RFC3630].
  Because it is an application-

   independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.

Somewhat similar for ISIS as well.


I'm sorry, I'm still not understanding your comment. Are you objecting because 
we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested 
this, updating the other two protocols.


 As per RFC 8920, Maximum Link Bandwidth cannot be advertised in 
ASLA. Will update the text to reflect Maximum Link Bandwidth sub-TLV in 
Extended Link TLV of Extended Link opaque LSA.

For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that different 
values for different applications is not allowed. Maximum Link bandwidth is 
also allowed with all bits set to zero in SABM/UDABM  or each individual 
application bit set for all applications making use of ASLA.

RFC 8919 sec 4.2.1
"  Maximum link bandwidth is an application-independent attribute of the
   link.  When advertised using the Application-Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised.
   This can be accomplished most efficiently by having a single
   advertisement for a given link where the Application Identifier Bit
   Mask identifies all the applications that are making use of the value
   for that link."


  1.  Document should cover the FAPM aspects for the Generic Metric and 
especially the Bandwidth metric.
 As long as we have fixed length generic metric, there won't be any 
changes to FAPM. We'll add a section to clarify about FAPM



Juniper Business Use Only
From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, May 26, 2021 10:10 PM
To: Ketan Jivan Talaulikar 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]


Hi Ketan,


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it's just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don't know what use-cases might arise. It doesn't seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.


Thank you for the suggestion. I don't think anyone has suggested a variable 
length metric before.  A variable length metric is difficult to 

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

>we only need the new TLV to carry FAPM if we make the Generic Metric's size 
>variable. If we keep it fixed size, we >should be fine with the existing FAPM.

Yes agree. 
The idea of making generic metric variable length is worth considering.
I don't see a strong enough usecase right now to make it variable length but 
will wait
for inputs from WG.

Rgds
Shraddha 


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Wednesday, May 26, 2021 10:27 PM
To: Tony Li ; Ketan Jivan Talaulikar 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]


Hi Tony, Ketan,

On 26/05/2021 18:40, Tony Li wrote:

>> */[KT] Generic Metric is used for the links. When we get to the 
>> computation of inter-area or external routes, we will need to get 
>> into FAPM. The draft at a minimum should discuss the applicability of 
>> the Generic Metric and its use as FAPM. Now, if we do make the 
>> Generic Metric size variable (as suggested above), then we will 
>> likely need a new TLV for a variable size FAPM equivalent?/*
>
>
> We would need a new TLV regardless of the metric size as the FAPM TLV 
> only carries the default metric. We are not proposing that TLV at this 
> time. That’s future work.

we only need the new TLV to carry FAPM if we make the Generic Metric's size 
variable. If we keep it fixed size, we should be fine with the existing FAPM.


thanks,
Peter
>
> Tony
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Snipped …


>Shraddha, you've said

>"The measurement mechanisms and advertisements in ISIS support micro-second 
>granularity (RFC 8570)."

>Could you direct me to the text in RFC 8570 that defines the measurement 
>method, protocol that limits the >resolution to a microsecond?



Pls refer RFC 8570 sec 4.1. The link delay is encoded in microseconds

“   Delay:  This 24-bit field carries the average link delay over a
  configurable interval in microseconds, encoded as an integer
  value.  When set to the maximum value 16,777,215
  (16.777215 seconds), then the delay is at least that value and may
  be larger.
“

Exact same text can be found in OSPF RFC 7471 sec 4.1.5 as well.



Rgds

Shraddha





Juniper Business Use Only
From: Lsr  On Behalf Of gregory.mir...@ztetx.com
Sent: Tuesday, May 25, 2021 8:03 AM
To: lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]


Dear All,

thank you for the discussion of my question on the unit of the Maximum Link 
Delay parameter.

Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 
nanoseconds or 100 nanoseconds.

To Tony's question, the delay is usually calculated from the timestamps 
collected at measurement points (MP). Several formats of a timestamp, but most 
protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits 
represent seconds and 32 bits - a fraction of a second. As you can see, the 
nanosecond-level resolution is well within the capability of protocols like 
OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of 
the packet delay metric, I can think of URLLC in the MEC environment. I was 
told that some applications have an RTT budget of in the tens microseconds 
range.



Shraddha, you've said

"The measurement mechanisms and advertisements in ISIS support micro-second 
granularity (RFC 8570)."

Could you direct me to the text in RFC 8570 that defines the measurement 
method, protocol that limits the resolution to a microsecond?



To Acee, I think that

"Any measurement of delay would include the both components of delay"

it depends on where the MP is located (yes, it is another "It depends" 
situation).



I agree with Anoop that it could be beneficial to have a text in the draft that 
explains three types of delays a packet experiences and how the location of an 
MP affects the accuracy of the measurement and the metric.



Best regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


[cid:image001.gif@01D75178.7F44CE20]
[cid:image002.gif@01D75178.7F44CE20]
E: gregory.mir...@ztetx.com
www.zte.com.cn

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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Greg and others,

The measurement mechanisms and advertisements in ISIS support micro-second 
granularity (RFC 8570).
The current draft is defining constraints on these advertised link delay.
The thread below seems to be converging towards micro-second granularity but 
even if we needed nano second granularity, it would not be in the scope of this 
document. We will first have to standardize measurement and advertisement of 
link delay in  nano second granularity.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Christian Hopps 
Sent: Monday, May 24, 2021 7:03 AM
To: Christian Hopps 
Cc: Acee Lindem (acee) ; Greg Mirsky 
; peng.sha...@zte.com.cn; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org; Shraddha Hegde 
; Tony Li ; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


Christian Hopps  writes:

> [[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps 
>  (trust ultimate) created at 
> 2021-05-23T21:12:09-0400 using RSA]]
>
> "Acee Lindem (acee)"  writes:
>
>> Hi Greg,
>>
>>
>>
>> Additionally, in a vacuum light will only travel 300 meters in a 
>> microsecond. So, in a nanosecond, that is less than a foot. What 
>> transmission technology and application do you anticipate that will 
>> require this this precision?
>
> Off by a few magnitude; light travels just shy of 300,000,000 meters per 
> second.

Or not.. getting my kilometers, meters, us and ns mixed up here. :) Your right 
on the transmission delay, sorry.

Thanks,
Chris.

> Consider that 100Gbps links transmit 100 bits every nanosecond. So about 5 
> nanoseconds to send a minimum sized ethernet frame (sans the pre/postamble).
>
> Thanks,
> Chris.
>
>
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>> From: Tony Li  on behalf of Tony Li 
>> 
>> Date: Sunday, May 23, 2021 at 4:56 PM
>> To: Greg Mirsky 
>> Cc: Shraddha Hegde , "peng.sha...@zte.com.cn"
>> , "lsr@ietf.org" , 
>> "draft-hegde-lsr-flex-algo-bw-...@ietf.org"
>> , Acee Lindem 
>> 
>> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
>> Bandwidth, Delay, Metrics and Constraints" -
>> draft-hegde-lsr-flex-algo-bw-con-02
>>
>>
>>
>>
>>
>> Hi Greg,
>>
>>
>>
>> That’s a very fair question and not one that has been discussed.
>>
>>
>>
>> Do we have that kind of accuracy from any of our measurement tools?
>> Is that even on the horizon?  I haven’t seen that…
>>
>>
>>
>> If it is time for nanosecond level measurement, then is it time to 
>> shift to floating point to give us more range?
>>
>>
>>
>> Tony
>>
>>
>>
>> On May 23, 2021, at 1:04 PM, Greg Mirsky 
>> wrote:
>>
>>
>>
>> Hi Shraddha, Authors, et al.,
>>
>> I apologize if my question has already been discussed. The unit
>> for the maximum link delay in the draft is a microsecond. There
>> is a group of services that require a highly accurate bounded
>> delay. Have you considered using a nanosecond as the unit for the
>> link delay?
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Wed, May 19, 2021 at 9:17 PM Shraddha Hegde > 40juniper@dmarc.ietf.org> wrote:
>>
>> Hi Pengshaofu,
>>
>>
>>
>> Pls see inline..
>>
>>
>>
>>
>>
>>   Juniper Business Use Only
>>
>> From: peng.sha...@zte.com.cn 
>> Sent: Thursday, May 20, 2021 7:26 AM
>> To: Shraddha Hegde 
>> Cc: acee=40cisco@dmarc.ietf.org; lsr@ietf.org;
>> draft-hegde-lsr-flex-algo-bw-...@ietf.org
>> Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible
>> Algorithms: Bandwidth, Delay, Metrics and Constraints" -
>> draft-hegde-lsr-flex-algo-bw-con-02
>>
>>
>>
>> [External Email. Be cautious of content]
>>
>>
>>
>>
>>
>> Hi Shraddha,
>>
>>
>>
>> Thanks. Actually, I don't really want to define other metric
>> types.
>>
>> Let's go back to the bandwidth-metric related to bandwidth
>> capability. My worry is that bandwidth-metric (whether it is
>> automatically calculated or manually configured) is not
>>   

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Hi Pengshaofu,

Pls see inline..



Juniper Business Use Only
From: peng.sha...@zte.com.cn 
Sent: Thursday, May 20, 2021 7:26 AM
To: Shraddha Hegde 
Cc: acee=40cisco@dmarc.ietf.org; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]




Hi Shraddha,



Thanks. Actually, I don't really want to define other metric types.

Let's go back to the bandwidth-metric related to bandwidth capability. My worry 
is that bandwidth-metric (whether it is automatically calculated or manually 
configured) is not cumulative in nature,

 Yes that is correct.

which is different from IGP default metric/TE metric/delay metric,



so that SPF based on bandwidth-metric may get an unexpected path (see the 
example of the original mail).

Can more text be added in the draft to describe why this can work ?

 Knowing that metric derived inversely from the link bandwidth is not 
additive in nature, should set the expectation right. I can add some text in 
this regard.



Regards,

PSF




原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org>;
日 期 ：2021年05月18日 13:01
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Pengshaofu,

If an operator wants to configure any other metric type draft provides a 
mechanism with generic metric.
Generic metric allows any standard or user-defined type metric to be configured.
The draft allows for any computing application such as Flex-algo, CSPF etc to 
make use of the
Metric. The intention of the draft is that for a particular computation same 
metric-type is used
throughout the network. If that is not clear, I’ll add some text in the draft.

Using a combination of different metrics for a single computation would need 
significant change to SPF algorithm and it is not in the scope of the draft 
"Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints".

Hope that clarifies.

Rgds
Shraddha



Juniper Business Use Only
From: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn> 
mailto:peng.sha...@zte.com.cn>>
Sent: Monday, May 17, 2021 12:49 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: acee=40cisco@dmarc.ietf.org<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]




Hi Shraddha,



The two methods of automatic generation of BW-metric introduced in the draft 
are also likely to be the method of manual configuration of BW-metric by 
operators. Operators can certainly manually configure any  BW-metric he wants 
to configure.

However, the manually configured BW-metric cannot deviate from the actual 
bandwidth capacity of the link, otherwise it could be any other names such as 
BX-metric.

For manual assignment, the problem may still exist We can find an example that  
the accumulated bandwidth-metric on the path may offset the manually increased 
bandwidth-metric of links on the path.

Combination of bandwidth attribute of link and other metric that is cumulative 
may be another co-exist way to completely address this issue.



Regards,

PSF








原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org>;
日 期 ：2021年05月17日 12:15
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Pengshaofu,

I was suggesting to manually assign bandwidth metric which will override the 
automatic metric calculation
as described in the draft section 5. Physically adding more fiber/capacity is 
not a feasible solution.

Rgds
Shraddha



Juniper Business Use Only
From: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn> 
mailto:peng.sha...@zte.com.cn>>
Sent: Monday, May 17, 2021 7:40 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: acee=40cisco@dmarc.ietf.org<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

>[Jie] I can understand how this works for a single Flex-Algo, while my 
>question was if more than one Flex-Algo use
>bandwidth as constraint to exclude some links, what would be the consequence 
>to the network?

Operators design and plan whether one flex-algo is suitable for their network 
or multiple. The planning also involves
the definition of each flex-algo that is suitable for their network. This 
network planning exercise has to be done
irrespective of whether bandwidth constraints are used in the flex-algo to 
ensure traffic distribution is even.

Rgds
Shraddha





Juniper Business Use Only
From: Dongjie (Jimmy) 
Sent: Wednesday, May 19, 2021 12:59 PM
To: Shraddha Hegde ; Acee Lindem (acee) 
; lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

Thanks for your reply. Please see further inline:

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi authors,

I've read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?
Yes. Any application can make use of generic metric including 
Flex-algo and SR-TE.
  Sure. I'll add some text to clarify this.

[Jie] OK, thanks.



2.   The "Exclude Minimum Bandwidth" constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?
 The motivation for "Exclude Minimum Bandwidth" is to avoid low 
capacity links for the high bandwidth traffic. For example if the Flex-algo 128 
carries high bw traffic flows of bw greater than 10g, it makes sense to remove 
1g links from this flex-algo topology since these links if happen to carry 
traffic, it  will get congested and traffic will be dropped. The introduction 
section talks about this motivation.

[Jie] I can understand how this works for a single Flex-Algo, while my question 
was if more than one Flex-Algo use bandwidth as constraint to exclude some 
links, what would be the consequence to the network?





Perhaps a more general question is, what would be the benefit of introducing 
bandwidth attribute into Flex-Algo based distributed path computation?  It is 
known that bandwidth can be used in centralized computation for efficient path 
placement and resource management, can distributed computation with bandwidth 
constraint achieve the same, or is there some advantages compared with 
centralized computation?

 Many network operators assign link metric relative to bandwidth of 
the link and it is 

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Hi Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) 
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) ; Acee Lindem (acee) 
; lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi authors,

I've read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?
Yes. Any application can make use of generic metric including 
Flex-algo and SR-TE.
  Sure. I'll add some text to clarify this.


2.   The "Exclude Minimum Bandwidth" constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?
 The motivation for "Exclude Minimum Bandwidth" is to avoid low 
capacity links for the high bandwidth traffic. For example if the Flex-algo 128 
carries high bw traffic flows of bw greater than 10g, it makes sense to remove 
1g links from this flex-algo topology since these links if happen to carry 
traffic, it  will get congested and traffic will be dropped. The introduction 
section talks about this motivation.



Perhaps a more general question is, what would be the benefit of introducing 
bandwidth attribute into Flex-Algo based distributed path computation?  It is 
known that bandwidth can be used in centralized computation for efficient path 
placement and resource management, can distributed computation with bandwidth 
constraint achieve the same, or is there some advantages compared with 
centralized computation?

 Many network operators assign link metric relative to bandwidth of 
the link and it is an existing practice. The draft is defining new attributes 
and constraints in order to simplify and automate this process.

It does not propose any bandwidth reservation/ bandwidth management solutions 
that a centralized computation or distributed RSVP based solutions provide.



3.   With the automatic metric calculation, it could introduce per 
Flex-Algo link metric value, while the existing Flex-Algo only refers to the 
metric of the link via metric type. Is this the expected behavior? Will it be 
further extended to make other link attributes flex-algo specific?



4.   In the reference bandwidth method, the draft says it simplifies the 
management in case the reference bandwidth needs to be changed. Since the 
reference bandwidth applies to the metric calculation of all the links in the 
flex-algo with the same proportion, it seems the change of the reference 
bandwidth will not impact the result of the path computation in the flex-algo. 
In which case the reference bandwidth need to be changed?
 Lets take a hypothetical example. Lets say a network starts with all 
1G links and 10G reference bw.
Over the years, many links get upgraded to 10G links and some get upgraded to 
100G links. Using a 10G reference bandwidth will not be feasible and reference 
bw need to get increased to a value > 100G.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: lsr@ietf.org
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

 

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Hi Pengshaofu,

If an operator wants to configure any other metric type draft provides a 
mechanism with generic metric.
Generic metric allows any standard or user-defined type metric to be configured.
The draft allows for any computing application such as Flex-algo, CSPF etc to 
make use of the
Metric. The intention of the draft is that for a particular computation same 
metric-type is used
throughout the network. If that is not clear, I’ll add some text in the draft.

Using a combination of different metrics for a single computation would need 
significant change to SPF algorithm and it is not in the scope of the draft 
"Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints".

Hope that clarifies.

Rgds
Shraddha



Juniper Business Use Only
From: peng.sha...@zte.com.cn 
Sent: Monday, May 17, 2021 12:49 PM
To: Shraddha Hegde 
Cc: acee=40cisco@dmarc.ietf.org; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]




Hi Shraddha,



The two methods of automatic generation of BW-metric introduced in the draft 
are also likely to be the method of manual configuration of BW-metric by 
operators. Operators can certainly manually configure any  BW-metric he wants 
to configure.

However, the manually configured BW-metric cannot deviate from the actual 
bandwidth capacity of the link, otherwise it could be any other names such as 
BX-metric.

For manual assignment, the problem may still exist We can find an example that  
the accumulated bandwidth-metric on the path may offset the manually increased 
bandwidth-metric of links on the path.

Combination of bandwidth attribute of link and other metric that is cumulative 
may be another co-exist way to completely address this issue.



Regards,

PSF








原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org>;
日 期 ：2021年05月17日 12:15
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Pengshaofu,

I was suggesting to manually assign bandwidth metric which will override the 
automatic metric calculation
as described in the draft section 5. Physically adding more fiber/capacity is 
not a feasible solution.

Rgds
Shraddha



Juniper Business Use Only
From: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn> 
mailto:peng.sha...@zte.com.cn>>
Sent: Monday, May 17, 2021 7:40 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: acee=40cisco@dmarc.ietf.org<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]




Hi Shraddha,



Thanks for your rely.

So it seems that the scheme may lead to the selection of links with less 
bandwidth. To address this point, the method as you described to assign more 
bandwidth to high bandwidth links seems not always possible, e.g, adding more 
fiber ?

Can this point can be addressed by combination of bandwidth attribute of link 
and other metric that is cumulative ? IMO, bandwidth is not cumulative.



Regards

PSF


原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org>;
日 期 ：2021年05月13日 21:01
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Peng shaofu,

As per the draft, if automatic metric calculation with reference bandwidth 
method is used to calculate the metric
Then as per your example s->D path will be chosen since metric is 10.
Lets say operator wants to choose S->X1->X2--->X10->D path then operator can 
manually assign higher bandwidth
Metric on S->D link which will ensure S->D path is not the least cost path.

Rgds
Shraddha



Juniper Business Use Only
From: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn> 
mailto:peng.sha...@zte.com.cn>>
Sent: Thursday, May 13, 2021 1:05 PM
To: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Cc: acee=40cisco@dmarc.ietf.org<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Hi Pengshaofu,

I was suggesting to manually assign bandwidth metric which will override the 
automatic metric calculation
as described in the draft section 5. Physically adding more fiber/capacity is 
not a feasible solution.

Rgds
Shraddha



Juniper Business Use Only
From: peng.sha...@zte.com.cn 
Sent: Monday, May 17, 2021 7:40 AM
To: Shraddha Hegde 
Cc: acee=40cisco@dmarc.ietf.org; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]




Hi Shraddha,



Thanks for your rely.

So it seems that the scheme may lead to the selection of links with less 
bandwidth. To address this point, the method as you described to assign more 
bandwidth to high bandwidth links seems not always possible, e.g, adding more 
fiber ?

Can this point can be addressed by combination of bandwidth attribute of link 
and other metric that is cumulative ? IMO, bandwidth is not cumulative.



Regards

PSF


原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org>;
日 期 ：2021年05月13日 21:01
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Peng shaofu,

As per the draft, if automatic metric calculation with reference bandwidth 
method is used to calculate the metric
Then as per your example s->D path will be chosen since metric is 10.
Lets say operator wants to choose S->X1->X2--->X10->D path then operator can 
manually assign higher bandwidth
Metric on S->D link which will ensure S->D path is not the least cost path.

Rgds
Shraddha



Juniper Business Use Only
From: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn> 
mailto:peng.sha...@zte.com.cn>>
Sent: Thursday, May 13, 2021 1:05 PM
To: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Cc: acee=40cisco@dmarc.ietf.org<mailto:acee=40cisco@dmarc.ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]




Sorry for spelling mistakens in the previous email.

updated text:





Hi WG,



I have a little doubt about the scheme described in this document.

See the following example:



S  X1 - X2  ... ... - X10 - D

\--/



Suppose the links in S---X1---X2...---D have the same bandwidth  10G, and the 
link S-D has bandwidth 1G.

Suppose that we select "reference bandwidth = 100G", then,

each link  in S---X1---X2...---D will have the same bandwidth-metric  10 (i.e., 
100/10)

link S-D will have a bandwidth-metric 100 (i.e., 100/1)



So flex-algo path from S to D based on bandwidth-metric will be S-D, not 
S---X1---X2...---D, because the later has a large cumulative bandwitdh-metric 
(i.e., 11*10).

But our expect path should not be S-D, but S---X1---X2...---D, as it has large 
bandwidth.

Do I misunderstand anything ?



Regards,

PSF








发件人：AceeLindem(acee)
收件人：lsr@ietf.org<mailto:lsr@ietf.org>;
抄送人：draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>;
日 期 ：2021年05月13日 05:49
主 题 ：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsL6l_0sA$>
Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

 
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsET5yKGD$>

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee






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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Hi Peng shaofu,

As per the draft, if automatic metric calculation with reference bandwidth 
method is used to calculate the metric
Then as per your example s->D path will be chosen since metric is 10.
Lets say operator wants to choose S->X1->X2--->X10->D path then operator can 
manually assign higher bandwidth
Metric on S->D link which will ensure S->D path is not the least cost path.

Rgds
Shraddha



Juniper Business Use Only
From: peng.sha...@zte.com.cn 
Sent: Thursday, May 13, 2021 1:05 PM
To: peng.sha...@zte.com.cn
Cc: acee=40cisco@dmarc.ietf.org; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]




Sorry for spelling mistakens in the previous email.

updated text:





Hi WG,



I have a little doubt about the scheme described in this document.

See the following example:



S  X1 - X2  ... ... - X10 - D

\--/



Suppose the links in S---X1---X2...---D have the same bandwidth  10G, and the 
link S-D has bandwidth 1G.

Suppose that we select "reference bandwidth = 100G", then,

each link  in S---X1---X2...---D will have the same bandwidth-metric  10 (i.e., 
100/10)

link S-D will have a bandwidth-metric 100 (i.e., 100/1)



So flex-algo path from S to D based on bandwidth-metric will be S-D, not 
S---X1---X2...---D, because the later has a large cumulative bandwitdh-metric 
(i.e., 11*10).

But our expect path should not be S-D, but S---X1---X2...---D, as it has large 
bandwidth.

Do I misunderstand anything ?



Regards,

PSF








发件人：AceeLindem(acee)
收件人：lsr@ietf.org;
抄送人：draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日 期 ：2021年05月13日 05:49
主 题 ：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

 https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee




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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

I am not aware of any IPR related to this draft.

Rgds
Shraddha



Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Thursday, May 13, 2021 2:39 AM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

 https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee


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

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[Shraddha Hegde]

Les,

I don't agree with mandating prefix attributes sub-TLV in locator TLV at this 
stage of publication
when there are multiple implementations that don't originate it.
There are usecases that can be deployed without prefix attributes sub-TLV.

I propose that we clarify the specific usecases that require prefix attributes 
sub-TLVs to be associated with locator TLV. For example, we should add the 
TI-LFA with leaked locators across multiple levels that Gunter pointed out,
and add a statement that prefix attributes sub-tlv SHOULD be originated in 
locator TLV
for this usecase to be supported.

Rgds
Shraddha


Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Wednesday, May 12, 2021 3:59 AM
To: Shraddha Hegde ; Alvaro Retana 
; Peter Psenak (ppsenak) ; 
lsr@ietf.org; Gengxuesong (Geng Xuesong) 
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
Subject: RE: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

[External Email. Be cautious of content]

Shraddha/ Xuesong -

Since Prefix Attributes sub-TLV is required for correct operation when a 
Locator is leaked, would it be safe to assume that your implementations either 
do not leak Locators or you advise your customers not to deploy this feature 
with multiple levels?

The problem with allowing the sub-TLV to be optional is that if the sub-TLV is 
omitted you cannot tell whether the Locator has been leaked - so you don't know 
whether you have a problem or not.

The safest thing to do is require prefix-attributes sub-TLV always - then you 
can guarantee that if the prefix is leaked the necessary information will be 
present.
Anything else leaves us vulnerable.

We all appreciate interoperability considerations, but frankly this is a gap 
that needs to be closed to support correct operation.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Tuesday, May 11, 2021 8:21 AM
To: Alvaro Retana mailto:aretana.i...@gmail.com>>; 
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

Juniper has an  implementation of SRv6 that does not support Prefix attributes 
sub-tlv in locator TLV.
We would prefer not to change the optional sub-TLV to MUST.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Alvaro Retana
Sent: Friday, May 7, 2021 7:23 PM
To: Peter Psenak mailto:ppse...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>;
 Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

[External Email. Be cautious of content]

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:

> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm 
requesting it to be put on the May/20 telechat, which means that we should have 
a resolution and updated draft by the end of next week.


Thanks!

Alvaro.



On May 3, 2021 at 5:17:58 AM, Peter Psenak 
(ppse...@cisco.com<mailto:ppse...@cisco.com>) wrote:
Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we
can start to mandate the Prefix Attribute Flags TLV at this point.

Technically I agree with you and if everybody agrees, I'm fine to
enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

thanks,
Peter


On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
>
> Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the 
> prefix-attribute tlv 

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[Shraddha Hegde]

Juniper has an  implementation of SRv6 that does not support Prefix attributes 
sub-tlv in locator TLV.
We would prefer not to change the optional sub-TLV to MUST.

Rgds
Shraddha




Juniper Business Use Only
From: Lsr  On Behalf Of Alvaro Retana
Sent: Friday, May 7, 2021 7:23 PM
To: Peter Psenak ; lsr@ietf.org
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

[External Email. Be cautious of content]

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:

> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm 
requesting it to be put on the May/20 telechat, which means that we should have 
a resolution and updated draft by the end of next week.


Thanks!

Alvaro.



On May 3, 2021 at 5:17:58 AM, Peter Psenak 
(ppse...@cisco.com) wrote:
Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we
can start to mandate the Prefix Attribute Flags TLV at this point.

Technically I agree with you and if everybody agrees, I'm fine to
enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

thanks,
Peter


On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
>
> Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the 
> prefix-attribute tlv is mandatory when a locator is redistributed?
>
> Why?
> *When calculating a LFA for an SRv6 End.SID we better know if the locator has 
> been redistributed or not for a correct operation.
>
> Reasoning:
> * A locator has the D bit. This one is set when we redistribute from L2 to L1.
> ** So this end-sid will not be used as we know that it is redistributed.
>
> * In the other direction (L1-L2), we only know that a locator is 
> redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised.
> ** This means if the operator does not configure advertisement of the 
> prefix-attribute tlv, ISIS could potentially use an end-sid which does not 
> terminate on the expected node.
>
> * Compared to sr-mpls, a prefix-sid has the R flag indicating it is 
> redistributed.
> * We don't have that for locator end-sids.
>
> Relevant snip from " draft-ietf-lsr-isis-srv6-extensions"
>
> 7.1. SRv6 Locator TLV Format
>
> The SRv6 Locator TLV has the following format:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length |R|R|R|R| MT ID |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Type: 27
>
> Length: variable.
>
> R bits: reserved for future use. They MUST be
> set to zero on transmission and MUST be ignored on receipt.
>
> MT ID: Multitopology Identifier as defined in [RFC5120].
> Note that the value 0 is legal.
>
> Followed by one or more locator entries of the form:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Metric |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Flags | Algorithm |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Loc Size | Locator (variable)...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Sub-TLV-len | Sub-TLVs (variable) . . . |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> Metric: 4 octets. As described in [RFC5305].
>
> Flags: 1 octet. The following flags are defined
>
> 0
> 0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+
> |D| Reserved |
> +-+-+-+-+-+-+-+-+
>
> where:
> D-flag: Same as described in section 4.1. of [RFC5305].
>
>
> G/
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Shraddha Hegde]

OSPF transport instance work is useful and I support the WG adoption 
subject to below major comments being addressed by authors.

Major comments
1. Add a section on how to advertise information in a transport instance if an 
application requires,
 per-link resource information to be advertised in transport instance.
2. Some applications may require to co-relate the information in transport 
instance
 to a specific routing-instance. This requirement to be addressed.

 Minor comments

 1. There may be cases when application information gets associated with 
prefixes rather than nodes
 We should allow advertisement of Extended Prefix-LSA and 
E-Intra-area-Prefix-LSA/E-Inter-Area-Prefix-LSA
  Advertisements inside transport instance.
2. It seems like we could reuse RI-LSA and originate RI-LSA in transport 
instance with application-ID TLV. What is the 
 Need to define yet another opaque LSA?

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: Sunday, May 2, 2021 2:09 PM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; cho...@chopps.org; 
draft-acee-lsr-ospf-transport-insta...@ietf.org
Subject: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[External Email. Be cautious of content]


This begins a 2 week WG adoption call for the following draft:


https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/__;!!NEt6yMaO-gk!RT_7qdzc7ZQ8JOAaCq5xunM6cbtAZMc171mp6OGUOdD-ZBwm9uzOnteWeQqN3Ryo$

Please indicate your support or objection by May 16th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Historical Note: The original OSPF transport instance document was adopted by 
the OSPF WG back in 2009, it was last updated in 2014, and then revived as an 
individual submission to LSR in Sep 2020. :)

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RT_7qdzc7ZQ8JOAaCq5xunM6cbtAZMc171mp6OGUOdD-ZBwm9uzOnteWeTnw4gEn$

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

[Lsr] FW: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-02.txt

[Shraddha Hegde]

All,

We have posted -02 version of the draft-hegde-lsr-flex-algo-bw-con-02 .
Major changes

1. New metric called generic metric has been defined with metric-type and 
metric values
 The metric type can be standard metric type or user defined metric type. 
  Bandwidth metric is one of the standard metric type
2.  IANA related changes specific to the generic metric type
3. Editorial changes 

Request working group to review and provide comments.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: internet-dra...@ietf.org  
Sent: Friday, April 16, 2021 4:17 PM
To: Bruno Decraene ; Peter Psenak 
; Rajesh M ; Rajesh M 
; Shraddha Hegde ; Tony Li 

Subject: New Version Notification for draft-hegde-lsr-flex-algo-bw-con-02.txt

[External Email. Be cautious of content]


A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-02.txt
has been successfully submitted by Shraddha Hegde and posted to the IETF 
repository.

Name:   draft-hegde-lsr-flex-algo-bw-con
Revision:   02
Title:  Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints
Document date:  2021-04-16
Group:  Individual Submission
Pages:  27
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-02.txt__;!!NEt6yMaO-gk!VyzSzDdeiQaqpxw75PS0o-N-G10jytAHylT-84_vALEBOnOKfV35KpnVEp9dfmHW$
Status: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!VyzSzDdeiQaqpxw75PS0o-N-G10jytAHylT-84_vALEBOnOKfV35KpnVEnVHRcO-$
Htmlized:   
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!VyzSzDdeiQaqpxw75PS0o-N-G10jytAHylT-84_vALEBOnOKfV35KpnVEtxz_bWZ$
Htmlized:   
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-02__;!!NEt6yMaO-gk!VyzSzDdeiQaqpxw75PS0o-N-G10jytAHylT-84_vALEBOnOKfV35KpnVEp9D1uaL$
Diff:   
https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-hegde-lsr-flex-algo-bw-con-02__;!!NEt6yMaO-gk!VyzSzDdeiQaqpxw75PS0o-N-G10jytAHylT-84_vALEBOnOKfV35KpnVEo7SMYTw$

Abstract:
   Many networks configure the link metric relative to the link
   capacity.  High bandwidth traffic gets routed as per the link
   capacity.  Flexible algorithms provides mechanisms to create
   constraint based paths in IGP.  This draft documents a generic metric
   type and set of bandwidth related constraints to be used in Flexible
   Algorithms.





Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Shraddha Hegde]

I agree problem is valid for networks that use summarization and leaking for 
inter-domain connectivity.
However, I don't think the solution space has to be in IGP.
There are various different ways the problem could be solved. 
A network could deploy egress protection [RFC 8679] or anycast based egress 
protection
[draft-hegde-rtgwg-egress-protection-sr-networks] which will ensure packets 
aren't dropped
Due to remote PE node failure. This mechanism is faster compared to other 
possible
Solutions  because if addresses failure  at the PLR and provides protection.


Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Tuesday, March 9, 2021 5:07 PM
To: Robert Raszuk 
Cc: Gyan Mishra ; Aijun Wang 
; Aijun Wang ; Tony Li 
; lsr ; Acee Lindem (acee) ; 
draft-wang-lsr-prefix-unreachable-annoucement 

Subject: Re: [Lsr] 
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[External Email. Be cautious of content]


Robert,

On 09/03/2021 12:20, Robert Raszuk wrote:
>
>  > In addition you may have a hierarchical RR, which would still 
> involve  > BGP signalling.
>
> Last time I measured time it takes to propage withdraw via good RR was 
> single milliseconds.
>
>
>  > because BGP signalling is prefix based and as a result slow.
> +
>  > that is the whole point, you need something that is prefix independent.
>
> BGP can be easily setup in prefix independent way today.
>
> Example 1:
>
> If session to PE1 goes down, withdraw all RDs received from such PE.

still dependent on RDs and BGP specific. We want app independent way of 
signaling the reachability loss. At the end that's what IGPs do without a 
presence of summarization.

Again, I'm not advocating the solution proposed in 
draft-wang-lsr-prefix-unreachable-annoucement. I'm just saying the problem 
seems valid  and IGP based solution is not an unreasonable thing to consider if 
a reasonable one can be found.

>
> Example 2:
>
> Use IGP recursion - Use RFC3107 to construct your interarea LSPs. If 
> PE

there is no LSP in SRv6.

Peter

> goes down withdraw it. IGP can still signal summary no issue as no
> inet.3 route.
>
> Best,
> R.
>
>
> On Tue, Mar 9, 2021 at 12:12 PM Peter Psenak  > wrote:
>
> Hi Robert,
>
> On 09/03/2021 12:02, Robert Raszuk wrote:
>  > Hey Peter,
>  >
>  > Well ok so let's forget about LDP - cool !
>  >
>  > So IGP sends summary around and that is all what is needed.
>  >
>  > So the question why not propage information that PE went down in
> service
>  > signalling - today mainly BGP.
>
> because BGP signalling is prefix based and as a result slow.
>
>  >
>  >  >   And forget BFD, does not scale with 10k PEs.
>  >
>  > You missed the point. No one is proposing full mesh of BFD sessions
>  > between all PEs. I hope so at least.
>  >
>  > PE is connected to RRs so you need as many BFD sessions as RR to
> PE BGP
>  > sessions.
>
> that can be still too many.
> In addition you may have a hierarchical RR, which would still involve
> BGP signalling.
>
> Once that session is brought down RR has all it needs to
>  > trigger a message (withdraw or implicit withdraw) to remove the
>  > broken service routes in a scalable way.
>
> that is the whole point, you need something that is prefix independent.
>
> thanks,
> Peter
>
>  >
>  > Thx,
>  > R.
>  >
>  > PS. Yes we still need to start support signalling of
> unreachability in
>  > BGP itself when BGP is used for underlay but this is a bit
> different use
>  > case and outside of scope of LSR
>  >
>  >
>  > On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak  
>  > >> wrote:
>  >
>  > Robert,
>  >
>  > On 09/03/2021 11:47, Robert Raszuk wrote:
>  >  >  > You’re trying to fix a problem in the overlay by
> morphing the
>  >  > underlay.  How can that seem like a good idea?
>  >  >
>  >  > I think this really nails this discussion.
>  >  >
>  >  > We have discussed this before and while the concept of
> signalling
>  >  > unreachability does seem useful such signalling should be done
>  > where it
>  >  > belongs.
>  >  >
>  >  > Here clearly we are talking about faster connectivity
> restoration
>  > for
>  >  > overlay services so it naturally belongs in overlay.
>  >  >
>  >  > It could be a bit misleading as this is today underlay which
>  > propagates
>  >  > reachability of PEs and overlay relies on it. And to scale,
>  >  > summarization is used hence in the underlay, failing
> remote PEs
>  > remain
>  >  > reachable. That however in spite of 

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Shraddha Hegde]

Tony,

Thanks for the comments.

Pls see inline for replies...


Juniper Business Use Only

-Original Message-
From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, March 3, 2021 5:30 AM
To: William Britto A J 
Cc: lsr@ietf.org; Rajesh M ; Shraddha Hegde 
; DECRAENE Bruno IMT/OLN 
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[External Email. Be cautious of content]


Hi William,


> 1) I’ll start with the title: there is MUCH more here than bandwidth 
> constraints. Perhaps this should be generalized somehow? Sorry, I don’t have 
> a constructive suggestion.
> [William] Agree. We are introducing few ‘definitions’ for a bandwidth based 
> Flex-Algo, along with couple of link constraints which can be used for any 
> type of flex-algo. Any suggestions are welcome.


In the hopes of inspiring others with better thoughts:

“Flexible Algorithms: Bandwidth Management Part 1”
“Flexible Algorithms: Some Stuff We Forgot”
“Flexible Algorithms: Bandwidth and Delay, Metrics and Constraints”
“Flexible Algorithms: A Few More Bits”

  “Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints”  looks 
like a good title


> 4) Sectiion 2.1: Why are there two octets reserved in this sub-TLV? If you’re 
> hoping for alignment within an IS-IS LSP, you’ve already lost. Nothing in 
> IS-IS is aligned.
> [William] Apologies. This was an error in the figure. Intention was one octet 
> for Reserved/future flags, hence the Length of 5 octets. Will correct this in 
> the next version.


And if you agree with a more general metric, maybe a few of those reserved bits 
could be used as the index for the user defined metric.

 This is a good idea. Its useful to have flexibility in assigning various 
metrics to the link and be able to find flex-algo SPF paths for those metric 
types.
We will update the draft.


> 5) Section 3.1.1: Here you have chosen to refer directly to subTLV 9.  To be 
> consistent with the rest of FlexAlgo, should we use subTLV 9 inside of the 
> Application Specific Link Attribute subTLV.
> [William] Shouldn’t there be only one Max link BW per link applicable for all 
> applications? However, agree that it could still be in a common ASLA. Will 
> add relevant text to clarify this.


That argument might well apply to all of our other link attributes as well.  
Why do we need a separate administrative group for FlexAlgo?  Why do we need a 
separate set of SRLGs?  I have to confess that we have added a bit of 
complexity that I don’t think is very valuable.
 Totally agree with you on this. 

 However, what’s done is done and there’s no point in arguing about it now.  
 Arguing about this during working group adoption of such work didn’t help 
either! 

We should simply strive to be consistent with what’s already in place so that 
we don’t create even MORE complexity.
 Agree.

> 6) Section 3.1.2: I’m unclear on the utility of this. I can understand 
> optimizing for path delay against the path metric. I can even understand 
> putting an upper bound on the total path delay. I don’t understand why a 
> bound on an individual link delay is important.  If my path delay budget is 
> 100ms, then does it matter if it is exceeded in one hop or ten? Could you 
> please provide more motivation here? Also, wouldn’t a FlexAlgo system be 
> advertising the link delay in the Application Specific Link Attributes subTLV?
> [William] This constraint could be useful in a Flex-Algo whose Metric-type is 
> anything but Link-delay. Here, Link-delay doesn’t influence the ‘cost’ of a 
> link in that Flex-Algo, but can be used to prune out certain links with very 
> high delay from that Flex-Algo.


Thank you, that’s helpful motivation.  Please add something like this to the 
draft.
 Sure.

Continuing on from there…

7) Section 4. You’ve hidden a big part of what you want to do down here, 9 
pages into the document.  You’ve got one whole sentence in the introduction to 
motivate it.  It deserves a good bit more.
 ok

8) Section 4.2. You write that an implementation "considers cumulative 
bandwidth of the parallel links while arriving at the metric for the link”. 
This seems a bit vague.  I think you’re trying to say that in interface group 
mode the bandwidth of an adjacency is the sum of the bandwidths of the 
individual links.  Typically today, if we have L3 parallel links they are 
encoded as separate adjacencies, complete with unique interface addresses.  How 
does interface group mode work with that? 
 It continues to work the same way. I mean the topological representation 
does not change. It is going to be represented as multiple parallel 
Adjacencies. How the metric is assigned to these links differs in simple mode 
and interface group mode. In simple mode, single l3 link bandwidth is taken and 
metric is derived by using either of two modes of metric derivation (reference 
bw or staircase bandwidth t

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Shraddha Hegde]

Tony,

> Please note that I'm NOT recommending that we back away. Rather, we should 
> seek to solve the long-standing issue of oscillatory routing.


It's a fair point and I see Robert is also making a comment on Implementation 
report of how the link-delay value is measured and flooded. Seems like either a 
clarification draft on RFC 8570 or an 8570bis would make sense.

RFC 8570 has been around for sometime. I would be interested to hear if there 
are deployments of dynamically measured link-delay.

Rgds
Shraddha



Juniper Business Use Only
From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, March 3, 2021 10:52 PM
To: Peter Psenak 
Cc: Robert Raszuk ; Gyan Mishra ; 
DECRAENE Bruno IMT/OLN ; Shraddha Hegde 
; Rajesh M ; lsr@ietf.org; William 
Britto A J 
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[External Email. Be cautious of content]


Peter,

Link delay was dynamic before this draft.  As William mentioned, TWAMP can 
already be used to provide a dynamic measurement of link delay.  That, coupled 
with the link delay metric already gave us dynamic path computation 
requirements and the possibilities of oscillation and instability. We have 
chosen to charge ahead, without addressing those concerns already.

TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the other 
side this value is calculated based on multiple measurements over period of 
time and an average is used. Also, smart implementations can normalize the 
value so that a small fluctuation of the delay is not causing the traffic to 
shift or cause ECMP loss.

What is important here is that the Min Unidirectional Link Delay is a link 
characteristic, not something that is affected by the amount of traffic on the 
link or subject to queuing delay. Same applies to Maximum link bandwidth.


I do understand that the minimum link delay is not meant to include queuing 
delay. That, however, does NOT make it a constant.

There are several link types in use that exhibit variable delay: satellite 
links (e.g., Starlink), microwave links, and ancient link layers that deliver 
reliability through retransmission.

Any of these (and probably a lot more) can create a noticeable and measurable 
difference in TWAMP. That would be reflected in an FA metric change. If you 
imagine a situation with multiiple parallel paths with nearly identical delays, 
you can easily imagine an oscillatory scenario.  IMHO, this is an outstanding 
concern with FA.

Please note that I'm NOT recommending that we back away. Rather, we should seek 
to solve the long-standing issue of oscillatory routing.

Regards,
Tony

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

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Shraddha Hegde]

Robert,

Pls see inline...



Juniper Business Use Only
From: Robert Raszuk 
Sent: Wednesday, March 3, 2021 6:50 PM
To: Shraddha Hegde 
Cc: Peter Psenak ; Gyan Mishra ; 
Rajesh M ; DECRAENE Bruno IMT/OLN 
; Tony Li ; lsr@ietf.org; William 
Britto A J 
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[External Email. Be cautious of content]

Shraddha,

Yes your proposal defines constrains for FAD. But ny point is that if you are 
defining such constrain called Max Link Delay you better make sure that 
parameter used to measure such Maximum is well generated and flooded.
 The Maximum delay in FAD is compared against min delay advertised 
per link as  in RFC 8570.
   so maximum delay is not required to be generated and 
flooded  for every link.

Otherwise this constrain becomes questionable.

What if implementation will choose to advertise Minimum Link Delay of the 
period of 1 week or have this as constant value configured wheen you test your 
link before deploying it in production ? What if it never will include egress 
queueing delay. How practical will be your constrain in such cases ?
 If statically configured link delay values are used in production, 
the existing exclude link affinity FAD constraints will be good enough to 
achieve any required  topology pruning in the Flex-algo. The "Exclude maximum 
link delay" defined in this document is useful when dynamic link-delay 
measurement is used.

Many thx,
R.






On Wed, Mar 3, 2021 at 2:03 PM Shraddha Hegde 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Robert,

The draft is not trying to define new delay metric.
A new constraint called " Exclude Maximum link delay " is being defined in the 
draft.
This constraint when included in the FAD should be used prune links that have 
RFC 8570 advertised
Unidirectional link delay larger than the value defined in this FAD constraint.
We will post the -01 version when the window opens. We have clearer text and 
also
fixed some confusions in IANA section.

Rgds
Shraddha





Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Wednesday, March 3, 2021 4:12 PM
To: Peter Psenak mailto:ppse...@cisco.com>>
Cc: Tony Li mailto:tony...@tony.li>>; Gyan Mishra 
mailto:hayabusa...@gmail.com>>; DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Rajesh M 
mailto:mraj...@juniper.net>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; William Britto A J 
mailto:40juniper@dmarc.ietf.org>>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[External Email. Be cautious of content]


Sorry but to me the draft is very clear that it does not care about min delay, 
but possible maximum delay of a link  ...

After all for time sensitive applications we do care how long it will take to 
actually traverse a path in practice not what would be the theoretical min 
amount of time needed for this path to be traversed.

And it does define it here as brand new metric.

Just read this paragraph as well as sections 3.1.2 and 
3.2.2.<https://urldefense.com/v3/__http:/3.2.2.__;!!NEt6yMaO-gk!Qi6nctWtUC5MsX--CcSHucSj6ja5VJIBkRYNQtm3EOTpOgWBEzDcIQDmqwM1R9Mc$>:


   Similarly, exclude maximum link delay constraint is also defined in

   this document.  Links may have the link delay measured dynamically

   and advertised in delay metric in IGP.  For usecases that deploy low

   latency flex-algo, may want to exclude links that have delay more

   than a defined threshold.

Thx,

R.

On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
On 03/03/2021 11:27, Robert Raszuk wrote:
>
> I am not sure I follow your logic here ...
>
> If we are already advertising "Min Unidirectional link delay" as
> described in 
> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-13<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-lsr-flex-algo-13__;!!NEt6yMaO-gk!Qi6nctWtUC5MsX--CcSHucSj6ja5VJIBkRYNQtm3EOTpOgWBEzDcIQDmq-eiJLT-$>
>  why
> would we need to define it again here in this draft ?

we are not defining the metric here, we are defining the constraint that
says what is the maximum value of that metric that can be used.

thanks,
Peter
>
> Also does it really make sense to advertise maximum value of
> minimum value ?
>
> Thx,
> R.
>
> On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak 
> mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com<mailto:ppse...@cisco.com>>> wrote:
>
> Robert,
>
> On 03/03/2021 11:10, Robert Raszuk wrote:
>  > Hey Peter,
>  >
>  >  > Authors stated: "Whether egress queueing delay is included
> in the
>  > link
>  >  > delay depends on the measuring mechanism."
>  >
>

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Shraddha Hegde]

Robert,

The draft is not trying to define new delay metric.
A new constraint called " Exclude Maximum link delay " is being defined in the 
draft.
This constraint when included in the FAD should be used prune links that have 
RFC 8570 advertised
Unidirectional link delay larger than the value defined in this FAD constraint.
We will post the -01 version when the window opens. We have clearer text and 
also
fixed some confusions in IANA section.

Rgds
Shraddha





Juniper Business Use Only
From: Robert Raszuk 
Sent: Wednesday, March 3, 2021 4:12 PM
To: Peter Psenak 
Cc: Tony Li ; Gyan Mishra ; DECRAENE 
Bruno IMT/OLN ; Shraddha Hegde 
; Rajesh M ; lsr@ietf.org; William 
Britto A J 
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[External Email. Be cautious of content]


Sorry but to me the draft is very clear that it does not care about min delay, 
but possible maximum delay of a link  ...

After all for time sensitive applications we do care how long it will take to 
actually traverse a path in practice not what would be the theoretical min 
amount of time needed for this path to be traversed.

And it does define it here as brand new metric.

Just read this paragraph as well as sections 3.1.2 and 
3.2.2.<https://urldefense.com/v3/__http:/3.2.2.__;!!NEt6yMaO-gk!Qi6nctWtUC5MsX--CcSHucSj6ja5VJIBkRYNQtm3EOTpOgWBEzDcIQDmqwM1R9Mc$>:


   Similarly, exclude maximum link delay constraint is also defined in

   this document.  Links may have the link delay measured dynamically

   and advertised in delay metric in IGP.  For usecases that deploy low

   latency flex-algo, may want to exclude links that have delay more

   than a defined threshold.

Thx,

R.

On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
On 03/03/2021 11:27, Robert Raszuk wrote:
>
> I am not sure I follow your logic here ...
>
> If we are already advertising "Min Unidirectional link delay" as
> described in 
> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-13<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-lsr-flex-algo-13__;!!NEt6yMaO-gk!Qi6nctWtUC5MsX--CcSHucSj6ja5VJIBkRYNQtm3EOTpOgWBEzDcIQDmq-eiJLT-$>
>  why
> would we need to define it again here in this draft ?

we are not defining the metric here, we are defining the constraint that
says what is the maximum value of that metric that can be used.

thanks,
Peter
>
> Also does it really make sense to advertise maximum value of
> minimum value ?
>
> Thx,
> R.
>
> On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak 
> mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com<mailto:ppse...@cisco.com>>> wrote:
>
> Robert,
>
> On 03/03/2021 11:10, Robert Raszuk wrote:
>  > Hey Peter,
>  >
>  >  > Authors stated: "Whether egress queueing delay is included
> in the
>  > link
>  >  > delay depends on the measuring mechanism."
>  >
>  > I disagree with that statement - the Min Unidirectional Link
> Delay is
>  > the value that does not include the queueing delay - that's
> why it is
>  > called Min.
>  >
>  >
>  >
>  > But draft we are discussing here does not talk about "Min" delay.
>  > Contrary it talks about "Max"
>  >
>  > *Maximum*  Delay sub-TLV
>  >
>  > That is also I asked that very question up front.
>
> I'm afraid you misunderstood it. FA uses "Min Unidirectional Link
> Delay"
> as one of its metrics. The "Maximum Delay sub-TLV"  is used to
> advertise
> the maximum value of the "Min Unidirectional Link Delay" that is
> allowed
> for the particular FA.
>
> The text should be improved in that regard though, it's not obvious,
> but
> I believe that's what it is.
>
> thanks,
> Peter
>
>  >
>  > Thx,
>  > R.
>  >
>  >
>  >
>  >
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-admin-tags-07

[Shraddha Hegde]

WG,

Its useful to have admin tag support for prefixes in OSPF.
I support the WG adoption.

I have below comments on the document.


  1.  I suggest to add subsections in the section 4 protocol operations to 
separately address sender side and receiver side protocol operations
  2.  Sender side need to talk about below cases
 *   Same admin tag should not be encoded multiple times
 *   For each Prefix TLV, only one admin tag sub-TLV should be included

(I don't see the need to support multiple admin tag sub-TLV in same prefix TLV)
 Receiver side

  1.  If same tag appears multiple times in the admin tag sub-TLV , the first 
one MUST be  considered and others ignored
  2.  If there are more than one admin tag sub-TLVs in the ospfv2/ospfv3  
prefix TLV only first one MUST be processed and others ignored
  3.  When both admin tag sub-TLV and existing tag in OSPFv2 and OSPFv3 
AS-External-LSA and NSSA-LSA are received, the route should consider a union of 
all these tags.


  1.  Section 6 IANA

Change to

TBD - 32-bit Administrative Tag sub-TLV

  1.  Need to have some explicit statements on Route calculation.

Change in admin tag sub_TLV should at minimum trigger partial route calculation.



Rgds

Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Jeff Tantsura
Sent: Saturday, January 9, 2021 6:03 AM
To: lsr@ietf.org; Christian Hopps 
Cc: lsr-cha...@ietf.org
Subject: Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-admin-tags-07

[External Email. Be cautious of content]

yes/support

Cheers,
Jeff
On Jan 5, 2021, 1:17 AM -0800, Christian Hopps 
mailto:cho...@chopps.org>>, wrote:
This begins a 2 week WG adoption call for the following draft:

https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-admin-tags/

Please indicate your support or objection by January 19th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris.

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

Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

[Shraddha Hegde]

Hi Les,

Thanks for the review and comments.
Pls see inline for replies.



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Monday, November 30, 2020 11:44 AM
To: Shraddha Hegde ; lsr@ietf.org
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt

[External Email. Be cautious of content]


Draft authors -



I note that as the draft has evolved over the years a number of mechanisms have 
been removed (revised adjacency formation and auto tier detection) and the 
draft now focuses exclusively on flooding optimizations.

The draft now also references the recent work done in 
draft-ietf-lsr-dynamic-flooding.



A couple of things are not clear to me.



1)Is it your intent to use the mechanisms defined in 
draft-ietf-lsr-dynamic-flooding? I am specifically - though not exclusively - 
referring to how flooding adapts to topology changes.

It isn't clear from Section 3 whether you are actually intending to use the 
mechanisms defined in 
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07#section-6.8<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07*section-6.8__;Iw!!NEt6yMaO-gk!VproGis8uUGmcl-cCplFMwuNceAo-3roUZT7ZdTlwvY7nJSszUo9AeWXymgguZIt$>
 or whether you simply want to use the Flooding sub-TLV defined in 
draft-ietf-lsr-dynamic-flooding to (optionally??) advertise your algorithm and 
all other procedures are specific to your algorithm.

 We want to use the " IS-IS Dynamic Flooding Sub-TLV" defined in sec 
5.1.2 of the lsr-dynamic-flooding draft just to flood the information
that nodes support the algorithm specified in draft-white-lsr-distoptflood. I 
agree it's not writen very well. I'll update that section in next version.





2)The text at the end of 
https://tools.ietf.org/html/draft-white-lsr-distoptflood-00#section-2.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-white-lsr-distoptflood-00*section-2.1__;Iw!!NEt6yMaO-gk!VproGis8uUGmcl-cCplFMwuNceAo-3roUZT7ZdTlwvY7nJSszUo9AeWXyucq9YRN$>
 states:



" LSPs transmitted to adjacent

   neighbors on the DNR list, however, MUST be transmitted using a

   circuit scope PDU as described in [RFC7356]."



Although this text is not new to this revision, it raises a number of 
questions/concerns - some of which relate to how this draft fits with 
draft-ietf-lsr-dynamic-flooding.



For "DNR neighbors", although a circuit scoped LSP was received, the actual 
content is a traditional area scoped LSP.

 yes.

This presumably needs to be used internally (e.g., when running the Decision 
Process) in the same way as an area scoped LSP.

 yes.

So there are now two internal databases (traditional area LSPs and Circuit 
Scoped LSPs) which have to be used as if they are a single database?

 Yes that is correct

When a node sends a traditional CSNP does it include the LSPs it received as 
Circuit-Scoped LSPs?

If not, how is resynchronization achieved when necessary?

 yes. CSNPs includes circuit scoped LSPs.

Since you raised this point, I am thinking that we need a protocol extension to 
indicate that "this circuit scoped LSP" should be treated

In this special way.



Given the base work defined in draft-ietf-lsr-dynamic-flooding why is the use 
of Circuit Scoped LSPs required/useful?

 I am not sure which base work you are suggesting to use. Could you 
pls provide details?

The flooding algorithm as written in the draft breaks if circuit scoped 
flooding is not done.

Because, the distributed algorithm does not flood the LSP back in the direction 
from where it was originated.



In general, it would be helpful to more completely define the relationship 
between this draft and draft-ietf-lsr-dynamic-flooding.

 yes. I'll produce next version soon.



Thanx.



   Les





> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Shraddha Hegde

> Sent: Sunday, November 29, 2020 8:36 PM

> To: lsr@ietf.org<mailto:lsr@ietf.org>

> Subject: [Lsr] FW: New Version Notification for draft-white-lsr-distoptflood-

> 00.txt

>

> WG members,

>

>

> We have posted new version of the draft-white-lsr-distoptflood.

> This draft has been around for sometime by name openfabric and

> draft-white-distoptflood. The current revision has the name changed

> to reflect LSR WG.

> This draft describes a flood reduction mechanism in ISIS which is based on

> similar mechanisms implemented in OSPF for mobile-ad-hoc Networks

> ([RFC5449], [RFC5614], and [RFC7182]).

>

> Request working group to review and provide inputs.

>

> Rgds

> Shraddha

>

>

> Juniper Business Use Only

>

> -Original Message-

> From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
> mailto:internet-dra...@ietf.org>>

> Sent: Monday, November 30, 2020 9:59 AM

> To: Shraddha H

Re: [Lsr] IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Shraddha Hegde]

I am not aware of any IPR, other than the one disclosed by Juniper.

Rgds
Shraddha



Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Wednesday, December 2, 2020 2:51 AM
To: draft-bonica-lsr-ip-flexa...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" 
- draft-bonica-lsr-ip-flexalgo-01

[External Email. Be cautious of content]

Authors,

Are you aware of any IPR that applies to draft-bonica-lsr-ip-flexalgo-01?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

[Lsr] FW: New Version Notification for draft-white-lsr-distoptflood-00.txt

[Shraddha Hegde]

WG members,


We have posted new version of the draft-white-lsr-distoptflood.
This draft has been around for sometime by name openfabric and
draft-white-distoptflood. The current revision has the name changed
to reflect LSR WG.
This draft describes a flood reduction mechanism in ISIS which is based on
similar mechanisms implemented in OSPF for mobile-ad-hoc Networks
([RFC5449], [RFC5614], and [RFC7182]).

Request working group to review and provide inputs.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: internet-dra...@ietf.org  
Sent: Monday, November 30, 2020 9:59 AM
To: Shraddha Hegde ; Russ White ; Shawn 
Zandi 
Subject: New Version Notification for draft-white-lsr-distoptflood-00.txt

[External Email. Be cautious of content]


A new version of I-D, draft-white-lsr-distoptflood-00.txt
has been successfully submitted by Shraddha Hegde and posted to the IETF 
repository.

Name:   draft-white-lsr-distoptflood
Revision:   00
Title:  IS-IS Optimal Distributed Flooding for Dense Topologies
Document date:  2020-11-29
Group:  Individual Submission
Pages:  12
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-white-lsr-distoptflood-00.txt__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSEm2FfjO$
Status: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-white-lsr-distoptflood/__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSC0pwavY$
Htmlized:   
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-white-lsr-distoptflood__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSFYebZSl$
Htmlized:   
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-white-lsr-distoptflood-00__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSANTt6Q2$


Abstract:
   In dense topologies, such as data center fabrics based on the Clos
   and butterfly fabric topologies, flooding mechanisms designed for
   sparse topologies, when used in these dense topologies, can
   "overflood," or carry too many copies of topology and reachability to
   fabric devices.  This results in slower convergence times and higher
   resource utilization.  The modifications to the flooding mechanism in
   the Intermediate System to Intermediate System (IS-IS) link state
   protocol described in this document reduce resource utilization to a
   minimum, while increaseing convergence performance in dense
   topologies.

   Note that a Clos fabric is used as the primary example of a desne
   flooding topology throughout this document.  However, the flooding
   optimizations described in this document apply to any dense topology.




Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt

[Shraddha Hegde]

I am not aware of any IPR.



Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Friday, October 2, 2020 1:54 AM
To: draft-ietf-lsr-flex-a...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt

[External Email. Be cautious of content]

Authors,

The following IPR has been disclosed (excerpted from 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo):

Date
ID
Statement
2018-08-08
3248
Cisco's Statement about IPR related to 
draft-ietf-lsr-flex-algo
2019-12-05
3910
Huawei Technologies Co.,Ltd's Statement about IPR related to 
draft-ietf-lsr-flex-algo


Are you aware of any other IPR that applies to draft-ietf-lsr-flex-algo?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Shraddha Hegde]

Peter,


Thanks for the conclusion on adding L-bit clarification in the 
draft-ietf-lsr-flex-algo.

Snip to open comments.

> Note that earlier versions of this document did not mandate use of 
> ASLA TLVs and hence may not inter-operate with early implementations that use 
> legacy advertisements."

>it is not true that "earlier versions of this document" did not 
mandate ASLA.


>https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-
  >gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$ , 
which only supported the >  >include/exclude Admin Groups, clearly stated:

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/

https://mailarchive.ietf.org/arch/browse/lsr/?q=LSR%20Working%20Group%20Adoption%20Poll%20for%20Flex%20Algorithm%20Drafts

The above two drafts were polled for WG adoption. These two drafts did not have 
any reference to te-app draft.

There was no discussion in the WG about ASLA TLV during the adoption call. When 
the WG adopted draft was posted, that merged the ISIS and OSPF drafts and the 
non-backward compatible text mandating ASLA TLV was introduced. The link to 
this draft, you have copied in the mail above.


I think it is fair to warn the operators on the possible inter-op issues this 
could cause.
I would like to see the above sentence added to the draft.


Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Thursday, September 3, 2020 1:25 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]


Hi Shraddha,

On 03/09/2020 05:39, Shraddha Hegde wrote:
> Peter,
>
> In order to make the document clearer on this point, I would like the 
> text below to be added to section 11 to make it explicit that setting the 
> L-bit is valid for flex-algo for ISIS.
>
> =
> Section 11.
>
> “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 
> of [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST 
> use legacy advertisements for that link. Flex algorithm application 
> MUST support sending and receiving link attributes with ASLA TLV having L-bit 
> set.


I can add the above, although, it's clear from the draft-ietf-isis-te-app that 
L-bit with legacy advertisement MAY be used for any app.

>
> Note that earlier versions of this document did not mandate use of 
> ASLA TLVs and hence may not inter-operate with early implementations that use 
> legacy advertisements."

it is not true that "earlier versions of this document" did not mandate ASLA.

https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$
 , which only supported the include/exclude Admin Groups, clearly stated:


9.  Advertisement of Link Attributes for Flex-Algorithm

Various link include or exclude rules can be part of the Flex-
Algorithm definition.  These rules use Admin Groups (AG) as defined
in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
as defined in [RFC7308].

To advertise a link affinity in a form of the AG or EAG that is used
during Flex-Algorithm calculation, an Application Specific Link
Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
of Extended Link TLV as described in
[I-D.ietf-ospf-te-link-attr-reuse] MUST be used.  The advertisement
MUST indicate that it is usable by the Flex-Algorithm application.


thanks,
Peter



> 
>
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Peter Psenak 
> Sent: Wednesday, September 2, 2020 2:43 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; 
> Acee Lindem (acee) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
> [External Email. Be cautious of content]
>
>
> Hi Shraddha,
>
> please see inline:
>
>
> On 02/09/2020 06:45, Shraddha Hegde wrote:
>> Peter,
>>
>> It is worthwhile to note the history of the flex-algo draft and the 
>> te-app draft and how many  backward incompatible changes have been 
>> introduced in the course of the flex-algo draft.
>>
>> The original drafts of flex-algo did not mention the te-a

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Shraddha Hegde]

Peter,

In order to make the document clearer on this point, I would like the text 
below to be added
to section 11 to make it explicit that setting the L-bit is valid for flex-algo 
for ISIS.

=
Section 11.

“The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 of 
[draft-ietf-isis-te-app]. When the L-bit is set, applications MUST use
legacy advertisements for that link. Flex algorithm application MUST support
sending and receiving link attributes with ASLA TLV having L-bit set.

Note that earlier versions of this document did not mandate use of ASLA TLVs
and hence may not inter-operate with early implementations that use legacy 
advertisements."



Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Wednesday, September 2, 2020 2:43 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]


Hi Shraddha,

please see inline:


On 02/09/2020 06:45, Shraddha Hegde wrote:
> Peter,
>
> It is worthwhile to note the history of the flex-algo draft and the 
> te-app draft and how many  backward incompatible changes have been 
> introduced in the course of the flex-algo draft.
>
> The original drafts of flex-algo did not mention the te-app draft and 
> was completely based on legacy advertisements.
> Two years ago, after the working group adopted the original drafts 
> without the ASLA TLV, the text was changed to require the ASLA TLV.

draft-ietf-lsr-flex-algo-00, which was the initial version of the WG document 
already mandated the ASLA usage. I don't believe we have to go back to the 
individual drafts that predated the WG version.

>
>
> ASLA TLV had the L-Bit and it was always valid to advertise link 
> attributes for flex-algo with L-bit set which means the link 
> attributes could still be sent in legacy TLVs.
> In a conversation last year, you had agreed that advertising link 
> attributes with L-bit set is valid for Flex-algo.


what we say in flex-algo draft in section 11 is:

"Link attribute advertisements that are to be used during Flex-
Algorithm calculation MUST use the Application-Specific Link
Attribute (ASLA) advertisements defined in [I-D.ietf-isis-te-app] or
[I-D.ietf-ospf-te-link-attr-reuse]."

ietf-isis-te-app clearly allows the app specific value of the attribute to be 
advertised in legacy TLV and be pointed to by ASLA with L-bit.
This is perfectly valid for Flex-algo with ISIS.

Please note that etf-ospf-te-link-attr-reuse does not have the concept of L-bit.

>
> Towards the end of 2019, draft-ietf-isis-te-app-08 was posted. This 
> version said that only RSVP, SR-TE and LFA can use legacy advertisements.
> This change in a different draft made using flex-algo with legacy 
> advertisements invalid.

no, not really. From the version 00, the WG version of the flex-algo draft 
mandated the usage of ASLA. And from day one of the draft-ietf-isis-te-app 
draft we mandated the usage of the ALSA for new applications, including the 
flex-algo. And usage of ASLA with L-bit together with the legacy advertisement 
of the link attribute is valid for any new application.

>
> So implementations from 2 yrs ago may not inter-operate with the ones 
> implemented a year ago or the ones implemented based on published RFC.

let's be more precise here. The implementation of the pre-WG version may not 
inter-operate with WG version. I don't see a problem there really.

> Implementations from a year ago may not interoperate with published RFC.

no, that is not true.

>
> I don’t agree with this series of backward incompatible changes that 
> have been made in this document.  However, if the working group 
> decides to go ahead and request publication of the current version,  
> which has broken backward compatibility twice with previous versions,

above statement is not correct. The WG document has been consistent in terms of 
ASLA usage from day one.

thanks,
Peter


>   I want the history to be accurately  recorded. This allows network 
> operators to better understand the history and ensure interoperability across 
> vendors before deploying.
>
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Peter Psenak 
> Sent: Thursday, August 27, 2020 3:34 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; 
> Acee Lindem (acee) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-fl