Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Tony Li]

Hi Peng Shaofu,


> On May 19, 2021, at 6:55 PM, peng.sha...@zte.com.cn wrote:
> 
> 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, 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 ?


The whole point of the bandwidth metric (and indeed, of all of FlexAlgo) is to 
get a different path computation result than what we might get with the 
standard IGP metric. What it will do in any given topology is highly dependent 
on the topology, as you’ve seen.  It may or may not ‘work’ by whatever 
definition you have in mind. However, what matters is what the network operator 
is trying to achieve. It doesn’t have to work for every topology or every 
purpose.

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]

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;
日 期 ：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>>
Sent: Monday, May 17, 2021 12:49 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
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;
日 期 ：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>>
Sent: Monday, May 17, 2021 7:40 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
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 seem

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[peng.shaofu]

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, 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 ?






Regards,


PSF











原始邮件



发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：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  
 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;



日 期 ：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  
 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;



日 期 ：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

Re: [Lsr] opsawg-l3sm-l3nm

[Acee Lindem (acee)]

Hi Tom, 
I would agree with your assessment. However, I'd also put this draft in the 
"wisdom to know the difference" category. I won't speak for the rest of the WG 
but fixing it isn't a priority for me. 
Thanks,
Acee 

On 5/18/21, 5:46 AM, "Lsr on behalf of tom petch"  wrote:

Looking at this I-D, from OPSAWG, I get somewhat concerned and wonder what 
those with more knowledge of the LSR protocols than I would think.   

It caters for routing between PE and CE, RIP, VRRP, BGP, PIM, MLD, IGMP, 
BFD not to mention the two LSR protocols and so contains the YANG to configure 
those protocols but in a way that is different to the YANG models for those 
protocols.  Thus it uses address family to mean IPv4 or IPV6 (not the BGP 
meaning) and often splits the protocol on that basis, not e.g. as OSPFv2 or 
OSPFv3.  There is but a single OSPF identity, imported from a common module 
which only ever mentions OSPFv2, which means there is no way of specifying in 
YANG what is part of OSPFv2, what is OSPFv3, only what is OSPF for IPv4 or what 
is OSPF for IPv6.

Other terminology is different.  Thus for BGP, symptomatic if not a concern 
here, it specifies hold-time and keep-alive, where BGP omits the hyphen, and it 
does not mention BGP Identifier which I would see as the starting point for 
BGP.  Of more interest here, it uses level1, level2 and level1-2 where every 
other document I know uses level-1 etc including the hyphen.  OSPF 
authentication is rather different to that of ospf-yang with IPsec,  key-chain 
and key-explicit.

I would sum up the I-D as 'routing for everyone but different' and wonder 
what others might think.

Tom Petch


___
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] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Christian Hopps]

My final input would be that it is important to maintain the linkages. So if an 
RFC creates a registry and then that registry's name is changed by another RFC 
then, unfortunately, I think that the second RFC updates the first.

Otherwise I agree with Les.

How about we pick names that don't need updating in the future?

Thanks,
Chris.


"Les Ginsberg (ginsberg)"  writes:


Alvaro -

I don’t find the referenced draft relevant to this case.

Our difference of opinion has to do with the function of a codepoint registry.
Registries are created as a place to both document existing codepoints and to 
be updated when the need for additional codepoints arises.
There is no benefit or need (IMO of course) for an RFC which initially created the 
registry to be marked as "updated" when new codepoints are added to the 
registry - which is really all that is happening here.

Is there anything in RFC 7370 that states or implies that the name of the 
registry is not subject to change?
Is there anything in RFC 7370 that states or implies that the set of TLVs under 
the purview of the registry is not subject to change?
Why are either of these cases functionally any different from adding a new 
sub-TLV codepoint to the registry?

I do agree that this is not worth the time being spent on it. So, you have my 
input. I leave it to the ADs/WG chairs/IESG review to close this issue.
Thanx for listening.

   Les



-Original Message-
From: Alvaro Retana 
Sent: Wednesday, May 19, 2021 6:55 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee)
; Peter Psenak (ppsenak) ; John
Scudder 
Cc: John Scudder via Datatracker ; draft-ietf-lsr-isis-srv6-
extensi...@ietf.org; Christian Hopps ; lsr-
cha...@ietf.org; lsr@ietf.org; The IESG 
Subject: RE: John Scudder's No Objection on draft-ietf-lsr-isis-srv6-
extensions-14: (with COMMENT)

Les:

Hi!

In this case the name is being changed, a new column is added, and all
the existing code points are updated in light of the new column.

I realize this may not be enough for you.  Instead of all of us
discussing this specific case, we should focus our energy on clearly
defining what “Updates” means — there’s a proposal that could be a
starting point [1].

