Les,

Thanks for catching that.
Will update.

Rgds
Shraddha


Juniper Business Use Only
-----Original Message-----
From: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Sent: 07 February 2025 12:51
To: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; Shraddha 
Hegde <shraddha=40juniper....@dmarc.ietf.org>; Eric Vyncke (evyncke) 
<evyn...@cisco.com>; The IESG <i...@ietf.org>
Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org; acee.i...@gmail.com
Subject: RE: Éric Vyncke's No Objection on draft-ietf-lsr-flex-algo-bw-con-18: 
(with COMMENT)

[External Email. Be cautious of content]


Small error - should have said "types 0,1,2 are not allowed..." - but you get 
the idea.
Sorry ...

   Les



Juniper Business Use Only
From: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>
Sent: Thursday, February 6, 2025 11:14 PM
To: Shraddha Hegde <shraddha=40juniper....@dmarc.ietf.org>; Eric Vyncke 
(evyncke) <evyn...@cisco.com>; The IESG <i...@ietf.org>
Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org; acee.i...@gmail.com
Subject: [Lsr] Re: Éric Vyncke's No Objection on 
draft-ietf-lsr-flex-algo-bw-con-18: (with COMMENT)

Shraddha -

Section 10.1 modifies the IGP Metric-Type registry - adding a new column to 
indicate whether a given metric type is allowed in the Generic Metric sub-TLV.
This was done because we do not know at this time whether a future metric-type 
will utilize the generic metric sub-TLV or not.
All we know at present is that types 0,1 are NOT allowed and the new 
metric-type this document defines (3) IS allowed.

The most accurate statement for Section 2.1/2.2 would then be:

"The metric type may be any value which is indicated as allowed in the generic 
metric sub-TLV by the IGP Metric-Type Registry."

   Les

From: Shraddha Hegde 
<shraddha=40juniper....@dmarc.ietf.org<mailto:shraddha=40juniper....@dmarc.ietf.org>>
Sent: Thursday, February 6, 2025 10:50 PM
To: Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>>; The 
IESG <i...@ietf.org<mailto:i...@ietf.org>>
Cc: 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-...@ietf.org>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
acee.i...@gmail.com<mailto:acee.i...@gmail.com>
Subject: [Lsr] Re: Éric Vyncke's No Objection on 
draft-ietf-lsr-flex-algo-bw-con-18: (with COMMENT)

Hi Eric,

I added below to sec 2.1/2.2

The value is taken from the "IGP Metric-Type"
      registry maintained by IANA. The metric-type may be
                standard metric-type (3-127) or user-defined (128-255).

Let me know if that works for you.
Ver-21 will reflect the changes.
Rgds
Shraddha



Juniper Business Use Only
From: Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>>
Sent: 06 February 2025 19:39
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; The 
IESG <i...@ietf.org<mailto:i...@ietf.org>>
Cc: 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-...@ietf.org>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
acee.i...@gmail.com<mailto:acee.i...@gmail.com>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-lsr-flex-algo-bw-con-18: 
(with COMMENT)

[External Email. Be cautious of content]

Shraddha

Thank you for your quick reply and the proposed changes and answers.

I still think that the text in section 2.1 and 2.2 could be clearer, but this 
is non-blocking.

Regards

-éric

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Thursday, 6 February 2025 at 14:51
To: Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>>, The 
IESG <i...@ietf.org<mailto:i...@ietf.org>>
Cc: 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-...@ietf.org>
 
<draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-...@ietf.org>>,
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> 
<lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>>, 
lsr@ietf.org<mailto:lsr@ietf.org> <lsr@ietf.org<mailto:lsr@ietf.org>>, 
acee.i...@gmail.com<mailto:acee.i...@gmail.com> 
<acee.i...@gmail.com<mailto:acee.i...@gmail.com>>, 
a...@cisco.com<mailto:a...@cisco.com> <a...@cisco.com<mailto:a...@cisco.com>>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-lsr-flex-algo-bw-con-18: 
(with COMMENT) Hi Eric,

Thanks for the reply.
Pls see inline for replies <SH>..

Ver-19 will address your comments


Rgds
Shraddha


Juniper Business Use Only
-----Original Message-----
From: Éric Vyncke via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>>
Sent: 03 February 2025 16:29
To: The IESG <i...@ietf.org<mailto:i...@ietf.org>>
Cc: 
draft-ietf-lsr-flex-algo-bw-...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-...@ietf.org>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
acee.i...@gmail.com<mailto:acee.i...@gmail.com>; 
a...@cisco.com<mailto:a...@cisco.com>
Subject: Éric Vyncke's No Objection on draft-ietf-lsr-flex-algo-bw-con-18: 
(with COMMENT)

[External Email. Be cautious of content]


Éric Vyncke has entered the following ballot position for
draft-ietf-lsr-flex-algo-bw-con-18: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!C91vbUitzDkF8V1c0kH31BLKVBdwYOTMEXaU1XYgFXBCxXmBC4Eq_XizG2w2n0GSs9uICRCd_j_zePSW$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!C91vbUitzDkF8V1c0kH31BLKVBdwYOTMEXaU1XYgFXBCxXmBC4Eq_XizG2w2n0GSs9uICRCd_j_zePSW$>
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!C91vbUitzDkF8V1c0kH31BLKVBdwYOTMEXaU1XYgFXBCxXmBC4Eq_XizG2w2n0GSs9uICRCd_qwSyEVm$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!C91vbUitzDkF8V1c0kH31BLKVBdwYOTMEXaU1XYgFXBCxXmBC4Eq_XizG2w2n0GSs9uICRCd_qwSyEVm$>



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-lsr-flex-algo-bw-con-18
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some 
non-blocking COMMENT points (but replies would be appreciated even if only for 
my own education), and some nits.

Special thanks to Acee Lindem for the shepherd's detailed write-up including 
the WG consensus *and* the justification of the intended status, there is no 
justification for six authors though.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Support of metrics by IGP routers

It is perhaps specified in other RFCs, but I failed to see the specification of 
what to do when a router receives a metric that it does not support.
<SH> All the new metrics are used by Flex-algo. If a flex-algo definition 
(FAD)includes a metric-type that is not supported/understood by a router, it 
stops participating in that flex-algo. This behavior is specified in RFC 9350 
And this document need not repeat this statement IMO . The router would simply 
flood the LSPs/LSAs Even if it did not understand the metric. This behaviour is 
defined in base OSPF/ISIS standards

### Section 1

Should the terms throughput be used in addition to bandwidth ? E.g., s/High 
bandwidth traffic/High throughput traffic/ ?
<SH>I searched the RFCs a bit and couldn't find other RFCs using the term high 
bandwidth traffic, I also couldn't find the term high throughput traffic . But 
for now I am changing it to "high throughput traffic".

s/This document proposes /This document specifies / (or "defines"), after all 
it will be published as a PS RFC ;-) <SH> ok

Else, this section is super well written and easy to read.

Suggest adding a reference to "PCE".
<SH>OK

### Section 2

Suggest adding references to IS-IS and OSPF.
<SH>ok

Please expand "ASLA".
<SH> ok

### Section 2.1

It took me a while to understand that figure 1 is not part of bullet item g

_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

Reply via email to