Thanks!

Alvaro.

[1] https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag



On May 19, 2021 at 12:33:27 AM, Les Ginsberg wrote:

> The only legitimate reason to update an older
> document would be if we are actually changing
> in some way one or more of the existing codepoints
> already defined in the registry. That is not
> happening here.


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

Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Les Ginsberg (ginsberg)]

Alvaro -

I don’t find the referenced draft relevant to this case.

Our difference of opinion has to do with the function of a codepoint registry.
Registries are created as a place to both document existing codepoints and to 
be updated when the need for additional codepoints arises.
There is no benefit or need (IMO of course) for an RFC which initially created 
the registry to be marked as "updated" when new codepoints are added to the 
registry - which is really all that is happening here.

Is there anything in RFC 7370 that states or implies that the name of the 
registry is not subject to change?
Is there anything in RFC 7370 that states or implies that the set of TLVs under 
the purview of the registry is not subject to change?
Why are either of these cases functionally any different from adding a new 
sub-TLV codepoint to the registry?

I do agree that this is not worth the time being spent on it. So, you have my 
input. I leave it to the ADs/WG chairs/IESG review to close this issue.
Thanx for listening.

   Les


> -Original Message-
> From: Alvaro Retana 
> Sent: Wednesday, May 19, 2021 6:55 AM
> To: Les Ginsberg (ginsberg) ; Acee Lindem (acee)
> ; Peter Psenak (ppsenak) ; John
> Scudder 
> Cc: John Scudder via Datatracker ; draft-ietf-lsr-isis-srv6-
> extensi...@ietf.org; Christian Hopps ; lsr-
> cha...@ietf.org; lsr@ietf.org; The IESG 
> Subject: RE: John Scudder's No Objection on draft-ietf-lsr-isis-srv6-
> extensions-14: (with COMMENT)
> 
> Les:
> 
> Hi!
> 
> In this case the name is being changed, a new column is added, and all
> the existing code points are updated in light of the new column.
> 
> I realize this may not be enough for you.  Instead of all of us
> discussing this specific case, we should focus our energy on clearly
> defining what “Updates” means — there’s a proposal that could be a
> starting point [1].
> 
> Thanks!
> 
> Alvaro.
> 
> [1] https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag
> 
> 
> 
> On May 19, 2021 at 12:33:27 AM, Les Ginsberg wrote:
> 
> > The only legitimate reason to update an older
> > document would be if we are actually changing
> > in some way one or more of the existing codepoints
> > already defined in the registry. That is not
> > happening here.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Alvaro Retana]

Les:

Hi!

In this case the name is being changed, a new column is added, and all
the existing code points are updated in light of the new column.

I realize this may not be enough for you.  Instead of all of us
discussing this specific case, we should focus our energy on clearly
defining what “Updates” means — there’s a proposal that could be a
starting point [1].

Thanks!

Alvaro.

[1] https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag



On May 19, 2021 at 12:33:27 AM, Les Ginsberg wrote:

> The only legitimate reason to update an older
> document would be if we are actually changing
> in some way one or more of the existing codepoints
> already defined in the registry. That is not
> happening here.

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

Re: [Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Peter,

Thank you for your quick reply and addressing my non-blocking COMMENTs.

You may want to have a look at EV> below (again non blocking)

Regards

-éric


-Original Message-
From: Peter Psenak 
Date: Wednesday, 19 May 2021 at 13:39
To: Eric Vyncke , The IESG 
Cc: "lsr-cha...@ietf.org" , "aretana.i...@gmail.com" 
, "cho...@chopps.org" , 
"draft-ietf-lsr-isis-srv6-extensi...@ietf.org" 
, "lsr@ietf.org" 
Subject: Re: [Lsr] Éric Vyncke's No Objection on 
draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

Hi Eric,

thanks for comments, please see inline (##PP):

On 18/05/2021 18:05, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-lsr-isis-srv6-extensions-14: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated), and some nits.
> 
> Thank you to Christian Hopps for his shepherd's write-up (including the WG
> consensus).
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 2 --
> Any reason why the bits of the 'Flags' field are not reserved (except for 
the
> O-bit) ?  

##PP
sure, marked them as Reserved

> or be in a to-be-created IANA registry? 

##PP
there is a registry defined for these bits in section 11.7

EV> may I suggest to add a reference to the IANA registry already in this 
section ?

> I would expect the default
> value for sending them (usually 0) and what to do on the receiving 
side(s) when
> the value is not 0 (usually ignore them). E.g., see the section 7.1

##PP
yes, this has been commented by others and I have added the statement 
similar to 7.1 already.


> 
> -- Section 3 --
> Isn't it obvious that the "Segment Routing Algorithm" is also supported 
by SRv6
> routers ? Consider removing this section ? If you prefer to keep it, then
> please use the wording "Segment Routing Algorithm" exactly as in the IANA
> registry.

##PP
I prefer to keep it to make it clear that the SRv6 algo participation is 
using the same signaling as SR MPLS. That may not be that obvious as it 
may look like.

EV> you may want to state that SRv6 uses the same signaling as SR MPLS (even by 
one more sentence)

Corrected the sub-TLV name to match IANA.

> 
> -- Section 7.1 (also 7.2 and possibly others) --
> The header 'Length' should not be defined as 'variable' as it is probably 
a
> fixed length of 1 octet. Specifying how it is measured and in which units
> (octets, 32-bit word, ...) is probably welcome.

##PP
with "variable" we refer to the value of the Length's field, not it's 
length. We use this in many ISIS RFCs (e.g. RFC8667, section 2.2.2.)

EV> Honestly, history mistakes do not need to be repeated ;-)

> 
> -- Section 7.2 --
> What is the default value of the "Flags" field?

##PP

I added:

"All bits are reserved for future use. They MUST be  set to zero on 
transmission and MUST be ignored on receipt."

> 
> == NITS ==
> 
> -- title-
> Should the plural form be used for 'extension' ?

##PP
sure, changed to plural.


> 
> -- Section 1 --
> s\topology/algorithm specific\topology/algorithm-specific\ ?

##PP
done

> 
> -- Section 13 --
> While there is a rather long contributors list, there is no 
acknowledgement
> section. The latter is of course optional but usual. Should the doc   
 or
> last call reviewers be acknowledged ?

##PP
sure, added it.

thanks,
Peter


> 
> 
> 
> ___
> 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] Éric Vyncke's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Peter Psenak]

Hi Eric,

thanks for comments, please see inline (##PP):

On 18/05/2021 18:05, Éric Vyncke via Datatracker wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

Thank you to Christian Hopps for his shepherd's write-up (including the WG
consensus).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2 --
Any reason why the bits of the 'Flags' field are not reserved (except for the
O-bit) ?  


##PP
sure, marked them as Reserved

or be in a to-be-created IANA registry? 


##PP
there is a registry defined for these bits in section 11.7



I would expect the default
value for sending them (usually 0) and what to do on the receiving side(s) when
the value is not 0 (usually ignore them). E.g., see the section 7.1


##PP
yes, this has been commented by others and I have added the statement 
similar to 7.1 already.





-- Section 3 --
Isn't it obvious that the "Segment Routing Algorithm" is also supported by SRv6
routers ? Consider removing this section ? If you prefer to keep it, then
please use the wording "Segment Routing Algorithm" exactly as in the IANA
registry.


##PP
I prefer to keep it to make it clear that the SRv6 algo participation is 
using the same signaling as SR MPLS. That may not be that obvious as it 
may look like.


Corrected the sub-TLV name to match IANA.



-- Section 7.1 (also 7.2 and possibly others) --
The header 'Length' should not be defined as 'variable' as it is probably a
fixed length of 1 octet. Specifying how it is measured and in which units
(octets, 32-bit word, ...) is probably welcome.


##PP
with "variable" we refer to the value of the Length's field, not it's 
length. We use this in many ISIS RFCs (e.g. RFC8667, section 2.2.2.)




-- Section 7.2 --
What is the default value of the "Flags" field?


##PP

I added:

"All bits are reserved for future use. They MUST be  set to zero on 
transmission and MUST be ignored on receipt."




== NITS ==

-- title-
Should the plural form be used for 'extension' ?


##PP
sure, changed to plural.




-- Section 1 --
s\topology/algorithm specific\topology/algorithm-specific\ ?


##PP
done



-- Section 13 --
While there is a rather long contributors list, there is no acknowledgement
section. The latter is of course optional but usual. Should the doc  or
last call reviewers be acknowledged ?


##PP
sure, added it.

thanks,
Peter






___
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] 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
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 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
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.

[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 an existing practice. The draft is defining new attributes 
and constraints in order to simplify and automate this process.

It does not propose any

Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Christian Hopps]

"Les Ginsberg (ginsberg)"  writes:


Perhaps the somewhat unfortunate choice of the name of the registry - which 
inserts the codepoint for all the TLVs supported by the registry into the 
registry name - feeds into this confusion.
If so, I would suggest renaming the registry to:  "Sub-TLVs for TLVs advertising 
NLRI".
The registry name would then never have to be changed and we could more easily avoid 
being drawn into an inappropriate use of "update".


The existing names are mouthful that's for sure. I think updating the name 
might make sense.

Thanks,
Chris.



   Les




-Original Message-
From: Acee Lindem (acee) 
Sent: Monday, May 17, 2021 7:03 AM
To: Peter Psenak (ppsenak) ; John Scudder

Cc: Alvaro Retana ; Les Ginsberg (ginsberg)
; John Scudder via Datatracker ;
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; lsr-cha...@ietf.org;
The IESG ; Christian Hopps 
Subject: Re: John Scudder's No Objection on draft-ietf-lsr-isis-srv6-
extensions-14: (with COMMENT)

Hi Peter,

On 5/17/21, 9:07 AM, "Peter Psenak"  wrote:

Hi Acee,

On 17/05/2021 14:56, Acee Lindem (acee) wrote:
> Hi John,
>
> Yes – I think “updates” should be removed. Registries are created
> explicitly for the purpose of tracking extensions and every document
> that adds to a registry should not update the document creating that
> registry. Now if the definition or application of the registry were
> changed, which I don’t believe is the case here, then we could consider
> “updates”.

RFC 7370 created the registry by merging multiple existing registries.
It did not really defined any new functionality.

We are changing the name of that merged registry. Given that RFC 7370
did not define anything new, just defined the merged registry, one can
consider the name change as an update to RFC 7370.

Ok - I missed that. I agree with that it updates RFC 7370 since the registry
name changed as opposed to simply adding code points.

Thanks,
Acee

thanks,
Peter
>
> Thanks,
>
> Acee
>
> *From: *John Scudder 
> *Date: *Monday, May 17, 2021 at 8:48 AM
> *To: *Acee Lindem 
> *Cc: *Alvaro Retana , "Les Ginsberg
(ginsberg)"
> , "Peter Psenak (ppsenak)"
, John
> Scudder via Datatracker ,
> "draft-ietf-lsr-isis-srv6-extensi...@ietf.org"
> , "lsr@ietf.org"
> , "lsr-cha...@ietf.org" , The IESG
> , Christian Hopps 
> *Subject: *Re: John Scudder's No Objection on
> draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
>
> Acee,
>
> I think you are saying you prefer to remove the “updates”. Is that
> right? It was a little confusing given the reply chain.
>
> (I’ve already given my opinion but said I’m not going to go to the mat
> over it.)
>
> —John
>
>
>
> On May 17, 2021, at 8:21 AM, Acee Lindem (acee)
>  wrote:
>
> That we be my preference as well. We’ve had several discussions on
> what constitutes “update” and I believe that the consensus was that
> a document isn’t “updated” unless the current behavior is changed.
> If we’ve done our jobs, protocols are designed to be extended and
> these extensions shouldn’t constitute updates.
>
> Thanks,
>
> Acee
>
> *From: *Alvaro Retana 
> *Date: *Monday, May 17, 2021 at 6:55 AM
> *To: *"Les Ginsberg (ginsberg)" , "Peter Psenak
> (ppsenak)" , John Scudder
> 
> *Cc: *John Scudder via Datatracker ,
> "draft-ietf-lsr-isis-srv6-extensi...@ietf.org"
> , "lsr@ietf.org"
> , "lsr-cha...@ietf.org" , The
> IESG , Christian Hopps 
> *Subject: *Re: John Scudder's No Objection on
> draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
> *Resent-From: *
> *Resent-To: *Yingzhen Qu , Christian
Hopps
> , Acee Lindem 
> *Resent-Date: *Monday, May 17, 2021 at 6:54 AM
>
> Peter:
>
> Hi!
>
> As John mentioned, "Since for better or worse we don’t have a firm
> definition of when we do, and don’t, use “updates”, it comes down to
> a matter of personal taste in the end.”
>
> I rather you leave it in.
>
> Thanks!
>
> Alvaro.
>
> On May 17, 2021 at 6:42:48 AM, Peter Psenak (ppse...@cisco.com
> ) wrote:
>
> John, Alvaro,
>
> do we have a consensus whether we need the update to RFC 7370 or
> not?
>
>
> thanks,
> Peter
>
>
>
> On 13/05/2021 21:12, Les Ginsberg (ginsberg) wrote:
>  > Alvaro –
>  >
>  > FWIW, I agree w John here.
>  >
>  > There are many examples – to cite a few:
>  >
>  > Sub-TLVs for TLVs 22, 23, 2

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Dongjie (Jimmy)]

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

[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 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.



[Jie] OK it is clear that this mechanism will not replace the centralized 
bandwidth computation or distributed bandwidth reservation solutions.  While if 
the purpose is just to simplify and automate the metric configuration process, 
, it seems the gain is relatively limited?





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