[Lsr] Re: Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-isis-fast-flooding-10: (with COMMENT)

[John Scudder]

Thanks for the ping, Acee.

Looking at the latest version I have one question. The revised Section 6.2.2 
says,


Whereas flow control prevents the sender from overwhelming the
receiver, congestion control prevents senders from overwhelming the
network.  For an IS-IS adjacency, the network between two IS-IS
neighbors is relatively limited in scope and includes a single link
which is typically over-sized compared to the capability of the IS-IS
speakers.  Only implementing flow control Section 6.2.1 is expected
to give good results and be enough if the internals or the receiver
is not significantly dropping LSP.  Otherwise, adding congestion
control will help handling congestion of LSPs in the receiver.

I don’t understand what the new “only implementing flow control” sentence 
means. Maybe it means something like, “In situations where the probability of 
LSP drop is low, flow control [Section 6.2.1] is expected to give good results, 
without the need to implement congestion control”. But maybe it doesn’t mean 
that, I can’t tell for sure.

I’d appreciate a clarification from the authors (or someone else who knows!) 
and probably one more revision to make the sentence more understandable. After 
that, let’s ship it.

Thanks,

—John

On May 9, 2024, at 12:27 PM, Acee Lindem  wrote:

Hey John,

Is there anything more that needs to be done by the authors?

Thanks,
Acee

On May 2, 2024, at 9:05 AM, Zaheduzzaman Sarker via Datatracker 
 wrote:

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-lsr-isis-fast-flooding-10: 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!FeiWW24FwHcnwOkXm0kSg8nkuiR_EXpMYeXN5C4TXj_zmXX_sX6BykCYqyqe2WgI8bRUzsJGsOcpqsM$
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-isis-fast-flooding/__;!!NEt6yMaO-gk!FeiWW24FwHcnwOkXm0kSg8nkuiR_EXpMYeXN5C4TXj_zmXX_sX6BykCYqyqe2WgI8bRUzsJGEt32q7I$



--
COMMENT:
--

Thanks for addressing my discuss points and comments. It was great to work with
you all. I think the current version of this document is better, hence, cleared
my discuss.





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

Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[John Scudder]

I’m with Les on this one — "we should not conflate this document by discussing 
such issues.”

We often have this tension at this stage of reviewing a draft that’s almost 
ready for publication. It’s being cross-reviewed by specialists in other areas, 
and so it’s helpful for the document to provide enough background to satisfy 
them. Sometimes this works, sometimes not, as seems to have been the case this 
time, and then as Bruno says, "I have large freedom to express myself in an 
email” to try to fill in the blanks. The question at hand is whether after 
publication, those blanks have to be filled in for future readers, or if we are 
in a special case situation right now.

My take is that once the document is published, its primary and most important 
audience will be people who are already experts in IS-IS, either as 
implementors or operators (or both!), and those people won’t find a discussion 
of IS-IS over a standard L4 to be illuminating, but confusing… even if the 
discussion ends up saying “here’s why we didn’t do it over a standard L4”. It’s 
vaguely analogous to asking a QUIC document to provide a rationale for why it’s 
specified over IP and not over CLNS… sure, you could provide that rationale, 
but everyone reading it would end up wondering why you spent your time and 
theirs on it.

So while the NEW text Bruno suggested is correct of course, I wouldn’t 
encourage adding it to the document, because I think it doesn’t serve the needs 
of future readers, it just creates clutter.

$0.02,

—John

On Apr 12, 2024, at 1:03 PM, Les Ginsberg (ginsberg)  wrote:


Top posting one comment.

Regarding


[Bruno2] Well, I have large freedom to express myself in an email. Writing a 
summary of WG history in an RFC is a little bit more engaging... Also, although 
the perspective may be of interest, it’s less likely of little interest to an 
IS-IS implementor.
I would propose the below addition in §6.1 “overview”  but I’d very much 
welcome the opinion of chairs and responsible AD on this text. (both added in 
destination of this email)

OLD:
Ensuring the goodput between two entities is a layer-4 responsibility as per 
the OSI model. A typical example is the TCP protocol defined in [RFC9293] that 
provides flow control, congestion control, and reliability.

NEW:
Ensuring the goodput between two entities is a layer-4 responsibility as per 
the OSI model. A typical example is the TCP protocol defined in [RFC9293] that 
provides flow control, congestion control, and reliability.
In order to improve the IS-IS goodput an option would be to carry IS-IS in a 
layer-4 protocol. However this creates challenges as IS-IS does not use IP so 
existing layer-4 stacks using IP are not readily available. Also IS-IS already 
have reliability mechanisms which would create duplication and possibly 
interference. Finally, many layer-4 providing flow control also provides 
ordered delivery which is not required for IS-IS and even harmful.


IS-IS runs directly over Layer 2.
The solutions proposed in this document are for IS-IS as it is currently 
defined.

The question of whether to run IS-IS over Layer 3 and if so how to do it are 
not in scope for this document.
If a definition of running Is-IS over Layer 3 ever becomes standardized, how 
that may impact fast-flooding is just one of many aspects which will need to be 
addressed.

I feel very strongly that we should not conflate this document by discussing 
such issues.

   Les


From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
mailto:bruno.decra...@orange.com>>
Sent: Thursday, April 11, 2024 11:53 AM
To: Zaheduzzaman Sarker 
mailto:zahed.sarker.i...@gmail.com>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; John Scudder - Juniper 
(j...@juniper.net<mailto:j...@juniper.net>) 
mailto:j...@juniper.net>>
Cc: Zaheduzzaman Sarker 
mailto:zaheduzzaman.sar...@ericsson.com>>; 
draft-ietf-lsr-isis-fast-flood...@ietf.org<mailto:draft-ietf-lsr-isis-fast-flood...@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>; The IESG 
mailto:i...@ietf.org>>
Subject: RE: Zaheduzzaman Sarker's Discuss on 
draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

Hi Zahed,

Please see inline [Bruno2]

From: Zaheduzzaman Sarker 
mailto:zahed.sarker.i...@gmail.com>>
Sent: Thursday, April 11, 2024 11:33 AM
Hi Bruno,

My apologies too :-) , I was on PTO

[Bruno2] No problem. I was also partly on PTO and I would also hope to be next 
week.

My responses inline below.

//Zahed

On Tue, Apr 9, 2024 at 5:13 PM 
mailto:bruno.decra...@orange.com>> wrote:
Zahed,

Thank you for your review and comments.
Sorry for my delayed response.

Les has already commented on the algo 2 section.

Please see inline for other points [Bruno]

>
> -Original Message-
> From: Zaheduzzaman Sark

Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[John Scudder]

Hi Les,

Thanks. AFAICT the only remaining point in question is whether Zahed insists on 
the s/SHOULD/should/g change. Can you and your coauthors prepare a complete 
version 09, including the necessary small edits to sections other than 6.3.2? 
As far as I'm concerned you can post it, which makes it easy for everyone 
involved to review, and then if there are any residual changes wanted we can 
always do a version 10. But it’s fine to circulate it some other way if you 
want a fully-agreed 09, the main point is that it will be easier to close this 
conversation out once the complete proposed text is available.

Thanks!

—John

> On Apr 9, 2024, at 12:05 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> Zahed -
> 
> First, thanx to John - his replies are on point and I agree with all of them.
> 
> As I mentioned in a previous reply to John, my post was simply to get your 
> agreement on the revised text for that section - it was not intended to 
> address other editorial issues (such as revising related section names) - 
> which we will certainly do when generating an updated version.
> A few more comments inline.
> 
>> -----Original Message-
>> From: John Scudder 
>> Sent: Tuesday, April 9, 2024 8:28 AM
>> To: Zaheduzzaman Sarker 
>> Cc: Les Ginsberg (ginsberg) ; The IESG ;
>> draft-ietf-lsr-isis-fast-flood...@ietf.org; lsr-cha...@ietf.org; 
>> lsr@ietf.org;
>> acee.i...@gmail.com
>> Subject: Re: Zaheduzzaman Sarker's Discuss on 
>> draft-ietf-lsr-isis-fast-flooding-
>> 08: (with DISCUSS and COMMENT)
>> 
>> Hi Zahed,
>> 
>> I’m sure Les will reply as soon as his TZ allows him adequate caffeination 
>> :-). To
>> jump-start things, though, a couple questions/comments below.
>> 
>>> On Apr 9, 2024, at 5:49 AM, Zaheduzzaman Sarker
>>  wrote:
>>> 
>>> Thanks for taking the stab, it is a good start but no quite there yet.
>>> 
>>> - Now 6.3 and 6.3.2 has the same section title. I would rename section 6.3
>> to "Transmitter side congestion control considerations" and 6.3.2 to
>> "Guidelines for transmitter side congestion controls". Note that here
>> "transmitter side" congestion control would particularly mean that the
>> transmitter is in sole change of doing congestion congestion control based on
>> say - performance measurements of any sort.
>>> - Rest of changes looks good to me, however, I am not sure we should use
>> normative text to describe guidelines, unless we say those are requirements
>> and then perhaps also describe how one should fulfill those requirements. My
>> understanding is we don't want that sort of details here. I would recommend
>> to remove all the normative SHOULD and relay on implementer doing the right
>> thing. We are anyway not doing standard algorithm (s) and accepting
>> implementation details would vary.
>> 
>> To be clear, your suggestion is s/SHOULD/should/ throughout the text Les
>> sent? IMO that would be fine, and would not make the document any less fit
>> for purpose. Once we have accepted that these are guidelines and not a
>> statement of an algorithm, it’s very difficult to insist that RFC 2119 
>> keywords
>> have much power, doubly so when all of them are SHOULD and not MUST.
>> 
>> One possible counterargument is that SHOULD makes the document more
>> useful to the future implementor than “should”. I would (and did!) also 
>> accept
>> that position.
>> 
>> In short, I don’t much care if the SHOULD is changed, or kept, and I hope the
>> parties to this discussion don’t either.
>> 
> [LES:] I also am not heavily invested in SHOULD vs should - but as the 
> section is advisory (which is why I changed MUST to SHOULD) it seemed like 
> SHOULD was still appropriate.
> However, if you feel this distinction is important, we can certainly use 
> lowercase.
> Please let us know.
> 
>>> - I am expecting this document to call out the algorithm 1 as the only one 
>>> it is
>> defining/describing and 6.3.2 are guidelines for other approaches when
>> Algorithm 1 is not feasible. This should be reflected in the document.
>> 
>> I didn’t think "when Algorithm 1 is not feasible” was implicit in the 
>> document,
>> it was just “here are two approaches” with no editorializing about a 
>> preference
>> between the two. (I haven’t read it recently so I *could* be wrong, but 
>> that’s
>> how I recall it.)
>> 
>> Assuming my recollection is right, I think it would be unwise to change the
>> document to state a preference.
>> 
> [LES:] John is completely correct.

Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[John Scudder]

Hi Zahed,

I’m sure Les will reply as soon as his TZ allows him adequate caffeination :-). 
To jump-start things, though, a couple questions/comments below.

> On Apr 9, 2024, at 5:49 AM, Zaheduzzaman Sarker  
> wrote:
> 
> Thanks for taking the stab, it is a good start but no quite there yet.
> 
> - Now 6.3 and 6.3.2 has the same section title. I would rename section 6.3 to 
> "Transmitter side congestion control considerations" and 6.3.2 to "Guidelines 
> for transmitter side congestion controls". Note that here "transmitter side" 
> congestion control would particularly mean that the transmitter is in sole 
> change of doing congestion congestion control based on say - performance 
> measurements of any sort.  
> - Rest of changes looks good to me, however, I am not sure we should use 
> normative text to describe guidelines, unless we say those are requirements 
> and then perhaps also describe how one should fulfill those requirements. My 
> understanding is we don't want that sort of details here. I would recommend 
> to remove all the normative SHOULD and relay on implementer doing the right 
> thing. We are anyway not doing standard algorithm (s) and accepting 
> implementation details would vary.

To be clear, your suggestion is s/SHOULD/should/ throughout the text Les sent? 
IMO that would be fine, and would not make the document any less fit for 
purpose. Once we have accepted that these are guidelines and not a statement of 
an algorithm, it’s very difficult to insist that RFC 2119 keywords have much 
power, doubly so when all of them are SHOULD and not MUST. 

One possible counterargument is that SHOULD makes the document more useful to 
the future implementor than “should”. I would (and did!) also accept that 
position. 

In short, I don’t much care if the SHOULD is changed, or kept, and I hope the 
parties to this discussion don’t either. 

> - I am expecting this document to call out the algorithm 1 as the only one it 
> is defining/describing and 6.3.2 are guidelines for other approaches when 
> Algorithm 1 is not feasible. This should be reflected in the document.

I didn’t think "when Algorithm 1 is not feasible” was implicit in the document, 
it was just “here are two approaches” with no editorializing about a preference 
between the two. (I haven’t read it recently so I *could* be wrong, but that’s 
how I recall it.)

Assuming my recollection is right, I think it would be unwise to change the 
document to state a preference. 

Thanks,

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

Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[John Scudder]

P. S. With this change I guess you’d also want to change “algorithm 1” to just 
“algorithm.”

—John

On Apr 5, 2024, at 4:33 PM, John Scudder  wrote:



[External Email. Be cautious of content]


Thanks, Les. LGTM. It’s late in Zahed’s TZ so I’m guessing he might not get 
back to us until Monday.

—John

On Apr 5, 2024, at 3:07 PM, Les Ginsberg (ginsberg)  wrote:


Zahed/John –

Here is a proposed revision of the section in question (not yet vetted with any 
of my co-authors).
Have a read and let me know what you think.

For your convenience, I have attached a diff file.

   Les

6.3.2.  Transmitter Based Congestion Control

   The approach to congestion control described in this section does not
   depend upon direct signaling from the receiver.  Instead it adapts
   the transmission rate based on measurement of the actual rate of
   acknowledgments received.

   When congestion control is necessary, it can be implemented based on
   knowledge of the current flooding rate and the current
   acknowledgement rate.  The algorithm used is a local matter and there
   is no requirement or intent to standardize an algorithm.  But there are a
   number of aspects which serve as guidelines which can be described.
   Algorithms based on this approach SHOULD follow the recommendations
   described below.

   A maximum LSP transmission rate (LSPTxMax) SHOULD be configurable.
   This represents the fastest LSP transmission rate which will be
   attempted.  This value SHOULD be applicable to all interfaces and
   SHOULD be consistent network wide.

   When the current rate of LSP transmission (LSPTxRate) exceeds the
   capabilities of the receiver, the congestion control algorithm needs
   to quickly and aggressively reduce the LSPTxRate.  Slower
   responsiveness is likely to result in a larger number of
   retransmissions which can introduce much longer delays in
   convergence.

   Dynamic increase of the rate of LSP transmission (LSPTxRate) (i.e.,
   faster) SHOULD be done less aggressively and only be done when the
   neighbor has demonstrated its ability to sustain the current
   LSPTxRate.

   The congestion control algorithm SHOULD NOT assume the receive
   performance of a neighbor is static, i.e., it SHOULD handle transient
   conditions which result in a slower or faster receive rate on the
   part of a neighbor.

   The congestion control algorithm SHOULD consider the expected delay
   time in receiving an acknowledgment.  It therefore incorporates the
   neighbor partialSNPInterval (Section 4.5) to help determine whether
   acknowlegments are keeping pace with the rate of LSPs transmitted.
   In the absence of an advertisement of partialSNPInterval, a locally
   configured value can be used.

From: John Scudder mailto:j...@juniper.net>>
Sent: Friday, April 5, 2024 9:37 AM
To: Zaheduzzaman Sarker 
mailto:zahed.sarker.i...@gmail.com>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
The IESG mailto:i...@ietf.org>>; 
draft-ietf-lsr-isis-fast-flood...@ietf.org<mailto:draft-ietf-lsr-isis-fast-flood...@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>; 
acee-i...@gmail.com<mailto:acee-i...@gmail.com>
Subject: Re: Zaheduzzaman Sarker's Discuss on 
draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

Thanks, Zahed.

Les and all, for clarity: please propose a revision, and then Zahed will take a 
look at it and sign off or raise any remaining concerns.

—John


On Apr 5, 2024, at 9:15 AM, Zaheduzzaman Sarker 
mailto:zahed.sarker.i...@gmail.com>> wrote:


Hi John,

That might work, given that the content of the section also reflects the 
intention clearly and matches with the section title change. I can have a look 
if there is any proposed changes.

//Zahed

On Fri, Apr 5, 2024 at 3:00 PM John Scudder 
mailto:j...@juniper.net>> wrote:
Hi Les,


On Apr 5, 2024, at 12:17 AM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
John – I am not entirely clear on what would address your comment. Would 
replacing “algorithm” with “approach” in Section 6.3.2 be satisfactory?

I think so, with the exception of “there is no requirement or intent to 
standardize an algorithm” which would remain as written. But this is really 
Zahed’s question to answer. Zahed?, does s/algorithm/approach/g in Section 
6.3.2 (including section title) work for you, or do you have another suggestion?

Thanks,

—John


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

Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[John Scudder]

Thanks, Les. LGTM. It’s late in Zahed’s TZ so I’m guessing he might not get 
back to us until Monday.

—John

On Apr 5, 2024, at 3:07 PM, Les Ginsberg (ginsberg)  wrote:


Zahed/John –

Here is a proposed revision of the section in question (not yet vetted with any 
of my co-authors).
Have a read and let me know what you think.

For your convenience, I have attached a diff file.

   Les

6.3.2.  Transmitter Based Congestion Control

   The approach to congestion control described in this section does not
   depend upon direct signaling from the receiver.  Instead it adapts
   the transmission rate based on measurement of the actual rate of
   acknowledgments received.

   When congestion control is necessary, it can be implemented based on
   knowledge of the current flooding rate and the current
   acknowledgement rate.  The algorithm used is a local matter and there
   is no requirement or intent to standardize an algorithm.  But there are a
   number of aspects which serve as guidelines which can be described.
   Algorithms based on this approach SHOULD follow the recommendations
   described below.

   A maximum LSP transmission rate (LSPTxMax) SHOULD be configurable.
   This represents the fastest LSP transmission rate which will be
   attempted.  This value SHOULD be applicable to all interfaces and
   SHOULD be consistent network wide.

   When the current rate of LSP transmission (LSPTxRate) exceeds the
   capabilities of the receiver, the congestion control algorithm needs
   to quickly and aggressively reduce the LSPTxRate.  Slower
   responsiveness is likely to result in a larger number of
   retransmissions which can introduce much longer delays in
   convergence.

   Dynamic increase of the rate of LSP transmission (LSPTxRate) (i.e.,
   faster) SHOULD be done less aggressively and only be done when the
   neighbor has demonstrated its ability to sustain the current
   LSPTxRate.

   The congestion control algorithm SHOULD NOT assume the receive
   performance of a neighbor is static, i.e., it SHOULD handle transient
   conditions which result in a slower or faster receive rate on the
   part of a neighbor.

   The congestion control algorithm SHOULD consider the expected delay
   time in receiving an acknowledgment.  It therefore incorporates the
   neighbor partialSNPInterval (Section 4.5) to help determine whether
   acknowlegments are keeping pace with the rate of LSPs transmitted.
   In the absence of an advertisement of partialSNPInterval, a locally
   configured value can be used.

From: John Scudder mailto:j...@juniper.net>>
Sent: Friday, April 5, 2024 9:37 AM
To: Zaheduzzaman Sarker 
mailto:zahed.sarker.i...@gmail.com>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
The IESG mailto:i...@ietf.org>>; 
draft-ietf-lsr-isis-fast-flood...@ietf.org<mailto:draft-ietf-lsr-isis-fast-flood...@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>; 
acee-i...@gmail.com<mailto:acee-i...@gmail.com>
Subject: Re: Zaheduzzaman Sarker's Discuss on 
draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

Thanks, Zahed.

Les and all, for clarity: please propose a revision, and then Zahed will take a 
look at it and sign off or raise any remaining concerns.

—John


On Apr 5, 2024, at 9:15 AM, Zaheduzzaman Sarker 
mailto:zahed.sarker.i...@gmail.com>> wrote:


Hi John,

That might work, given that the content of the section also reflects the 
intention clearly and matches with the section title change. I can have a look 
if there is any proposed changes.

//Zahed

On Fri, Apr 5, 2024 at 3:00 PM John Scudder 
mailto:j...@juniper.net>> wrote:
Hi Les,


On Apr 5, 2024, at 12:17 AM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
John – I am not entirely clear on what would address your comment. Would 
replacing “algorithm” with “approach” in Section 6.3.2 be satisfactory?

I think so, with the exception of “there is no requirement or intent to 
standardize an algorithm” which would remain as written. But this is really 
Zahed’s question to answer. Zahed?, does s/algorithm/approach/g in Section 
6.3.2 (including section title) work for you, or do you have another suggestion?

Thanks,

—John


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

Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[John Scudder]

Thanks, Zahed.

Les and all, for clarity: please propose a revision, and then Zahed will take a 
look at it and sign off or raise any remaining concerns.

—John

On Apr 5, 2024, at 9:15 AM, Zaheduzzaman Sarker  
wrote:



Hi John,

That might work, given that the content of the section also reflects the 
intention clearly and matches with the section title change. I can have a look 
if there is any proposed changes.

//Zahed

On Fri, Apr 5, 2024 at 3:00 PM John Scudder 
mailto:j...@juniper.net>> wrote:
Hi Les,

On Apr 5, 2024, at 12:17 AM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

John – I am not entirely clear on what would address your comment. Would 
replacing “algorithm” with “approach” in Section 6.3.2 be satisfactory?

I think so, with the exception of “there is no requirement or intent to 
standardize an algorithm” which would remain as written. But this is really 
Zahed’s question to answer. Zahed?, does s/algorithm/approach/g in Section 
6.3.2 (including section title) work for you, or do you have another suggestion?

Thanks,

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

Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[John Scudder]

Hi Les,

On Apr 5, 2024, at 12:17 AM, Les Ginsberg (ginsberg)  wrote:

John – I am not entirely clear on what would address your comment. Would 
replacing “algorithm” with “approach” in Section 6.3.2 be satisfactory?

I think so, with the exception of “there is no requirement or intent to 
standardize an algorithm” which would remain as written. But this is really 
Zahed’s question to answer. Zahed?, does s/algorithm/approach/g in Section 
6.3.2 (including section title) work for you, or do you have another suggestion?

Thanks,

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

Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[John Scudder]

Adding Zahed’s current email and deleting his old/nonfunctional one.

— John

On Apr 5, 2024, at 12:17 AM, Les Ginsberg (ginsberg)  wrote:



[External Email. Be cautious of content]

John/Zahed –

In regards to Algorithm 2, note that older versions used the term “Flow 
Control”, but based on the discussion with Mirja (not that I am blaming her…) 
we changed that section to use the term “Congestion Control”.

This seems proper to me. If one looks at Section 6.1 – and in particular 
paragraphs 2 and 3 – congestion control seems like the correct choice.


Zahed – I would appreciate your updated response after rereading those 
paragraphs.

John – I am not entirely clear on what would address your comment. Would 
replacing “algorithm” with “approach” in Section 6.3.2 be satisfactory?

  Les


From: John Scudder 
Sent: Thursday, April 4, 2024 6:59 AM
To: Zaheduzzaman Sarker 
Cc: The IESG ; draft-ietf-lsr-isis-fast-flood...@ietf.org; 
lsr-cha...@ietf.org; lsr@ietf.org; acee.i...@gmail.com; acee-i...@gmail.com
Subject: Re: Zaheduzzaman Sarker's Discuss on 
draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

Hi Zahed,

I guess the authors should respond comprehensively. I do have one response to 
your comments on algorithm 2, though. They seem to boil down to your first 
comment, "Can we really call congestion control algorithm 2 a congestion 
control algorithm?” It seems to me, on looking at the document again, that the 
answer is probably “no”. From §6.3.2, with emphasis added:

"When congestion control is necessary, it can be implemented based on knowledge 
of the current flooding rate and the current acknowledgement rate. **Such an 
algorithm is a local matter and there is no requirement or intent to 
standardize an algorithm.** There are a number of aspects which serve as 
guidelines which can be described."

I wonder if it’s both necessary and sufficient to reword “algorithm” 2 to be 
called something else, and to remove the RFC 2119 keywords from 6.3.x. As I 
read the quoted text, it’s not an algorithm, it’s hints towards an algorithm.

Looking forward to your comments and those of the authors.

—John


On Apr 4, 2024, at 6:16 AM, Zaheduzzaman Sarker via Datatracker 
mailto:nore...@ietf.org>> wrote:

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-lsr-isis-fast-flooding-08: Discuss

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!C4IK0qxrHCShIaZBQk48oNHSXQ7rb3GAhaymBNFbvj-okuR1iO8UDVkcxrsY1Kxfqj_vVLgd108E$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!C4IK0qxrHCShIaZBQk48oNHSXQ7rb3GAhaymBNFbvj-okuR1iO8UDVkcxrsY1Kxfqj_vVLgd108E$>
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-isis-fast-flooding/__;!!NEt6yMaO-gk!C4IK0qxrHCShIaZBQk48oNHSXQ7rb3GAhaymBNFbvj-okuR1iO8UDVkcxrsY1Kxfqj_vVG87RLDF$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!C4IK0qxrHCShIaZBQk48oNHSXQ7rb3GAhaymBNFbvj-okuR1iO8UDVkcxrsY1Kxfqj_vVG87RLDF$>



--
DISCUSS:
--

Thanks for working on this specification. Thanks for Mirja for the TSVART
review.

I would like to discuss the following points as I believe some clarifications
would help -

- Does the flow and congestion control algorithm 1 assume that there is only on
(input)queue in a particular link? I understand that the motivation for
congestion control algorithm 2 is that there are multiple input queues and
defining rwin is difficult. Why is that easy for the case of algorithm 1?

- Can we really call congestion control algorithm 2 a congestion control
algorithm? We are are really solving the problem of flow control, it sounded
more like a emergency break ( aka circuit breaker ) to me where you reduce or
even stop sending LSPs. My point is I am not sure how to interpret the
congestion control algorithm 2 with any sort of details. If I replace section
6.3.2 with - "if the routing architecture does not support deterministic rwin,
the transmitter MUST adapts the transmission rate based on measurement of the
actual rate of acknowledgments received." what harm would it cause?

- For the congestion control algorithm 2, I am missing when the transmitter
should reduce or when it should stop sending as I am not sure reducing the
transmission rate would solve the problem of not. This comes from 

Re: [Lsr] Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)

[John Scudder]

Hi Zahed,

I guess the authors should respond comprehensively. I do have one response to 
your comments on algorithm 2, though. They seem to boil down to your first 
comment, "Can we really call congestion control algorithm 2 a congestion 
control algorithm?” It seems to me, on looking at the document again, that the 
answer is probably “no”. From §6.3.2, with emphasis added:

"When congestion control is necessary, it can be implemented based on knowledge 
of the current flooding rate and the current acknowledgement rate. **Such an 
algorithm is a local matter and there is no requirement or intent to 
standardize an algorithm.** There are a number of aspects which serve as 
guidelines which can be described."

I wonder if it’s both necessary and sufficient to reword “algorithm” 2 to be 
called something else, and to remove the RFC 2119 keywords from 6.3.x. As I 
read the quoted text, it’s not an algorithm, it’s hints towards an algorithm.

Looking forward to your comments and those of the authors.

—John

On Apr 4, 2024, at 6:16 AM, Zaheduzzaman Sarker via Datatracker 
 wrote:

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-lsr-isis-fast-flooding-08: Discuss

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!C4IK0qxrHCShIaZBQk48oNHSXQ7rb3GAhaymBNFbvj-okuR1iO8UDVkcxrsY1Kxfqj_vVLgd108E$
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-isis-fast-flooding/__;!!NEt6yMaO-gk!C4IK0qxrHCShIaZBQk48oNHSXQ7rb3GAhaymBNFbvj-okuR1iO8UDVkcxrsY1Kxfqj_vVG87RLDF$



--
DISCUSS:
--

Thanks for working on this specification. Thanks for Mirja for the TSVART
review.

I would like to discuss the following points as I believe some clarifications
would help -

- Does the flow and congestion control algorithm 1 assume that there is only on
(input)queue in a particular link? I understand that the motivation for
congestion control algorithm 2 is that there are multiple input queues and
defining rwin is difficult. Why is that easy for the case of algorithm 1?

- Can we really call congestion control algorithm 2 a congestion control
algorithm? We are are really solving the problem of flow control, it sounded
more like a emergency break ( aka circuit breaker ) to me where you reduce or
even stop sending LSPs. My point is I am not sure how to interpret the
congestion control algorithm 2 with any sort of details. If I replace section
6.3.2 with - "if the routing architecture does not support deterministic rwin,
the transmitter MUST adapts the transmission rate based on measurement of the
actual rate of acknowledgments received." what harm would it cause?

- For the congestion control algorithm 2, I am missing when the transmitter
should reduce or when it should stop sending as I am not sure reducing the
transmission rate would solve the problem of not. This comes from lack of
details on the particular algorithm that will be implemented eventually.

- Section 6.3.2. says -

   The congestion control algorithm MUST NOT assume the receive performance of
   a neighbor is static, i.e., it MUST handle transient conditions which
   result in a slower or faster receive rate on the part of a neighbor.

 How to separate the persistent congestion from transient slower receive rate?
 I am not sure how to fulfill the "MUST".


--
COMMENT:
--

I have some further questions or comments -

- How does the implementers select between congestion control (CC) algorithm 1
and 2? or is the intention that both gets implemented and after experiments we
pick one? As in my discuss point I am not sure about the CC algorithm 2 on how
to conclude on the experiments.

- It already says flow control and congestion control is a Layer-4
responsibility, it would be great if we can say why that is not the preferred
layer for fast flooding even if it may be obvious for some of us.

- Section 6.3.2 says -

   When congestion control is necessary, it can be implemented based on
   knowledge of the current flooding rate and the current acknowledgement rate.

 So, how do we know when the congestion control is necessary?




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

Re: [Lsr] [Technical Errata Reported] RFC2328 (7850)

[John Scudder]

Regarding whether it should be verified or HFDU, I haven’t taken a hard look 
yet. The operative question from the guidance [1] though, is if the change 
corrects “errors at the time the document was published”.

The guidance is necessarily not completely prescriptive and my impression is 
that these errata could be verified in that they do not change the operation of 
the protocol from what was intended (“Technical items that have a clear 
resolution in line with the original intent should be classified as Verified.”)

I’d be interested in any further discussion, though, and won’t immediately 
verify the errata.

—John

[1] 
https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/

On Mar 16, 2024, at 3:19 PM, Ketan Talaulikar  wrote:



[External Email. Be cautious of content]


Hi Acee,

I agree with this errata and thanks for raising it.

Not sure if it can be "Verified" or "Held for Document Update" though.

Thanks,
Ketan


On Fri, Mar 15, 2024 at 8:07 PM RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>> wrote:
The following errata report has been submitted for RFC2328,
"OSPF Version 2".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7850

--
Type: Technical
Reported by: Alfred Lindem mailto:acee.i...@gmail.com>>

Section: 10.7/A.3.5

Original Text
-
Section 10.7

Each LSA specified in the Link State Request packet should be
located in the router's database, and copied into Link State
Update packets for transmission to the neighbor.  These LSAs
should NOT be placed on the Link state retransmission list for
the neighbor.  If an LSA cannot be found in the database,
something has gone wrong with the Database Exchange process, and
neighbor event BadLSReq should be generated.

Section A.3.5

Link State Update packets are multicast on those physical networks
that support multicast/broadcast.  In order to make the flooding
procedure reliable, flooded LSAs are acknowledged in Link State
Acknowledgment packets.  If retransmission of certain LSAs is
necessary, the retransmitted LSAs are always sent directly to the
neighbor.  For more information on the reliable flooding of LSAs,
consult Section 13.

Corrected Text
--
Section 10.7

Each LSA specified in the Link State Request packet should be
located in the router's database, and copied into Link State
Update packets for transmission directly to the neighbor,
i.e., unicast on all interface types except point-to-point
interfaces where all OSPF packets are sent to the address
AllSPFRouters.  These LSAs should NOT be placed on the Link
state retransmission list for the neighbor.  If an LSA cannot
be found in the database, something has gone wrong with the
Database Exchange process, and neighbor event BadLSReq should
be generated.

Section A.3.5

Link State Update packets are multicast on those physical networks
that support multicast/broadcast.  In order to make the flooding
procedure reliable, flooded LSAs are acknowledged in Link State
Acknowledgment packets.  If retransmission of certain LSAs is
necessary, the retransmitted LSAs are always sent directly to the
neighbor.  For more information on the reliable flooding of LSAs,
consult Section 13. Link State Update packets are also sent
directly to the neighbor in response to Link State Request
packets as specified in Section 10.7.


Notes
-
Clarify that OSPF Link State Updates sent in response to OSPF Link Requests 
should be unicast.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
will log in to change the status and edit the report, if necessary.

--
RFC2328 (no draft string recorded)
--
Title   : OSPF Version 2
Publication Date: April 1998
Author(s)   : J. Moy
Category: INTERNET STANDARD
Source  : Open Shortest Path First IGP
Stream  : IETF
Verifying Party : IESG

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

Re: [Lsr] AD review of draft-ietf-lsr-dynamic-flooding-14

[John Scudder]

Hi Tony and all,

On rereading my comments about Section 6.7, it occurred to me that I ignored 
distributed mode. I can see that in that mode, the concept of "old" and "new" 
topology does make sense, isn't hard to nail down, and in that context, 
paragraph two makes sense. My comments continue to apply to centralized mode, 
though.

Thanks,

--John

> On Feb 6, 2024, at 8:52 PM, John Scudder  
> wrote:
> 
> ### Section 6.7
> 
> I had asked about old vs. new topologies. Your new version has this:
> 
>   In centralized mode, transient conditions with the Area Leader's set
>   of advertisements may cause multiple flooding topologies to be
>   advertised concurrently.  In this case, nodes SHOULD flood on each of
>   these topologies until the transient condition is resolved.
> 
>   When the flooding topology changes on a node, either as a result of
>   the local computation in distributed mode or as a result of the
>   advertisement from the Area Leader in centralized mode, the node MUST
>   continue to flood on both the old and new flooding topology for a
>   limited amount of time.  This is required to provide all nodes
>   sufficient time to migrate to the new flooding topology.
> 
>   In centralized mode, a node doesn't need to distinguish between the
>   old and new flooding topologies.  As updated information comes in, it
>   can be added to the existing flooding topology.  As old information
>   is replaced by subsequent updates, it can be removed, thereby
>   converging to the new information.
> 
> In the first quoted paragraph, you tell me that in centralized mode there can 
> be multiple concurrent topologies. But then in the third paragraph, you tell 
> me I don't need to care about distinguishing between them. In that case, why 
> are we even talking about them? Also, I still don't think I know how to 
> distinguish between them (although I guess that's OK because the third 
> paragraph tells me I don't have to).
> 
> If the third paragraph is the bottom line, can't the second paragraph be 
> deleted? And can't the first paragraph be rewritten considerably? This whole 
> thing reads like an artifact of some long-ago working group debate, or debate 
> between the authors, that was resolved as "just flood over whatever topology 
> you currently know, it will sort itself out, it’s an eventually-consistent 
> protocol”... which is what you would do if none of these paragraphs existed 
> at all, and you were just implementing the spec as written, without trying to 
> exercise creativity.
> 
> If the point of these paragraphs is what I’ve guessed above, I wonder if it 
> would be better to rewrite them without talking about “old” and “new” 
> topology since those are not discrete things we can even nail down. Something 
> along the lines of, “At any given time, a node's concept of the flooding 
> topology may be in flux, due to the receipt of updates from the Area Leader 
> adding or removing links from the flooding topology. A node need not take any 
> special action, but should flood according to its current view of the 
> flooding topology."

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

Re: [Lsr] AD review of draft-ietf-lsr-dynamic-flooding-14

[John Scudder]

Hi Tony,

> On Feb 6, 2024, at 7:43 PM, Tony Li  wrote:
> 
> Thank you for your fantastic comments.  Please see inline.

You’re welcome and thank you for your careful reply, and also for the 
additional polishing. I’ve just reviewed the diff, it looks good. Just a few 
things to note in the revision, below.

—John

### Section 5.1.1

• 1-127: Standardized distributed algorithms. Individual values are to 
be assigned according to the "Specification Required" policy defined in 
[RFC8126] (see Section 7.3).

But in 7.3 you’ve changed the policy to Expert Review. I suggest deleting the 
conflicting sentence here, so,

NEW:
• 1-127: Standardized distributed algorithms. 

On the basis that it’s better to have a single source of truth when possible. 
It would also be OK to update the conflicting text, though. 

### Section 5.1.2

   2.  Indicate the set of algorithms that it supports, if any.

But since you pointed out that "6.4 prohibits zero algorithms”, can’t “if any” 
be deleted since there must always be at least one?

### Section 6.7

I had asked about old vs. new topologies. Your new version has this:

   In centralized mode, transient conditions with the Area Leader's set
   of advertisements may cause multiple flooding topologies to be
   advertised concurrently.  In this case, nodes SHOULD flood on each of
   these topologies until the transient condition is resolved.

   When the flooding topology changes on a node, either as a result of
   the local computation in distributed mode or as a result of the
   advertisement from the Area Leader in centralized mode, the node MUST
   continue to flood on both the old and new flooding topology for a
   limited amount of time.  This is required to provide all nodes
   sufficient time to migrate to the new flooding topology.

   In centralized mode, a node doesn't need to distinguish between the
   old and new flooding topologies.  As updated information comes in, it
   can be added to the existing flooding topology.  As old information
   is replaced by subsequent updates, it can be removed, thereby
   converging to the new information.

In the first quoted paragraph, you tell me that in centralized mode there can 
be multiple concurrent topologies. But then in the third paragraph, you tell me 
I don't need to care about distinguishing between them. In that case, why are 
we even talking about them? Also, I still don't think I know how to distinguish 
between them (although I guess that's OK because the third paragraph tells me I 
don't have to). 

If the third paragraph is the bottom line, can't the second paragraph be 
deleted? And can't the first paragraph be rewritten considerably? This whole 
thing reads like an artifact of some long-ago working group debate, or debate 
between the authors, that was resolved as "just flood over whatever topology 
you currently know, it will sort itself out, it’s an eventually-consistent 
protocol”... which is what you would do if none of these paragraphs existed at 
all, and you were just implementing the spec as written, without trying to 
exercise creativity.

If the point of these paragraphs is what I’ve guessed above, I wonder if it 
would be better to rewrite them without talking about “old” and “new” topology 
since those are not discrete things we can even nail down. Something along the 
lines of, “At any given time, a node's concept of the flooding topology may be 
in flux, due to the receipt of updates from the Area Leader adding or removing 
links from the flooding topology. A node need not take any special action, but 
should flood according to its current view of the flooding topology."
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD review of draft-ietf-lsr-isis-fast-flooding-05

[John Scudder]

Hi All,

I reviewed the diffs from 05 to 06 and the email; looks good to me, thank you.

I see that there is an active discussion going on about Mirja Kühlewind’s 
TSVART review of 06. It seems to me it would probably be better to let that 
play out before sending the document for IETF Last Call. Seem reasonable? By 
the way, please ping me when you think the conversation has concluded (or 
anyway reached a state where I should send the doc for IETF LC). I’m going to 
put it back in the “revised ID needed” substate for now, on the assumption that 
version 07 will be required to address the TSVART review; this has the benefit 
that datatracker will update the substate and flag it to me when you push a new 
version. If you end up concluding no new version is needed, you can let me know 
and I can clear the substate.

Thanks,

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

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)

[John Scudder]

Hi Acee, Roman, all,

[top posting, hope that’s OK]

After talking with Roman about this today, what I understand his position to be 
is (at least in part), since the document identifies one specific case of a 
type of attack ("The ability to disable OSPFv3 Extended LSA support can result 
in a denial of service”), shouldn’t it also list other cases? What’s special 
about "denial of service” vs. other things such as the ones Roman mentioned? I 
don’t think he was seeking an in-depth exploration of these, just a more 
complete summary list. I also wonder if the concern could equally be satisfied 
by removing the one special case.

I’m sure Roman will chime in if I’ve gotten this wrong.

Thanks,

—John

> On Jan 31, 2024, at 8:50 PM, Acee Lindem  wrote:
> 
> 
> 
>> On Jan 31, 2024, at 20:14, Acee Lindem  wrote:
>> 
>> 
>> 
>>> On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker  
>>> wrote:
>>> 
>>> Roman Danyliw has entered the following ballot position for
>>> draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Discuss
>>> 
>>> 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/about/groups/iesg/statements/handling-ballot-positions/
>>>  
>>> for more information about how to handle DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>>> 
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> ** Section 5.
>>> 
>>>  Write
>>>  operations (e.g., edit-config) to these data nodes without proper
>>>  protection can have a negative effect on network operations.  There
>>>  are the subtrees and data nodes and their sensitivity/vulnerability:
>>> 
>>> /ospf:ospf/extended-lsa-support
>>> /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
>>> The ability to disable OSPFv3 Extended LSA support can result in a
>>> denial of service.
>>> 
>>> Isn’t it more than just denial of service?  In certain environments wouldn’t
>>> the ability to modify OSPF Extended LSA configurations enable an attacker 
>>> to:
>>> modify network topologies to enable select traffic to avoid inspection or
>>> treatment by security controls; route traffic in a way that it would be 
>>> subject
>>> to inspect/modification by an adversary node; or gain access to otherwise
>>> segregated parts of the network.
>> 
>> Only if they were able to craft extended LSAs on behalf of the original as 
>> well as
>> modify the YANG configuration added by this document. I didn’t think we’d 
>> have to
>> reiterate all the possible protocol attacks for every incremental 
>> enhancement.
> 
> Furthermore, no one is going to use the support of extended LSAs to isolate 
> OSPFv3 domains 
> from one another. The configuration is to control migration to the extended 
> LSA encodings.
> Please see RFC 8362 for more information on OSPFv3 Extended LSAs.  
> 
> Acee
> 
> 
> 
> 
> 
>> 
>> Acee
>> 
>> 
>> 
>>> 
>>> 
>>> --
>>> COMMENT:
>>> --
>>> 
>>> As an editorial note, I would have benefit from some narrative prose on the 
>>> data model.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!CSaaziWFGrg6dv81sm55-XN-CP5eUEsFoeObIEuQzH8mYmJPURb3VboumvFzwTwOiHyiHP8O67tleiE$

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

Re: [Lsr] draft-ietf-lsr-isis-fast-flooding IANA section

[John Scudder]

On Jan 24, 2024, at 12:51 PM, bruno.decra...@orange.com wrote:
> 
> as a correction we are proposing the following two changes

Looks good to me.

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

[Lsr] draft-ietf-lsr-isis-fast-flooding IANA section

[John Scudder]

Hi Authors,

This isn't a full review of your document, however, I was looking at it and 
noticed that in the IANA section, you create two registries with the "expert 
review" policy. RFC 8126 says that you need to provide guidance to the 
designated experts for such registries. If you plan on having these registries 
grouped under 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
then you will be covered since there is blanket guidance for all registries in 
that group, but then you should mention in your IANA section that you want them 
grouped there.

Thanks,

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

Re: [Lsr] [Technical Errata Reported] RFC5838 (7644)

[John Scudder]

Quickly reversing myself, and to quote my other reply just now: "Actually, upon 
reviewing this one, I'm leaning back toward simply rejecting both this erratum 
and erratum 7644. As we discussed earlier in the thread on this one, the best 
fix (assuming the working group agrees is a fix is merited, of course) is a 
draft to update or replace the base spec.”

In short, “never mind!”

—John

> On Jan 11, 2024, at 2:24 PM, John Scudder  wrote:
> 
> Hi Acee, WG,
> 
> I'm convinced this doesn't meet the criteria to be verified as a technical 
> erratum. I am considering verifying it as "Hold for Document Update”, though. 
> The definition for HFDU is "The erratum is not a necessary update to the RFC. 
> However, any future update of the document might consider this erratum, and 
> determine whether it is correct and merits including in the update.” [1]
> 
> Please let me know soon if you have any concerns about that disposition.
> 
> --John
> 
> [1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
> 
> 
>> On Sep 17, 2023, at 6:25 PM, Acee Lindem  wrote:
>> 
>> Given that the context of the “Interface MTU” is specifically the “interface 
>> MTU” field in OSPFv3 Database Description packets and OSPF virtual links 
>> (RFC 2328), the additions recommended in this Errata are unnecessary. The 
>> Errata should be rejected.
>> 
>> Thanks,
>> Acee
>>> On Sep 17, 2023, at 15:58, RFC Errata System  
>>> wrote:
>>> 
>>> The following errata report has been submitted for RFC5838,
>>> "Support of Address Families in OSPFv3".
>>> 
>>> --
>>> You may review the report below and at:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7644__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmW7pFbpMU$
>>> 
>>> --
>>> Type: Technical
>>> Reported by: Owen DeLong 
>>> 
>>> Section: 2.7
>>> 
>>> Original Text
>>> -
>>> Interface MTU
>>>The size in octets of the largest address family specific datagram
>>>that can be sent on the associated interface without
>>>fragmentation.  The MTUs of common Internet link types can be
>>>found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
>>>to 0 in Database Description packets sent over virtual links.
>>> 
>>> 
>>> Corrected Text
>>> --
>>> Interface MTU
>>>The size in octets of the largest address family specific datagram
>>>that can be sent on the associated interface without
>>>fragmentation.  The MTUs of common Internet link types can be
>>>found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
>>>to 0 in Database Description packets sent over (OSPF3) virtual links.
>>>This recommendation MUST NOT be applied to tunnel and other virtual
>>>or software interfaces which carry traffic other than OSPF protocol 
>>> packets.
>>> 
>>> Notes
>>> -
>>> Currently, the language is ambiguous and at least one vendor has 
>>> implemented OSPF3 sending an MTU of zero on GRE interfaces (and possibly 
>>> others such as IPIP, IPSEC, etc., as I have not tested these). I believe 
>>> that the intent of the RFC is to refer strictly to OSPF virtual-links which 
>>> carry only OSPF protocol data and therefore have no meaningful MTU. When 
>>> this is mistakenly applied to other forms of "virtual" interfaces such as 
>>> tunnels, the results can be quite harmful.
>>> 
>>> As such, I think that clarification is in order, since the vendor in 
>>> question is unrepentant and claims their current implementation to be 
>>> compliant with the RFC.
>>> 
>>> Instructions:
>>> -
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>> 
>>> --
>>> RFC5838 (draft-ietf-ospf-af-alt-10)
>>> --
>>> Title   : Support of Address Families in OSPFv3
>>> Publication Date: April 2010
>>> Author(s)   : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. 
>>> Aggarwal
>>> Category: PROPOSED STANDARD
>>> Source  : Open Shortest Path First IGP
>>> Area: Routing
>>> Stream  : IETF
>>> Verifying Party : IESG
>>> 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmWKATRhUo$
> 

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

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[John Scudder]

Actually, upon reviewing this one, I'm leaning back toward simply rejecting 
both this erratum and erratum 7644. As we discussed earlier in the thread on 
this one, the best fix (assuming the working group agrees is a fix is merited, 
of course) is a draft to update or replace the base spec.

—John

> On Sep 20, 2023, at 2:05 PM, Acee Lindem  wrote:
> 
> 
> I’m beginning to get a feeling of Deja MTU…
> 
> Acee
> 
>> On Sep 19, 2023, at 19:15, RFC Errata System  
>> wrote:
>> 
>> The following errata report has been submitted for RFC5340,
>> "OSPF for IPv6".
>> 
>> --
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7649__;!!NEt6yMaO-gk!BYmUJjHFQ4KMZJsCjZgl_d0_PYcaJK_iJ6PuAAKdEtrss5IOJOR_WhubhtnyFvmisUP-WbpxnM0kOok$
>> 
>> --
>> Type: Technical
>> Reported by: Owen DeLong 
>> 
>> Section: A.3.3 (in part)
>> 
>> Original Text
>> -
>> Interface MTU
>> The size in bytes of the largest IPv6 datagram that can be sent
>> out the associated interface without fragmentation.  The MTUs of
>> common Internet link types can be found in Table 7-1 of [MTUDISC].
>> Interface MTU should be set to 0 in Database Description packets
>> sent over virtual links.
>> 
>> 
>> Corrected Text
>> --
>> Interface MTU
>> The size in bytes of the largest IPv6 datagram that can be sent
>> out the associated interface without fragmentation.  The MTUs of
>> common Internet link types can be found in Table 7-1 of [MTUDISC].
>> Interface MTU should be set to 0 in Database Description packets
>> sent over OSPF virtual links. This rule should not be applied to tunnel
>> or other software interfaces.
>> 
>> Notes
>> -
>> OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed 
>> and this provision makes sense. For interfaces that have an actual MTU, even 
>> though they may be "virtual" interfaces, they are not "virtual links" in the 
>> intended meaning of this paragraph. As such, this change will provide 
>> clarification and remove ambiguity from the current standard. At least one 
>> popular router vendor implements this RFC as MTU = 0 sent on all GRE 
>> interfaces which results in incompatibilities with most other router 
>> platforms which expect an actual value. The router vendor points to this 
>> provision in the RFCs as justification for their implementation. It is 
>> (arguably) a legitimate, if nonsensical interpretation of the existing text.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>> 
>> --
>> RFC5340 (draft-ietf-ospf-ospfv3-update-23)
>> --
>> Title   : OSPF for IPv6
>> Publication Date: July 2008
>> Author(s)   : R. Coltun, D. Ferguson, J. Moy, A. Lindem
>> Category: PROPOSED STANDARD
>> Source  : Open Shortest Path First IGP
>> Area: Routing
>> Stream  : IETF
>> Verifying Party : IESG
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!BYmUJjHFQ4KMZJsCjZgl_d0_PYcaJK_iJ6PuAAKdEtrss5IOJOR_WhubhtnyFvmisUP-Wbpxjmyny-M$
> 

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

Re: [Lsr] [Technical Errata Reported] RFC5838 (7644)

[John Scudder]

Hi Acee, WG,

I'm convinced this doesn't meet the criteria to be verified as a technical 
erratum. I am considering verifying it as "Hold for Document Update”, though. 
The definition for HFDU is "The erratum is not a necessary update to the RFC. 
However, any future update of the document might consider this erratum, and 
determine whether it is correct and merits including in the update.” [1]

Please let me know soon if you have any concerns about that disposition.

--John

[1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/


> On Sep 17, 2023, at 6:25 PM, Acee Lindem  wrote:
> 
> Given that the context of the “Interface MTU” is specifically the “interface 
> MTU” field in OSPFv3 Database Description packets and OSPF virtual links (RFC 
> 2328), the additions recommended in this Errata are unnecessary. The Errata 
> should be rejected.
> 
> Thanks,
> Acee
>> On Sep 17, 2023, at 15:58, RFC Errata System  
>> wrote:
>> 
>> The following errata report has been submitted for RFC5838,
>> "Support of Address Families in OSPFv3".
>> 
>> --
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7644__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmW7pFbpMU$
>> 
>> --
>> Type: Technical
>> Reported by: Owen DeLong 
>> 
>> Section: 2.7
>> 
>> Original Text
>> -
>>  Interface MTU
>> The size in octets of the largest address family specific datagram
>> that can be sent on the associated interface without
>> fragmentation.  The MTUs of common Internet link types can be
>> found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
>> to 0 in Database Description packets sent over virtual links.
>> 
>> 
>> Corrected Text
>> --
>>  Interface MTU
>> The size in octets of the largest address family specific datagram
>> that can be sent on the associated interface without
>> fragmentation.  The MTUs of common Internet link types can be
>> found in Table 7-1 of [MTUDISC].  The Interface MTU SHOULD be set
>> to 0 in Database Description packets sent over (OSPF3) virtual links.
>> This recommendation MUST NOT be applied to tunnel and other virtual
>> or software interfaces which carry traffic other than OSPF protocol 
>> packets.
>> 
>> Notes
>> -
>> Currently, the language is ambiguous and at least one vendor has implemented 
>> OSPF3 sending an MTU of zero on GRE interfaces (and possibly others such as 
>> IPIP, IPSEC, etc., as I have not tested these). I believe that the intent of 
>> the RFC is to refer strictly to OSPF virtual-links which carry only OSPF 
>> protocol data and therefore have no meaningful MTU. When this is mistakenly 
>> applied to other forms of "virtual" interfaces such as tunnels, the results 
>> can be quite harmful.
>> 
>> As such, I think that clarification is in order, since the vendor in 
>> question is unrepentant and claims their current implementation to be 
>> compliant with the RFC.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>> 
>> --
>> RFC5838 (draft-ietf-ospf-af-alt-10)
>> --
>> Title   : Support of Address Families in OSPFv3
>> Publication Date: April 2010
>> Author(s)   : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. 
>> Aggarwal
>> Category: PROPOSED STANDARD
>> Source  : Open Shortest Path First IGP
>> Area: Routing
>> Stream  : IETF
>> Verifying Party : IESG
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!EqM7dBCk2SJzfxt702pp2Pbbk_Bes0OWPmR7eRHvIT3bmb7J2x7frRsHKbUzctMtiDBrCxmWKATRhUo$

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

[Lsr] AD review of draft-ietf-lsr-ospfv3-extended-lsa-yang

[John Scudder]

Hi All,

Thanks for the easy review, basically LGTM. I have just a few nits, below. I'll 
hold off on sending the doc for IETF LC for a short time, in case you want to 
fix these first. (It would be OK to send the current version, but IMO you might 
as well do another revision since GENART or other reviewers are likely to ask 
for some of these changes anyway.)

--John

## NITS

### Section 3

"The augmentations defined in the ietf-ospfv3-extended-lsa YANG model will 
provide"

They *do* provide these things, so delete "will"?

### Section 4

  /*
   * OSPFv3 Extend LSA Type Identities
   */

Shouldn't that be "Extended" not "Extend"?

### Section 5

"For OSPFv3 Extended LSAs, the ability to disable OSPFv3 Extended LSA support 
result in a denial of service"

Shouldn't that be "can result" or "results"? (Even with that patch the sentence 
is still a little off, it doesn't so much result in, as create an exposure to. 
But do as you will.)

This one is grammatically and shade-of-meaning-wise not quite right too: "The 
exposure of the Link State Database (LSDB) will expose the detailed topology of 
the network and information beyond the scope of OSPF router." ("OSPF router" 
needs a definite article or to be pluralized, at minimum, but maybe a bit more 
of a rewrite, if you choose.)

"This may be undesirable since both due to the fact that exposure may 
facilitate other attacks." Probably, delete "since both".
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label

[John Scudder]

Hi Hannes,

Thanks for pointing this out:

> On Dec 7, 2023, at 4:38 AM, Hannes Gredler 
>  wrote:
> 
> We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions and I 
> am not aware
> of any questions from implementators around ambiguity.

I checked RFCs 8665 and 8666, and they don't exhibit the same problem. Instead 
of indirecting the field definition to a different subsection, they take the 
more usual approach of defining it in line. So, all good as far as this issue 
is concerned.

Thanks,

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

Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label

[John Scudder]

Hi Acee,

> On Dec 7, 2023, at 3:44 PM, Acee Lindem  wrote:
> 
> We’ll probably never BIS these RFCs but I would agree that it would be good 
> for one of the RFC authors to provide a clearer definition of the 
> relationship between the L flag, V flag, TLV length, and TLV values (label, 
> index, value). Since it seems a single flag indicating whether the value is 
> an MPLS label or index into an MPLS label range would have sufficed, this 
> description would certainly be beneficial to those new to IGP segment 
> routing. Also, it is unclear why an index/value ever needs to be 4 octets 
> when the value is bounded by the MPLS label space itself.

I went ahead and filed the erratum with the minimal language suggested by Tony. 
I don't think that prevents moving ahead with your suggestion also if the 
working group thinks it's worthwhile, but I didn't want to hold up the simple 
fix.

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

Re: [Lsr] AD review of draft-ietf-lsr-isis-area-proxy-09

[John Scudder]

Hi Tony,

Thanks for your prompt reply. I can live with most of that, just a few 
follow-ups below.

> On Dec 7, 2023, at 3:45 PM, Tony Li  wrote:
> 
> Hi John,
> 
> Thank you for your comments and suggestions.  I’m incorporating most of
> them

Cool. Looking forward to reviewing version 10.

> and only responding to ones that warrant further discussion.

Ditto.

> […]
>> @@ -302,14 +315,23 @@
>>   value of the SRGB advertised by all Inside Nodes MUST start at the
>>   same value.  The range advertised for the area will be the minimum of
>>   all Inside Nodes.
>> ++---
>> +jgs: shouldn't the document say something about what to do if
>> +either one of the MUST requirements isn't met?
>> ++---
> 
> 
> If either is not met, it would be a protocol error and major malfunctions 
> will occur.
> The network manager should remedy the problem. I’m not sure that needs to be
> called out.
> 
> If you’re suggesting that implementations should complain if those 
> constraints are
> not met, we did not specify that as that would require a walk through the LSDB
> that is not otherwise required.

Doesn't the area leader already have to do an operation like that, to determine 
what range to advertise? I had expected to be told what the area leader is 
supposed to do if it encounters non-overlapping SRGB as it looks for the 
minimum mentioned in the quoted text. Halt and catch fire? Give up and log an 
error? Something else?

(Also, now that I've looked at that sentence a few more times, a nit: how about 
"will be the minimum of that advertised by all Inside Nodes"?)

[…]
>> @@ -644,6 +701,28 @@
>>   If the inside area supports Traffic Engineering (TE), the Area Leader
>>   SHOULD copy TE related sub-TLVs [RFC5305] Section 3 to each Extended
>>   IS Reachability TLV in the Proxy LSP.
>> ++---
>> +jgs: what is 4.4.4 and 4.4.5 are specified as MAY. According to the RFC
>> +2119 definition of MAY,
>> +
>> +5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>> +   truly optional.
>> +   [etc]
>> +
>> +That means it would be considered completely reasonable and OK for
>> +the area leader to omit both the IS neighbors TLV and end the extended
>> +IS neighbors TLV. Would the protocol still function correctly and
>> +usefully if both of those TLVs were omitted from the Proxy LSP?  Seems
>> +as though it wouldn't.
>> +
>> +I think probably what is going on here is that you're trying to say
>> +that ordinarily, only one or the other would be expected, not both.
>> +The RFC 2119 keywords seem like a poor fit for expressing this. This
>> +seems like a good time to remind you that it's not mandatory to use
>> +RFC 2119 keywords, and in cases like these where they hinder,
>> +rather than help, clarity, it's worth considering whether you should
>> +rewrite the affected text without relying on them.
>> ++---
> 
> 
> Yes, we would expect one and not both. There’s a sentence that even says
> that.

You're referring to this sentence, right? "An entry for a neighbor in both the 
IS Neighbors TLV and the Extended IS Neighbors would be functionally redundant, 
so the Area Leader SHOULD NOT do this."

> We intentionally selected 2119 keywords because we wanted to explicitly
> say what is permissible.
> 
> Again, the protocol would work syntactically and semantically if things are
> omitted, but not meet network architectural requirements. Additionally,
> we did not want to preclude filtering, so we did not think that ‘MUST’ was 
> called
> for.

I could swallow your justification for the various SHOULDs because you said (my 
paraphrase) that there isn't any single one of them that's of the essence for 
the utility of the protocol. However, if you don't advertise either of the IS 
Neighbors or Extended IS Neighbors TLVs, I don't think you have a useful 
routing protocol, do you? So, even though neither one of them, individually, is 
of the essence, collectively they still are. I don't think your text captures 
this. An example of text that would address this concern is,

OLD:
   An entry for a neighbor in both the IS Neighbors TLV and the Extended
   IS Neighbors would be functionally redundant, so the Area Leader
   SHOULD NOT do this.

NEW:
   An entry for a neighbor in both the IS Neighbors TLV and the Extended
   IS Neighbors would be functionally redundant, so the Area Leader
   SHOULD NOT do this. Although considered in isolation, either of these 
   two TLV types may be omitted, at least one MUST be included.

That's only an illustration, I don't think it's the most artful way to do it. 
My own preference would be something more like, change both MAY to “can”, and 
add something like,

   The Area Leader MAY omit either the IS Neighbors TLV or the Extended 
   IS Neighbors TLV, but it MUST include at least one of them.

If you're stuck on having each subsection stand on its own, you’d put the 
sentence in twice, once each. But I think you aren't stuck on that, because you 
only include the "functionally redundant" 

Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label

[John Scudder]

Hi Les,

> On Dec 7, 2023, at 4:03 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Let's be careful here.

Certainly. I don't think we've been proceeding recklessly so far, have we?

> SR-MPLS has been deployed for several years, there are multiple 
> implementations which have demonstrated interoperability, and clearly the 
> correct encoding of the SID is a key element of that interoperability.
>  
> As a co-author, I am happy to listen to relevant feedback, but any textual 
> change which has the potential to even suggest that an actual change has been 
> made in encoding is clearly undesirable.
>  
> John - I note you have already acknowledged any errata (or erratum ) would 
> be an editorial one - but given the above context and the fact that no one 
> over these many years has publicly voiced any concerns

^ until now

> argues for caution.
> I am sure you have more pressing issues, but as your post has already started 
> to cause waves, I would appreciate resolving this sooner rather than later.

It's not the direction I had been thinking in, but Tony Li got there first and 
suggested [1] a change that I think would get the job done. It has the merit of 
being a minimal update to the published text. The change would be,

OLD:
2.1.1.1.  V-Flag and L-Flag

NEW:
2.1.1.1.  V-Flag, L-Flag, and the SID/Index/Label Field

Absent further discussion, I'll plan to open an editorial erratum with that 
proposal; in light of the alleged waves, I will get it done by end of week, 
possibly today. Since I'll be the one opening it, and since it's not completely 
uncontentious, I'll ask one of the other ADs to handle verifying or rejecting 
it.

—John

[1] https://mailarchive.ietf.org/arch/msg/lsr/xIBSCGENJAuPHquywuPvt-oItIE/
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label

[John Scudder]

Hi Hannes,

> On Dec 7, 2023, at 4:38 AM, Hannes Gredler 
>  wrote:
> 
> We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions and I 
> am not aware
> of any questions from implementators around ambiguity.

Thanks for the pointer, I’ll take a look at those, too.

> IMO there is clear enough language to describe proper encoding of the 
> prefix-SID subTLV and
> I am not sure why an "erratum" is required.

I agree that, after reconsidering the text in light of Les’s reply, it’s not a 
technical error (or “bug” as I put it in the subject line). However, offline 
feedback from a couple of other experienced protocol implementors indicates to 
me that I’m not the only one who finds the presentation of the information to 
be unclear [1] and not as helpful as it could be to someone using the document 
as a reference instead of doing an in-depth read-through.

BTW if there’s some nuance to the quotation marks you used around “erratum” I’m 
missing it. Errata are a normal part of our process, and erratum is just the 
singular of errata. [2]

Thanks,

—John

[1] This quote doesn’t quite apply, but it’s a humorous way of illustrating 
that information can be provided without being made available as clearly as it 
could be. 
http://hitchhikerguidetothegalaxy.blogspot.com/2006/04/beware-of-leopard-douglas-adams-quote.html

[2] https://www.rfc-editor.org/errata-definitions/
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label

[John Scudder]

Hi Les,

Thanks for the speedy reply, and I take your point. I do still think an erratum 
is called for, but I think it's editorial or "hold for document update", not 
technical. Now that you've applied the clue bat I think I can compose one. I'll 
do so by and by and you can see what you think.

--John

> On Dec 6, 2023, at 4:25 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> 
> John -
>  
> The meaningful bits of the SID and the size (number of octets) depend upon 
> the flags. As Section 2.1.1.1 states (emphasis added):
>  
> The following settings for V-Flag and L-Flag are valid:
>  
> The V-Flag and L-Flag are set to 0:
> The SID/Index/Label field is a 4-octet index defining the offset in the 
> SID/Label space advertised by this router using the encodings defined in 
> Section 3.1.
>  
> The V-Flag and L-Flag are set to 1:
> The SID/Index/Label field is a 3-octet local label where the 20 rightmost 
> bits are used for encoding the label value.
>  
> Do you still believe some change/clarification is needed?
>  
>Les
>  
> > -Original Message-
> > From: John Scudder 
> > Sent: Wednesday, December 6, 2023 1:13 PM
> > To: stefano.prev...@gmail.com; Les Ginsberg (ginsberg)
> > ; Clarence Filsfils (cfilsfil) ;
> > abashandy.i...@gmail.com; han...@rtbrick.com; DECRAENE Bruno
> > INNOV/NET ; slitkows.i...@gmail.com; Jeff
> > Tantsura ; Peter Psenak (ppsenak)
> > ; Horneffer, Martin ;
> > wim.henderi...@nokia.com; edc.i...@gmail.com; ro...@google.com;
> > milojevici...@gmail.com; s...@ytti.fi
> > Cc: lsr 
> > Subject: Bug in RFC 8667 definition of SID/Index/Label
> > 
> > Hi Authors and Contributors who "should be considered as coauthors”,
> > 
> > Your RFC defines the SID/Index/Label field of the Prefix Segment Identifier
> > (Prefix-SID) Sub-TLV, in Section 2.1, as:
> > 
> >   SID/Index/Label as defined in Section 2.1.1.1.
> > 
> > But when I look at Section 2.1.1.1 I see that it defines "V-Flag and 
> > L-Flag”, not
> > SID/Index/Label at all. It relates to the interpretation of 
> > SID/Index/Label, yes,
> > but it doesn’t define the field.
> > 
> > It seems as though an erratum is needed to provide a useful definition. I 
> > don’t
> > have text to suggest. Can one of you suggest text, and either raise the 
> > erratum
> > yourself, or if you send text, I can raise it? Alternatively, if you can 
> > help me
> > understand how section 2.1.1.1 actually does define this field, I'm all 
> > ears.
> > 
> > Thanks,
> > 
> > --John

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

[Lsr] Bug in RFC 8667 definition of SID/Index/Label

[John Scudder]

Hi Authors and Contributors who "should be considered as coauthors”,

Your RFC defines the SID/Index/Label field of the Prefix Segment Identifier 
(Prefix-SID) Sub-TLV, in Section 2.1, as:

  SID/Index/Label as defined in Section 2.1.1.1.

But when I look at Section 2.1.1.1 I see that it defines "V-Flag and L-Flag”, 
not SID/Index/Label at all. It relates to the interpretation of 
SID/Index/Label, yes, but it doesn’t define the field.

It seems as though an erratum is needed to provide a useful definition. I don’t 
have text to suggest. Can one of you suggest text, and either raise the erratum 
yourself, or if you send text, I can raise it? Alternatively, if you can help 
me understand how section 2.1.1.1 actually does define this field, I'm all ears.

Thanks,

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

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[John Scudder]

Hi Aijun,

I apologize for the length of time it’s taken me to respond to your request. 

Having now taken the time to study the question properly, including a review of 
both drafts in question, the WG adoption call, and the subsequent email, here’s 
my take.

In large part, your position appears to be based on historical precedence — 
your draft was published first. (This is your “follower solution… initiator” in 
the email I’m responding to, as well as the first three “which draft is the 
first” points in your follow-up.) This is true of course. Furthermore, although 
our formal process does not take into account such questions as “who came 
first?” I think it would be safe for me to say that people generally do try to 
do not just what’s required, but what’s right, in terms of acknowledging prior 
work. For this reason, I was a little surprised to see no acknowledgment of the 
contributions of your draft in draft-ppsenak. But I think such an 
acknowledgment — which is a norm, not a requirement — is the most you can 
expect for having published the first draft that covers the same general 
subject area as draft-ppsenak. This might also be a good time to remind you 
that draft-wang-lsr-prefix-unreachable-annoucement-00 includes the statement,

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

I encourage you to review BCP 78 if you haven’t recently.

In short, I’m not persuaded by the first-to-publish argument.

The other major point made by you, and others advocating for the consideration 
of draft-wang as the WG solution and against draft-ppsenak, is that draft-wang 
is said to cover more cases. (This is “cover more scenarios” in your email, as 
well as point five, “cover more scenarios” in your follow-up.) There was some 
spirited debate about whether the draft does so successfully, or not, but I 
don’t want to take a position on that in this email. Rather, what I observe is 
that since these points were made clearly, and repeatedly, in the WG adoption 
email thread as well as at other times previously, it can’t be argued that the 
WG didn’t know that draft-wang claims to address (for example) area partition, 
and that draft-ppsenak explicitly doesn’t. So, this suggests those who 
supported the adoption of draft-ppsenak either implicitly, or explicitly, 
believed that the additional use cases draft-wang claims to address are not 
important. At least, not important to address in this draft, at this time, as 
part of this adopted WG work.

In your follow-up, you also proposed that “which explicit signaling mechanism 
is simpler” should be a criterion (point four). In my experience, this kind of 
question seldom leads to a useful outcome since it’s so subjective. I will say 
however that many of the people who responded to the WG adoption call made it 
clear they had such considerations in mind, so I think there is good reason to 
think the WG has taken this question into account.

I also want to speak to the questions of whether the WG adoption decision was 
too hasty, whether there should be more deliberation in the WG, and whether 
there should have been a separate adoption call for draft-wang, which are 
points you’ve made emails other than the one I’m replying to. Regarding whether 
it was too hasty — as you say in this email, this work has been in progress 
since 2019. The merits of the solutions have been debated extensively. A 
considerable amount of valuable WG meeting time has been devoted to these 
discussions, as well as a great many emails. It’s hard for me to see the WG 
adoption decision as being made without due deliberation — the opposite if 
anything. Regarding whether there should have been an adoption call for 
draft-wang — our process allows considerable latitude to WG chairs in how they 
choose to run these things. In reviewing this adoption call, it seems to me 
that all participants were clear that in practice and regardless of what the 
subject line was, they were really addressing a multi-part question: should the 
WG work on this area? If so, should the base document be draft-ppsenak, or 
draft-wang? These questions received a full airing, as far as I can tell.

As you know, the IETF runs on “rough consensus”. This is true for WG adoptions 
just as for anything else, and it sometimes requires WG chairs to make hard 
decisions to call a consensus where some WG contributors are “in the rough”. 
After reviewing the WG adoption call, drafts, and history, it appears to me 
that the WG chairs have listened to all the positions put forward and 
considered them, and judged the rough consensus to favor the adoption of 
draft-ppsenak. I don’t see sufficient evidence to make me believe I should 
overrule the WG chairs’ judgment.

Finally, I will point out that you have many options still open to you if you 
strongly feel that the scenarios that are not covered by the adopted document 
are crucial. 

Thanks for your patience as I 

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[John Scudder]

Without commenting on the other aspects,

> On Sep 20, 2023, at 3:34 PM, Tony Przygienda  wrote:
> 
> 3. the MTU "largest datagram" needs to be errate'd to something more precise 
> on top.

Generally, errata are not the right way to fix “this is underspecified” kinds 
of problems. The right way is to do a bis or an update. See also 
https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/

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

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[John Scudder]

Tom is right of course, and thank you for pointing it out. (The specific 
section in RFC 2026 to look at is 6.5.1.)

In the meantime, I’ll review the mailing list discussion. However, the most 
desirable outcome would be to settle things at the WG level without further 
escalation.

—John

> On Sep 14, 2023, at 12:25 PM, tom petch  wrote:
> 
> From: Lsr  on behalf of Aijun Wang 
> 
> Sent: 14 September 2023 11:38
> 
> Hi, Acee:
> 
> I admire your efforts for the LSR WG, but for the adoption call of this 
> draft, you have not convinced me, although I gave you large amount of solid 
> facts.
> Then, it's time to let our AD to step in, to make the non-biased judgement, 
> based on our discussions along the adoption call.
> 
> 
> 
> I think that what you have in mind is an appeal, as per RFC2026.
> 
> The first stage therein is to involve the Chairs, and while Acee is one, he 
> is not the only one.
> 
> Have you involved the other Chair, on or off list? That would seem to me to 
> be next step.
> 
> Tom Petch
> 
> 
> We request the WG document be based on the 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5KWnyE3KA$
>  , because it is the first document to initiate the use case, provide the 
> explicit signaling mechanism, and cover more scenarios.
> 
> It’s unreasonable to adopt the follower solution and ignore the initiator. We 
> started and lead the discussions THREE years earlier than the current 
> proposal.
> 
> Aijun Wang
> China Telecom
> 
>> On Sep 8, 2023, at 23:16, Acee Lindem  wrote:
>> 
>> The WG adoption call has completed and there is more than sufficient 
>> support for adoption.
>> What’s more, vendors are implementing and operators are planning of 
>> deploying the extensions.
>> Please republish the draft as draft-ietf-lsr-igp-ureach-prefix-announce-00.
>> 
>> A couple of WG members, while acknowledging the use case, thought that it 
>> would be better satisfied outside of the IGPs.
>> In fact, they both offered other viable alternatives. However, with the 
>> overwhelming support and commitment to implementation
>> and deployment, we are going forward with WG adoption of this document. As 
>> the Co-Chair managing the adoption, I don’t see
>> this optional mechanism as fundamentally changing the IGPs.
>> 
>> There was also quite vehement opposition from the authors of 
>> draft-wang-lsr-prefix-unreachable-annoucement. This draft
>> purports to support the same use case as well as others (the archives can be 
>> consulted for the discussion). Further discussion
>> of this other draft and the use cases it addresses should be in the context 
>> of draft-wang-lsr-prefix-unreachable-annoucement
>> and not the WG draft.
>> 
>> Thanks,
>> Acee
>> 
>>> On Aug 23, 2023, at 3:58 PM, Acee Lindem  wrote:
>>> 
>>> LSR Working Group,
>>> 
>>> This begins the working group adoption call for “IGP Unreachable Prefix 
>>> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
>>> Please indicate your support or objection on this list prior to September 
>>> 7th, 2023.
>>> 
>>> Thanks,
>>> Acee
>> 
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$

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

Re: [Lsr] Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[John Scudder]

Awesome, thanks to both of you. Peter, if you can cut a new version with the 
change, I’ll approve it.

—John

> On Jun 28, 2023, at 3:41 AM, Zaheduzzaman Sarker 
>  wrote:
> 
> 
> 
> On Wed, 28 Jun 2023 at 12:47, Peter Psenak  wrote:
> Hi John,
> 
> please see inline (##PP):
> 
> On 27/06/2023 17:48, John Scudder wrote:
> > Hi Authors,
> > 
> > I don’t think we’ve completely closed on this. Zahed is asking for Section 
> > 3 to be tightened a little bit. The authors haven’t either said “no we 
> > won’t” or proposed text. In hopes of provoking some forward motion, here’s 
> > an attempt of my own, based on my understanding of the conversation so far. 
> > My straw man suggestion is to insert this paragraph at the beginning of 
> > Section 3.1:
> > 
> > In this subsection, we illustrate one use case that motivates this
> > specification: if a specific service can be identified by an IP
> > address, traffic to it can use constraint-based paths computed
> > according to this specification.
> > 
> > Zahed, if this works for you, please ack. If it doesn’t work for you, 
> > please propose text.
> > 
> > Authors, same to you.
> 
> ##PP
> I'm fine with your prposal.
> 
> Thanks Jhon! This works for me. 
> 
> // Zahed 
> 

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

Re: [Lsr] Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[John Scudder]

Hi Authors,

I don’t think we’ve completely closed on this. Zahed is asking for Section 3 to 
be tightened a little bit. The authors haven’t either said “no we won’t” or 
proposed text. In hopes of provoking some forward motion, here’s an attempt of 
my own, based on my understanding of the conversation so far. My straw man 
suggestion is to insert this paragraph at the beginning of Section 3.1:

   In this subsection, we illustrate one use case that motivates this
   specification: if a specific service can be identified by an IP
   address, traffic to it can use constraint-based paths computed
   according to this specification. 

Zahed, if this works for you, please ack. If it doesn’t work for you, please 
propose text.

Authors, same to you.

Also, if you do decide to do another revision, can you fix this nit I noticed 
in Section 5 of version 15? (There’s no need to cut a new version just for this 
change, no doubt the RFC Editor would catch it too.)

OLD:
   Only node that is participating in the Flex-Algorithm is:

   *  Able to compute path for such Flex-Algorithm

   *  Part of the topology for such Flex-Algorithm

NEW:
   Only a node that is participating in a Flex-Algorithm is:

   *  Able to compute a path for such Flex-Algorithm

   *  Part of the topology for such Flex-Algorithm

(Adds the indefinite article in two places, changes definite article to 
indefinite in one place.)

Thanks,

—John

> On Jun 9, 2023, at 11:30 AM, John Scudder  
> wrote:
> 
> 
> Ok. 
> 
> —John
> 
>> On Jun 9, 2023, at 11:28 AM, Zaheduzzaman Sarker 
>>  wrote:
>> 
>> 
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> 
>> 
>> On Thu, 8 Jun 2023 at 15:09, John Scudder  wrote:
>> Hi Zahed,
>> 
>> > On Jun 8, 2023, at 6:42 AM, Zaheduzzaman Sarker 
>> >  wrote:
>> > 
>> > I can help with text if I can understand use case better. Right now that 
>> > is not the case.
>> 
>> Do you understand the use case and intent of the section well enough now 
>> that you’d be able to propose text?
>> 
>> Jhon, I think my latest responses to Peter’s mail should shed lights on what 
>> part is missing in the example description. I think it is better that the 
>> authors take a stab at it, then I will review and amend if needed.
>> 
>> Makes sense?
>> 
>> // Zahed 
>> 
>> 
>> 
>> 
>> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HM2JE8-oV_8v4Inl3lW3zP44k8Mds02JL35t9zRtVIiYXqW0WRekp4sGpHfoAE39uJKvVGD83RqfBcoYppfXRmgjZsKX$
>  

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

Re: [Lsr] Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[John Scudder]

Ok.

—John

On Jun 9, 2023, at 11:28 AM, Zaheduzzaman Sarker  
wrote:



[External Email. Be cautious of content]



On Thu, 8 Jun 2023 at 15:09, John Scudder 
mailto:j...@juniper.net>> wrote:
Hi Zahed,

> On Jun 8, 2023, at 6:42 AM, Zaheduzzaman Sarker 
> mailto:zahed.sarker.i...@gmail.com>> wrote:
>
> I can help with text if I can understand use case better. Right now that is 
> not the case.

Do you understand the use case and intent of the section well enough now that 
you’d be able to propose text?

Jhon, I think my latest responses to Peter’s mail should shed lights on what 
part is missing in the example description. I think it is better that the 
authors take a stab at it, then I will review and amend if needed.

Makes sense?

// Zahed





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

Re: [Lsr] Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[John Scudder]

Hi Zahed,

> On Jun 8, 2023, at 6:42 AM, Zaheduzzaman Sarker  
> wrote:
> 
> I can help with text if I can understand use case better. Right now that is 
> not the case.

Do you understand the use case and intent of the section well enough now that 
you’d be able to propose text?

Thanks,

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

Re: [Lsr] Paul Wouters' No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[John Scudder]

Hi Peter and all,

> On Jun 8, 2023, at 2:43 AM, Peter Psenak  
> wrote:
> 
>> A node MUST participate in a Flex-Algorithm to be:
>> - Able to compute path for such Flex-Algorithm
>> - Part of the topology for such Flex-Algorithm
>> 
>> This is an odd use of MUST.
> 
> what exactly is odd in it?

I don’t know what Paul found odd about it, but now that I’m looking at it 
afresh, I also think it’s odd. My reason is that it’s not expressing a 
requirement, it’s expressing a statement of fact, a natural consequence. An 
analogy would be if we said “if you let go of your coffee cup as you’re lifting 
it, it MUST fall down”. You don’t need a MUST there, gravity doesn’t care about 
your rules. To continue the analogy, a more usual use of MUST would be to 
express an actual requirement on the implementor — “you MUST NOT drink your 
coffee through a straw”.

I haven’t gone and re-checked in the doc to be sure, but as I recall, it’s not 
possible for a node to be part of the topology for a given FA unless it 
participates in the FA, and this would be true whether the quoted MUST were 
there or not.

$0.02,

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

Re: [Lsr] Lars Eggert's No Objection on draft-ietf-lsr-ospf-terminology-08: (with COMMENT)

[John Scudder]

> On May 25, 2023, at 11:53 AM, tom petch  wrote:
> 
> We want to keep these down references and update these documents as well. I 
> don’t know what the DOWNREF registry is.
> 
> 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/downref/__;!!NEt6yMaO-gk!EFkdlgJWZLwuWb0cM-xrtJ9oKP-eu5L8_JvghT4g6MNqsUSHnempPe7RSJ-pKGpZi9vAKMtlGbScww$
> A registry of documents which have been approved by the IESG for use as 
> DOWNREFs in the past and so do not need further approval or a mention in the 
> Last Call notice

Yes. 

In this case the downrefs are approved (IESG meeting just ended) but we will 
not add the docs to the downref registry owing to the somewhat special nature 
of the downref in this case. In any event, it’s sorted now.

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

Re: [Lsr] Lars Eggert's No Objection on draft-ietf-lsr-rfc8920bis-04: (with COMMENT)

[John Scudder]

> On May 25, 2023, at 10:39 AM, Acee Lindem  wrote:
> 
> Please note that RFCs should use US English as opposed British English. See 
> section 3.1 of RFC 7322.

Correct citation, slightly inaccurate summary — either US English or British 
English is OK, but it MUST be all one or all the other, and in case of mixed 
usage inconsistencies will be reconciled in favor of US English spellings.

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

Re: [Lsr] Jim Guichard's No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-11: (with COMMENT)

[John Scudder]

I have an elaboration on one of Jim’s points:

> On May 24, 2023, at 12:23 PM, Jim Guichard via Datatracker  
> wrote:
> 
> - Section 7.1 SRv6 Locator TLV:
> 
>- The text 'Locator continued..' in Figure 5 might be confusing as perhaps
>it is just me but when I initially read it, I thought that multiple
>Locators could be carried in the TLV. This is not the case of
>  course. It would be easier on the eyes if the entire 'Locator' field of
>  Figure 5 were just a single block of 128-bits. Same comment for Figures
>  6, 7, and 8.

I guess an alternative strategy to the perfectly good one Jim proposes, would 
be to clean up the use of the ellipsis (…) and replace the final “continued” 
with “concluded” as in:

OLD:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Locator (128 bits) ...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Locator continued ...   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Locator continued ...   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Locator continued ...   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Locator (128 bits) ...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... Locator continued ...   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... Locator continued ...   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... Locator concluded   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks, Jim, for catching this.

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

[Lsr] John Scudder's Yes on draft-ietf-lsr-ospfv3-srv6-extensions-11: (with COMMENT)

[John Scudder via Datatracker]

John Scudder has entered the following ballot position for
draft-ietf-lsr-ospfv3-srv6-extensions-11: Yes

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



--
COMMENT:
--

I just realized that the document talks about "LSA ID" and as far as I can
tell, this is not a term that is defined in the OSPF document set. If it is a
well-defined term, can you please point me to what RFC defines it? Right now,
it looks to me as though you should be talking about 'Link State ID (Instance
ID)' for consistency with RFC 7770 §2.2.



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

Re: [Lsr] Ballot issued: to Proposed Standard

[John Scudder]

Hi Authors (and cc WG),

I see there were some changes that were agreed during IETF LC. It would be 
great if you could issue a new version incorporating those before IESG 
evaluation; in the meantime, I’ve issued the ballot. I expect this will be on 
the June 8 IESG agenda.

Thanks,

—John

> On May 19, 2023, at 2:41 PM, IESG Secretary  wrote:
> 
> Evaluation for  can be found at
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/__;!!NEt6yMaO-gk!F0QyBDJjlzmxaza-vAigdp0hFEB_h7MyUhimjB6c6iAUyPfne5VItBpV9gE_ext1r8Pqv0OKD2IxiYniIE14CA$
> 
> Last call expired on: 2023-05-16 00:00 PDT
> 
> Needs 9 more YES or NO OBJECTION positions to pass.
> 

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

Re: [Lsr] Warren Kumari's No Objection on draft-ietf-lsr-rfc8919bis-02: (with COMMENT)

[John Scudder]

That seems reasonable.

Les, I encourage you not to wait for the end of IESG review to make the change, 
if you’re going to — maybe it will help someone else even though Warren did 
extra work (sorry Warren, I tried).

—John

On May 18, 2023, at 3:54 PM, Warren Kumari  wrote:





On Thu, May 18, 2023 at 11:35 AM, Les Ginsberg 
mailto:ginsb...@cisco.com>> wrote:

Warren -

Thanx for the thoughtful (and entertaining [] ) review.

I have no objection to adding a forward reference to the "changes" section for 
both this document and draft-ietf-lsr-rfc8920bis. My only concern is whether 
this violates the guideline that the "abstract should be complete in itself".

Yah, that did bother me slightly — but I decided to just ignore the sense of 
disquiet and hope it was just me :-)  Another option would just be to have 
something towards the start of the Introduction saying something similar?

W




Les

-Original Message-
From: Warren Kumari via Datatracker mailto:nore...@ietf.org>> 
Sent: Thursday, May 18, 2023 8:22 AM
To: The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-lsr-rfc8919...@ietf.org; 
lsr-cha...@ietf.org; 
lsr@ietf.org; cho...@chopps.org; 
cho...@chopps.org
Subject: Warren Kumari's No Objection on draft-ietf-lsr-rfc8919bis-02: (with 
COMMENT)

Warren Kumari has entered the following ballot position for 
draft-ietf-lsr-rfc8919bis-02: 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/about/groups/iesg/statements/handling-ballot-
 positions/
for more information about how to handle DISCUSS and COMMENT positions.

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

-- COMMENT:
--

I initially wrote this up as a DISCUSS position, but made it NoObjection 
instead because it didn't strictly fit the DISCUSS criteria -- that said, I
*do* think that it is important and would really appreciate it if you'd 
strongly consider addressing it (it's also IMO a trivial update!).

I reviewed this document on a plane, and had a bunch of comments... but it was
only when I came to ballot that and I saw John Scudder's note of "Note that 
this document is a tightly-scoped update to RFC 8919. Prudent reviewers will 
focus on the diff vs. 8919 [1], and *not* try to do a detailed/full document 
review." - it would have been great to know that before reading the document!

Knowing what has changed in a -bis is really important - it lets the reader 
know if they actually have to bother reading the new document. This information
*does* exist in this document, but it is buried in the RFC equivalent of the 
bottom of a locked filing cabinet stuck in a disused lavatory with a sign on 
the door saying 'Beware of the Leopard.” (Section 9, between Security 
Considerations and References)

Normally, in an "Updates" document we'd say (in the Abstract) something like
"This document updates RFC 8919 by x and y and z". This is somewhat harder to
do in a grammatically correct manner with Obsoletes, but perhaps something 
like: "This document obsoletes RFC 8919; the changes are documented in Section
9"? (I'm planning on balloting the same on the OSPF version of this doc).

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

Re: [Lsr] Last Call Expired:

[John Scudder]

Hi Authors, WG,

Looks like the IETF LC went fine, I’ve issued the ballot for this document. 
Note that the May 25 telechat agenda is already full so I anticipate this will 
be on the June 8 telechat. 

It looks like there were some editorial points raised in the genart review, 
please consider posting a new version to address those as well as any others 
that may be raised by secdir and opsdir. I agree with the genart reviewer that 
it would be nice if a native HTML rendering were available, you can easily fix 
this by submitting the XML source instead of the TXT rendering when you upload 
your next revision, the backend tooling takes care of the rest.

Thanks,

—John

> On May 15, 2023, at 3:14 AM, DraftTracker Mail System 
>  wrote:
> 
> 
> Please DO NOT reply to this email.
> 
> I-D: 
> Datatracker URL: 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/__;!!NEt6yMaO-gk!DSA16NZ3kGMYXz05zdalxEmErHTmdlDvwO-k_d9nv5A9Z4Vy-FMrH9n_n2TtBWIisU9PGbDcHsDxbyAkATTCbQ$
> 
> IETF Last Call has ended, and the state has been changed to
> Waiting for AD Go-Ahead.

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

Re: [Lsr] Genart last call review of draft-ietf-lsr-rfc8919bis-01

[John Scudder]

> On May 3, 2023, at 11:04 AM, Les Ginsberg (ginsberg)  
> wrote:
> 
>> 2) Please reconsider the link to the mailarchive in the RFC. Put it in the
>> shepherd writeup or in the history in the datatracker as a comment (chairs
>> can
>> do this). Otherwise it adds to the list of URLs that we have to keep alive
>> forever.
> 
> [LES:] I am open to whatever the chairs/AD think is appropriate. But very few 
> people actually look at the shepherd writeup or Datatracker history. Having 
> it in the document provides context for those readers who are curious as to 
> why the bis changes were made. I don’t think it would be as effective if it 
> were removed from the document.
> I take your point that the URL may someday become stale - but if it did that 
> would apply to the other locations as well.
> The section in which it appears is informational only - it is not a normative 
> part of the document - so I am inclined to leave it as is.
> But again, happy to follow consensus on this.

Yeah, I don’t see how adding another layer of indirection makes the problem go 
away. Perhaps it would be reasonable, though, to change the reference from a 
bare URL, presented inline, to an Informative reference, to the effect of

[LSR-MAIL] IETF LSR Mailing List Archive, Tue, 15 June 2021 15:25 UTC, 
"[Lsr] Proposed Errata for RFCs 8919/8920”, and follow-up messages.

I don’t know if there is a standard style for this kind of reference, but it 
seems like it might be a cleaner solution. It doesn’t provide one-click access 
to the mailing list thread, but neither do some other references, and it should 
be easy enough for anyone familiar with our mailing list archives or frankly, 
even anyone who knows how to use a search engine. Also, ironically the bare URL 
doesn’t provide one-click access either, because of how it’s line-broken in the 
txt rendering.

Robert, Les, would that approach work for both of you? 

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

Re: [Lsr] AD review of draft-ietf-lsr-ip-flexalgo-09

[John Scudder]

Hi Peter,

All good, I figured it was something like that. Two residual nits —

1. One “datapalne” got left in. I guess you need something to seed version 11 
after all…

2. It looks like this one got omitted:

@@ -579,8 +592,18 @@
receiver.

The metric value in the parent TLV is RECOMMENDED to be set to
-   LSInfinity [RFC2328].  This recommendation only servers for debugging
+   LSInfinity [RFC2328].  This recommendation only serves for debugging
purposes and does not impact the functionality.
+---
+jgs: Thanks for adding the additional explanation. I made a minor editing
+correction in-line, but I also have a slightly more extensive revision to
+suggest:
+
+NEW:
+ This recommendation is provided as a network troubleshooting
+ convenience; if it is not followed the protocol will still
+ function correctly.
+—

Obviously, I don’t insist on the proposed rewrite. But even if you don’t use it 
you presumably should take the s/servers/serves/ proofreading correction.

I’m going to go ahead and request IETF Last Call, but feel free to push a 
revision with corrections if you want.

—John

> On May 2, 2023, at 6:06 AM, Peter Psenak  
> wrote:
> 
> 
> Hi John,
> 
> I apologize for the misses, likely the result of multiple editors
> updating the draft in parallel.
> 
> I also fixed the nits and updated the security sections as you proposed.
> 
> Version 10 has been published.
> 
> thanks,
> Peter
> 
> 
> 
> 
> 
> On 01/05/2023 20:54, John Scudder wrote:
>> Hi Peter (and Shraddha),
>> 
>>> On Apr 28, 2023, at 9:13 AM, Peter Psenak 
>>>  wrote:
>>> 
>>> Shradha and I have worked to address your comments.
>>> The new version of the draft has been published.
>> 
>> Thanks for that. I’ve reviewed the diffs in 09. I’ve attached a short review 
>> of it; there are some minor proofreading changes, but also one place a 
>> substantive edit was overlooked that I’ve flagged in Section 6.2. I also 
>> made a further suggestion on your Security Considerations.
>> 
>> I think one more revision and we will be ready for IETF Last Call.
>> 
>> Thanks,
>> 
>> —John
>> 
>> --- draft-ietf-lsr-ip-flexalgo-09.txt 2023-05-01 13:21:34.0 -0400
>> +++ draft-ietf-lsr-ip-flexalgo-09-jgs-comments.txt2023-05-01 
>> 14:47:16.0 -0400
>> @@ -138,9 +138,9 @@
>> result, traffic for different sessions is destined to a different
>> destination IP address.
>> 
>> -   IP address allocated to the UPF can be associated with an algoritm.
>> +   The IP address allocated to the UPF can be associated with an algorithm.
>> The mobile user traffic is then forwarded along the path based on the
>> -   algorithm specific metric and constraints.  As a result, traffic can
>> +   algorithm-specific metric and constraints.  As a result, traffic can
>> be sent over a path that is optimized for minimal latency or highest
>> bandwidth.  This mechanism is used to achieve SLA (Service Level
>> Agreement) appropriate for a user session.
>> @@ -186,9 +186,9 @@
>> 
>> Advertisement of participation in IP Flex-Algorithm does not impact
>> the router participation signaled for other data-planes.  For
>> -   Example, it is possible that a router participates in a particular
>> -   flex-algo for IP datapalne but does not participate in the same flex-
>> -   algo for SR dataplane.
>> +   example, it is possible that a router participates in a particular
>> +   flex-algo for the IP dataplane but does not participate in the same flex-
>> +   algo for the SR dataplane.
>> 
>> The following sections describe how the IP Flex-Algorithm
>> participation is advertised in IGP protocols.
>> @@ -196,6 +196,11 @@
>>  5.1.  The IS-IS IP Algorithm Sub-TLV
>> 
>> The ISIS [ISO10589] IP Algorithm Sub-TLV is a sub-TLV of the IS-IS
>> +---
>> +jgs: Was it deliberate that you didn't accept the suggestion to
>> +hyphenate "ISIS" above, or an oversight? If deliberate, how come?
>> +If accidental, please change in next rev.
>> +---
>> Router Capability TLV [RFC7981] and has the following format:
>> 
>>  0   1   2   3
>> @@ -302,9 +307,9 @@
>>  6.  Advertising IP Flex-Algorithm Reachability
>> 
>> To be able to associate the prefix with the Flex-Algorithm, the
>> -   existing prefix reachability advertisements can not be used, because
>> +   existing prefix reachability advertisements cannot be used, because
>> they advertise the prefix reachability in default algorithm 

Re: [Lsr] AD review of draft-ietf-lsr-ospfv3-srv6-extensions-09

[John Scudder]

Hi Ketan,

> On May 2, 2023, at 11:46 AM, Ketan Talaulikar  wrote:

[omitting agreed points that don’t need further discussion]

> > @@ -825,6 +988,9 @@
> > one neighbor.  Thus multiple instances of the SRv6 End.X SID and SRv6
> > LAN End.X SID Sub-TLVs MAY be advertised within the E-Router-Link TLV
> > for a single link.
> > +---
> > +jgs: why is the SHOULD above not a MUST?
> > +---
> > 
> > KT> It is an implementation choice based on the use-case. We don't 
> > mandatorily need adjacency SIDs. However, for many common use-cases like 
> > TI-LFA and SR-TE, the adjacency SIDs are required and hence the SHOULD.
> 
> That sounds to me more like ’should’ than ’SHOULD’; as my own rule of thumb I 
> generally think of ’SHOULD’ as ‘MUST… unless’, or to go to the source (RFC 
> 2119):
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>may exist valid reasons in particular circumstances to ignore a
>particular item, but the full implications must be understood and
>carefully weighed before choosing a different course.
> 
> Alternately, you could qualify the SHOULD with some words about under what 
> circumstances it would be OK to disregard, as in 
> 
>Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one
>unique SRv6 End.X SID corresponding to each of its neighbors, unless 
>it is known a priori that [… I’m actually not sure how best to word the
>caveat based on your comment above.]
> 
> I won’t insist on this, but I think it’s worth fixing and if you don’t make 
> changes, I think you’ll likely receive additional questions about it in IESG 
> review.
> 
> KT2> How about we change to the following?
> 
> Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one unique SRv6 
> End.X SID corresponding to each of its neighbors unless features like traffic 
> engineering or Topology-Independent Loop Free Alternate (TI-LFA) that 
> requires it are not in use.

That sounds pretty good. One quibble — as you’ve written it, an imaginative 
reader could come to the conclusion they SHOULD NOT instantiate such an End.X 
SID in the “unless” case, which I think is not the intent. Perhaps,

Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one unique SRv6 
End.X SID corresponding to each of its neighbors, although it MAY omit doing so 
if features like traffic engineering or Topology-Independent Loop Free 
Alternate (TI-LFA) that requires it are not in use.

(Replaced “unless” with ", although it MAY omit doing so if”)

> > @@ -887,6 +1053,9 @@
> >  +-+-+-+-+-+-+-+-+
> >  |B|S|P| Reserved|
> >  +-+-+-+-+-+-+-+-+
> > +---
> > +jgs: this should have a registry
> > +---
> > 
> > KT> Agree. In hindsight, we could have shared this between ISIS and OSPFv3. 
> > I missed this as the ISIS spec was working through the reviews. I wonder 
> > whether it is OK to point to ISIS registry or if we define one for OSPFv3.
> 
> I think this is a question for the WG; I’m OK with either outcome. (Also for 
> the later instance.)
> 
> KT2> I will wait to hear if anyone from the WG has a preference/suggestion, 
> if not, I will introduce a new flags registry on the same lines as done by 
> RF9352 for ISIS but under OSPFv3 parameter.

That sounds fine.

> FWIW, we have not defined registries for such flags previously for 
> RFC8665/6/7 related to SR-MPLS.

Your point is that those drafts create flags fields but don’t establish 
registries for the unused flags? Sure, and if we didn’t create registries here 
it wouldn’t be the end of the world, but I think it’s a good practice (dare I 
say, a best practice).

I encourage you to push a new version with the agreed changes (e.g., the small 
update to the SHOULD language quoted above) and then I’ll request IETF Last 
Call. I don’t think the registry stuff has to happen before IETF LC, but if we 
can take care of it before it goes to the IESG telechat that would be good.

Thanks,

—John

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

[Lsr] Duplication of TLVs [was: Re: AD review of draft-ietf-lsr-ip-flexalgo-08]

[John Scudder]

Hi Acee,

Yeah, TBH I probably wouldn’t have flagged it as a problem if the dup case 
hadn’t been covered at all — but having covered it, I found some bugs in the 
text. No good deed goes unpunished? I’m sure others in the WG can comment 
better than I as to why it was seen as necessary to cover such cases — whether 
it reflects actual experience in the field, or some past reviewer complaining, 
or some past author being especially diligent.

I think in general it’s a good thing to try to be as specific as we can about 
what kind of inputs are, and aren’t, allowed and how to deal with unexpected 
ones, so it’s basically a positive and I would probably not want to tear the 
text out now that the work has been done. But you make a good point that it’s 
sort of nuts to ask every document going forward to have similar language. 
Should there be a short spec (or set of specs) to update the respective base 
documents, so we can do this once and be done?

Thanks,

—John

> On Apr 28, 2023, at 11:16 AM, Acee Lindem  wrote:
> 
> Hi John,
> 
> All your comments regarding duplication of TLVs got me thinking.  We have 
> covered this in recent RFCs in a more generalized manner. For example, see 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc7684/__;!!NEt6yMaO-gk!E_W7f-scmqTyFPdlBqNfV8awLMiY664KyFwdFTj7PS_jvPbWGnkiSdQjDQ3WmRmqvUBhLdMjNSS3DaM$
>   and search for “same”. However, handling this general case of duplicate 
> information isn’t completely addressed in the base RFCs (at least not for 
> OSPF with which I’m infinitely more familiar with than IS-IS). For example, 
> duplicate links in router-LSAs is not covered in RFC 2328. And, with OSPFv3 
> (RFC 5340) where the LSA ID is decoupled from the advertised prefix or router 
> link, it is not covered in the base documents. It was just assumed that no 
> rationale implementations wouldn’t do this… I’m not sure if we need a 
> document to fully explain this but this document shouldn’t be burdened with 
> this specification.
> 
> Peter can comment for IS-IS as to whether this duplication is addressed in 
> IS-IS specifications.
> 
> Thanks,
> Acee
> 
>> On Apr 28, 2023, at 9:13 AM, Peter Psenak 
>>  wrote:
>> 
>> Hi John,
>> 
>> Shradha and I have worked to address your comments.
>> The new version of the draft has been published.
>> 
>> thanks,
>> Peter
>> 
>> On 20/04/2023 02:27, John Scudder wrote:
>>> Hi Authors, WG,
>>> Thanks for this spec and for your patience as it waited for me to review it.
>>> I’ve supplied my questions and comments in the form of an edited copy of 
>>> the draft. Minor editorial suggestions I’ve made in place without further 
>>> comment, more substantive questions and comments are done in-line and 
>>> prefixed with “jgs:”. You can use your favorite diff tool to review them; 
>>> I’ve attached the iddiff output for your convenience if you’d like to use 
>>> it. I’ve also pasted a traditional diff below in case you want to use it 
>>> for in-line reply.
>>> Thanks,
>>> —John
>>> --- draft-ietf-lsr-ip-flexalgo-08.txt   2023-04-19 19:07:41.0 -0400
>>> +++ draft-ietf-lsr-ip-flexalgo-08-jgs-comments.txt  2023-04-19 
>>> 20:24:36.0 -0400
>>> @@ -97,6 +97,10 @@
>>> 1.  Introduction
>>>An IGP Flex-Algorithm as specified in [I-D.ietf-lsr-flex-algo]
>>> +---
>>> +jgs: All references to [I-D.ietf-lsr-flex-algo] should be updated to
>>> +reference [RFC9350].
>>> +---
>>>computes a constraint-based path to:
>>>*  All Flex-Algorithm specific Prefix Segment Identifiers (SIDs)
>>> @@ -104,7 +108,7 @@
>>>*  All Flex-Algorithm specific SRv6 Locators [RFC8986].
>>> -   Therefore, Flex-Algorithm cannot be deployed in the absence of SR and
>>> +   Therefore, Flex-Algorithm cannot be deployed in the absence of SR or
>>>SRv6.
>>> @@ -128,7 +132,14 @@
>>> 3.  Use Case Example
>>>Mobile networks are becoming more and more IP centric.  Each end-user
>>> -   session from a gNB (gNodeB) can be destined to a specific UPFs (User
>>> +   session from a gNB (gNodeB) can be destined to a specific UPF (User
>>> +---
>>> +jgs: thanks for expanding gNB, but if you think about it I think you'll
>>> +realize that "gNodeB" isn't any more informative to a reader who isn't
>>> +already conversant with 3GPP terminology. Please either supply a reference,
>>> +rewrite this section in more accessible terms, or remove the section, your
>>> +choice.
>>> +---
>>>Plane Function) based on the session requ

Re: [Lsr] AD review of draft-ietf-lsr-ospfv3-srv6-extensions-09

[John Scudder]

Hi Ketan,

Thanks for your careful answers.

> On Apr 27, 2023, at 12:35 PM, Ketan Talaulikar  wrote:

…

> @@ -245,6 +260,12 @@
> 
> The SRv6 Capabilities TLV may contain optional Sub-TLVs.  No Sub-TLVs
> are defined in this specification.
> +---
> +jgs: Thank you for setting up registry creation for this flags field.
> +However, I noticed that the registry says the O-flag has value 0x0001, 
> +whereas in the diagram you show it as having value 0x4000. Please 
> +correct one or the other, to be consistent.
> +---
> 
> KT> Thanks for catching that. We've switched from using "value" to using "bit 
> positions" in the IANA section.

Thanks. Specifying these as hex “values” rather than bit positions triggered my 
inner pedant since they are *not* values per se… but I noticed that other OSPF 
RFCs do the same thing so I figured the ship has sailed and they’re 
sufficiently clear in context. But I’m happy with ‘bit position’. That having 
been said, in Section 13.3 (and Section 6) you still have a hex value,

   *  Value 0x80: AC-bit: Refer to Section 6 of this document.

Should this be made consistent?

> +---
> +jgs: Congratulations on getting 42, the best number, assigned for your
> +code point. :-)
> +---
> 
> KT> I think I am missing something significant with this number - perhaps you 
> will share what that is? ;-)

This is a pop-culture reference to Douglas Adams’ Hitchhiker’s Guide to the 
Galaxy series, wherein 42 is the answer to “life, the universe, and 
everything.” Too many references to cite, including of course the novels 
themselves, but here’s one: 
https://www.theguardian.com/books/2011/feb/03/douglas-adams-42-hitchhiker

> KT> Fixed the ordering of fields. We don't want to call this as a reserved 
> field since even though we don't yet have flags identified we know they would 
> be needed at some point. We have these SRv6 SID flags that are the same in 
> ISIS and BGP as well. Possibly we can share the same registry - though not 
> sure. Best to do this down the line when we start using the flags.

Normally I’d be more insistent on creating the empty registry, but if you think 
it might be shareable, I guess that could be a reason to defer. Is this really 
not a call we can make now? Will it really be more obvious later? 

> @@ -825,6 +988,9 @@
> one neighbor.  Thus multiple instances of the SRv6 End.X SID and SRv6
> LAN End.X SID Sub-TLVs MAY be advertised within the E-Router-Link TLV
> for a single link.
> +---
> +jgs: why is the SHOULD above not a MUST?
> +---
> 
> KT> It is an implementation choice based on the use-case. We don't 
> mandatorily need adjacency SIDs. However, for many common use-cases like 
> TI-LFA and SR-TE, the adjacency SIDs are required and hence the SHOULD.

That sounds to me more like ’should’ than ’SHOULD’; as my own rule of thumb I 
generally think of ’SHOULD’ as ‘MUST… unless’, or to go to the source (RFC 
2119):

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Alternately, you could qualify the SHOULD with some words about under what 
circumstances it would be OK to disregard, as in 

   Every SRv6 enabled OSPFv3 router SHOULD instantiate at least one
   unique SRv6 End.X SID corresponding to each of its neighbors, unless 
   it is known a priori that [… I’m actually not sure how best to word the
   caveat based on your comment above.]

I won’t insist on this, but I think it’s worth fixing and if you don’t make 
changes, I think you’ll likely receive additional questions about it in IESG 
review.

> @@ -887,6 +1053,9 @@
>  +-+-+-+-+-+-+-+-+
>  |B|S|P| Reserved|
>  +-+-+-+-+-+-+-+-+
> +---
> +jgs: this should have a registry
> +---
> 
> KT> Agree. In hindsight, we could have shared this between ISIS and OSPFv3. I 
> missed this as the ISIS spec was working through the reviews. I wonder 
> whether it is OK to point to ISIS registry or if we define one for OSPFv3.

I think this is a question for the WG; I’m OK with either outcome. (Also for 
the later instance.)

—John

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

Re: [Lsr] AD review of draft-ietf-lsr-ip-flexalgo-08

[John Scudder]

On Apr 20, 2023, at 1:24 PM, Peter Psenak  wrote:
> 
> Hi John,
> 
> I usually push txt version and give XML only to RFC Editors.

I used to do that too. Also for no particular reason, just habit I guess.

> No particular reason, I can upload XML next time.

Thanks! It’s not a huge difference for me, but it is a difference and I assume 
if I prefer the HTML rendering, some others do as well. (Come to think of it I 
bet the HTML rendering is better for visually disabled people — I bet reader 
software is better with paragraph-mode text than line-mode, and it’s certainly 
easier to scale cleanly.)

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

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

[John Scudder]

Hi Tom,

<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml>
IS-IS TLV 
Codepoints<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml>
iana.org<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml>
[apple-touch-icon.png]<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml>

—John

On Apr 20, 2023, at 12:04 PM, tom petch  wrote:



From: John Scudder 
Sent: 20 April 2023 13:45
To: tom petch
Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] Last Call:  (IS-IS 
Application-Specific Link Attributes) to Proposed Standard

Hi Tom,

Thanks for catching this, sorry I missed it in my review. The registry is now 
named "IS-IS Sub-TLVs for Application-Specific SRLG TLV”, so,

OLD:
7.5.  Sub-TLVs for TLV 238 Registry

  IANA has created a new registry titled "Sub-TLVs for TLV 238" under
  the "IS-IS TLV Codepoints" registry to control the assignment of sub-

NEW:
7.5.  Sub-TLVs for IS-IS Sub-TLVs for Application-Specific SRLG TLV Registry

  IANA has created a new registry titled "IS-IS Sub-TLVs for 
Application-Specific SRLG TLV" under
  the "IS-IS TLV Codepoints" registry to control the assignment of sub-

Authors, can you please make the revision when you publish the next version?


John

I had not got that far:-(  My comment was meant to be that there is nothing I 
can see on the IANA website with the title
IS-IS TLV Codepoints"
a reference which appears in several places.  I think that there are other 
inconsistencies but decided to work top down and see what I came up with and 
this was at the top.

Tom Petch
I think hat


Thanks,

—John

On Apr 20, 2023, at 6:41 AM, tom petch  wrote:


From: Lsr  on behalf of The IESG 
Sent: 19 April 2023 21:01
To: IETF-Announce
Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; j...@juniper.net; 
lsr-cha...@ietf.org; lsr@ietf.org
Subject: [Lsr] Last Call:  (IS-IS 
Application-Specific Link Attributes) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'IS-IS Application-Specific Link
Attributes'
 as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2023-05-03. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.


"   IANA has created a new registry titled "Sub-TLVs for TLV 238" under
 the "IS-IS TLV Codepoints" registry to control the assignment
"

When I go to the IANA website I see lots of  I S - I S under which it might be 
but not that particular one.  What is it by another name?

Tom Petch

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 of these link
 attributes, the current advertisements do not support application-
 specific values for a given attribute, nor do they support indication
 of which applications are using the advertised value for a given
 link.  This document introduces new link attribute advertisements
 that address both of these shortcomings.

 This document obsoletes RFC 8919.




The file can be obtained via
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8919bis/__;!!NEt6yMaO-gk!H--jQXaGBKyUh1Ji8-0I02I_lK5h848xPJFQqyeHphMG17NBjPpu__ABg4byU4qG2GbHgH-66efP5g$



No IPR declarations have been submitted directly on this I-D.





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

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

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

[John Scudder]

Hi Les,

> On Apr 20, 2023, at 10:43 AM, Les Ginsberg (ginsberg)  
> wrote:
> 
> Also to John - if you have provided a review of the bis draft (as you suggest 
> below) I don’t seem to have seen it.
> Did you send it to the list?? Or are you referring to your comments from last 
> year which resulted in the bis draft being created?

I did review the bis, in the sense of, I looked it over. My review, in toto, 
was “LGTM, ship it”,[1] so I simply sent it to IETF Last Call. Sorry for the 
ambiguity, I guess in the future when I have nothing substantive to say I 
should send a “this page intentionally left blank other than this notice” AD 
Review email.[2]

—John

[1] So what I meant by my comment was “I should have caught that while looking 
over the doc”. I think the reason I missed it was, I focused on the diff, and 
the registry name wasn’t part of the diff… but since the registry name changed 
since publication of 8919, it SHOULD have been part of the diff.
[2] Not snark, this conversation demonstrates that I really should do that. 
Every time I try to take a shortcut, I get brought up short. Every. Single. 
Time.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD review of draft-ietf-lsr-ip-flexalgo-08

[John Scudder]

[adding individual cc for authors to work around bounce issues]

One additional request — when you post your next revision, unless you have some 
specific reason NOT to upload the XML, please do that? It appears that for 
version 08 you only uploaded the txt rendering, which means there’s no native 
HTML rendering available. I often prefer to review the native HTML version 
instead of the monospaced, hard wrapped, fake-teletype txt format.

If there’s some impediment to your uploading the XML, I’d be curious to know 
what it is, so we can potentially address it in the tooling — feel free to 
unicast me.

Thanks,

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

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

[John Scudder]

Hi Tom,

Thanks for catching this, sorry I missed it in my review. The registry is now 
named "IS-IS Sub-TLVs for Application-Specific SRLG TLV”, so,

OLD:
7.5.  Sub-TLVs for TLV 238 Registry

   IANA has created a new registry titled "Sub-TLVs for TLV 238" under
   the "IS-IS TLV Codepoints" registry to control the assignment of sub-

NEW:
7.5.  Sub-TLVs for IS-IS Sub-TLVs for Application-Specific SRLG TLV Registry

   IANA has created a new registry titled "IS-IS Sub-TLVs for 
Application-Specific SRLG TLV" under
   the "IS-IS TLV Codepoints" registry to control the assignment of sub-

Authors, can you please make the revision when you publish the next version?

Thanks,

—John

> On Apr 20, 2023, at 6:41 AM, tom petch  wrote:
> 
> 
> From: Lsr  on behalf of The IESG 
> 
> Sent: 19 April 2023 21:01
> To: IETF-Announce
> Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; j...@juniper.net; 
> lsr-cha...@ietf.org; lsr@ietf.org
> Subject: [Lsr] Last Call:  (IS-IS 
> Application-Specific Link Attributes) to Proposed Standard
> The IESG has received a request from the Link State Routing WG (lsr) to
> consider the following document: - 'IS-IS Application-Specific Link
> Attributes'
>   as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2023-05-03. Exceptionally, comments may
> be sent to i...@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> 
> "   IANA has created a new registry titled "Sub-TLVs for TLV 238" under
>   the "IS-IS TLV Codepoints" registry to control the assignment
> "
> 
> When I go to the IANA website I see lots of  I S - I S under which it might 
> be but not that particular one.  What is it by another name?
> 
> Tom Petch
> 
> 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 of these link
>   attributes, the current advertisements do not support application-
>   specific values for a given attribute, nor do they support indication
>   of which applications are using the advertised value for a given
>   link.  This document introduces new link attribute advertisements
>   that address both of these shortcomings.
> 
>   This document obsoletes RFC 8919.
> 
> 
> 
> 
> The file can be obtained via
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8919bis/__;!!NEt6yMaO-gk!H--jQXaGBKyUh1Ji8-0I02I_lK5h848xPJFQqyeHphMG17NBjPpu__ABg4byU4qG2GbHgH-66efP5g$
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!H--jQXaGBKyUh1Ji8-0I02I_lK5h848xPJFQqyeHphMG17NBjPpu__ABg4byU4qG2GbHgH8CiymDMA$

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

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7406)

[John Scudder]

Verified. Also, note taken that it’s important to do a complete review of the 
updates to the document before signing off on AUTH48 — the RFC Editor, 
wonderful though they are, are not subject matter experts and they can and do 
occasionally make these kinds of mistakes through no fault of their own.

—John

> On Apr 13, 2023, at 9:37 AM, Acee Lindem  wrote:
> 
> 
> + John for approval.
> 
>> On Apr 13, 2023, at 7:49 AM, Ketan Talaulikar  wrote:
>> 
>> +1 - please accept this Errata as editorial
>> 
>> Thanks,
>> Ketan
>> 
>> 
>> On Tue, Mar 28, 2023 at 8:28 PM Acee Lindem  wrote:
>> That explains it and it is actually the right thing to do from the 
>> perspective of the IETF document process.
>> 
>> https://urldefense.com/v3/__https://www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!HMnNdjFA6EA97zRaVooR6nIgNuUrWtqaSqLLJR_lAKyCPDRJFT0pA9ZBhaeQ2TeOzouLy4yePgqL4gg$
>> 
>> Note that LSP is not asterisked as being well known and “Label Switched 
>> Path” is the first alternative. It should always be expanded on first use.
>> 
>> The Editorial Errata should be accepted. This is something we should watch 
>> for in documents specifying IS-IS.
>> 
>> Thanks,
>> Acee
>> 
>>> On Mar 27, 2023, at 11:58 PM, Robert Raszuk  wrote:
>>> 
>>> Hi Barry,
>>> 
>>> Looks like RFC Editor expanded the "LSP" abbreviation as version -26 (last 
>>> before publication) says this:
>>> 
>>> The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number. IS-
>>> IS router MAY advertise more than one IS-IS FAD Sub-TLV for a given
>>> Flexible Algorithm (see Section 6).
>>> 
>>> 
>>> Rgs,
>>> R.
>>> 
>>> 
>>> On Mon, Mar 27, 2023 at 8:34 PM RFC Errata System 
>>>  wrote:
>>> The following errata report has been submitted for RFC9350,
>>> "IGP Flexible Algorithm".
>>> 
>>> --
>>> You may review the report below and at:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7406__;!!NEt6yMaO-gk!HMnNdjFA6EA97zRaVooR6nIgNuUrWtqaSqLLJR_lAKyCPDRJFT0pA9ZBhaeQ2TeOzouLy4yeyr6UyXE$
>>> 
>>> --
>>> Type: Editorial
>>> Reported by: Barry Friedman 
>>> 
>>> Section: 5.1
>>> 
>>> Original Text
>>> -
>>> The IS-IS FAD sub-TLV MAY be advertised in a
>>> Label Switched Path (LSP) of any number.
>>> 
>>> Corrected Text
>>> --
>>> The IS-IS FAD sub-TLV MAY be advertised in a
>>> Link State PDU (LSP) of any number.
>>> 
>>> Notes
>>> -
>>> I assume LSP is meant to refer to the PDU carrying the FAD, not a Label 
>>> Switched Path.
>>> 
>>> Instructions:
>>> -
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necessary.
>>> 
>>> --
>>> RFC9350 (draft-ietf-lsr-flex-algo-26)
>>> --
>>> Title   : IGP Flexible Algorithm
>>> Publication Date: February 2023
>>> Author(s)   : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, 
>>> A. Gulko
>>> Category: PROPOSED STANDARD
>>> Source  : Link State Routing
>>> Area: Routing
>>> Stream  : IETF
>>> Verifying Party : IESG
>>> 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HMnNdjFA6EA97zRaVooR6nIgNuUrWtqaSqLLJR_lAKyCPDRJFT0pA9ZBhaeQ2TeOzouLy4yeS-597yQ$
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HMnNdjFA6EA97zRaVooR6nIgNuUrWtqaSqLLJR_lAKyCPDRJFT0pA9ZBhaeQ2TeOzouLy4yeS-597yQ$
>> 
> 

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

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)

[John Scudder]

Hi Les,

Thanks for the input. I’ve verified the erratum as editorial/HFDU already under 
the doctrine of “doesn’t hurt, might help”. Apart from other considerations, 
the existence of the erratum serves as further documentation that the text in 
question does *not* mean the protocol (IS-IS).

—John

> On Mar 6, 2023, at 11:01 AM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> 
> [External Email. Be cautious of content]
> 
> 
> (At the risks of giving this issue more attention than it merits…)
>  
> My interpretation of the filed Errata is that the submitter incorrectly 
> thought that the text should be referring to the protocol (IS-IS) and that 
> the text had been inadvertently truncated. Consider that the “Note” says:
>  
> “Incorrect name of protocol (IS instead IS-IS).”
>  
> We all agree that the text is in fact referring to a router (an IS) that 
> supports the IS-IS protocol. The text is therefore correct as it stands.
>  
> Acee has pointed out further that we are not required to expand this 
> particular acronym on first use – therefore there really is no reason to 
> accept this Errata (IMHO).
>  
> John – whatever you want to do here is fine – but I think your statement “the 
> lack of expansion confused at least one person” is being overly generous in 
> this case.
>  
> Les
>  
> From: Lsr  On Behalf Of John Scudder
> Sent: Monday, March 6, 2023 4:57 AM
> To: Acee Lindem 
> Cc: Peter Psenak (ppsenak) ; Tony Li ; 
> RFC Errata System ; nmal...@protokols.ru; Shraddha 
> Hegde ; Clarence Filsfils (cfilsfil) 
> ; Ketan Talaulikar ; 
> arkadiy.gu...@edwardjones.com; lsr 
> Subject: Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)
>  
> “Hold For Document Update” is exactly for the purpose [1] of making nominal 
> but inessential improvements. This one seems roughly on the level of “trivial 
> grammar correction” (item 4 of [1]) which is in-scope for HFDU, and 
> apparently the lack of expansion confused at least one person, so I’m 
> inclined to verify as HFDU with Tony’s text, unless there’s a strong case not 
> to. 
>  
> —John
>  
> [1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
> 
> 
> On Mar 6, 2023, at 7:39 AM, Acee Lindem  wrote:
> 
> 
> Hi Peter,
> 
> I agree it is not an errata. We really don’t want to set precedence of having 
> published RFC text nominally improved via Errata. I’ve copied John for Errata 
> resolution.
> 
> Thanks,
> Acee
> 
> 
> On Mar 6, 2023, at 4:14 AM, Peter Psenak  wrote:
>  
> Acee,
>  
> if you ask me, I would not do anything. "IS" is correct in the text and it's 
> well known.
>  
> my 2c,
> Peter
>  
>  
> On 05/03/2023 14:32, Acee Lindem wrote:
> Hi Tony,
> On Mar 4, 2023, at 4:42 PM, Tony Li  wrote:
>  
>  
> Hi all,
>  
> IMHO, this erratum is correct, but the proposed fix is incorrect.
>  
> In this case, the original text seeks to use ‘IS’ as an abbreviation for 
> ‘Intermediate System’ (i.e., router). Thus, a better fix would be:
>  
> One of the limitations of IS-IS [ISO10589] is that the length of a
> TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
> TLV, there are a number of sub-sub-TLVs (defined below) that are
> supported.  For a given Flex-Algorithm, it is possible that the total
> number of octets required to completely define a FAD exceeds the
> maximum length supported by a single FAD sub-TLV.  In such cases, the
> FAD MAY be split into multiple such sub-TLVs, and the content of the
> multiple FAD sub-TLVs are combined to provide a complete FAD for the
> Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
> Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
> Algorithm from a given IS (Intermediate System).
>  
> Please note the recurrence of the use of ‘IS’ in the next sentence and again 
> in the next paragraph.
> Strictly speaking, the expansion is not required as IS in the context of 
> IS-IS is “well-known” as 
> perhttps://urldefense.com/v3/__https://www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZdVtLolo$
>  . However, I agree that expansion on first use is an improvement.
> Thanks,
> Acee
>  
> Regards,
> Tony
>  
>  
> On Mar 4, 2023, at 1:28 PM, RFC Errata System  
> wrote:
>  
> The following errata report has been submitted for RFC9350,
> "IGP Flexible Algorithm".
>  
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7376__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)

[John Scudder]

“Hold For Document Update” is exactly for the purpose [1] of making nominal but 
inessential improvements. This one seems roughly on the level of “trivial 
grammar correction” (item 4 of [1]) which is in-scope for HFDU, and apparently 
the lack of expansion confused at least one person, so I’m inclined to verify 
as HFDU with Tony’s text, unless there’s a strong case not to.

—John

[1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/

On Mar 6, 2023, at 7:39 AM, Acee Lindem  wrote:


Hi Peter,

I agree it is not an errata. We really don’t want to set precedence of having 
published RFC text nominally improved via Errata. I’ve copied John for Errata 
resolution.

Thanks,
Acee

On Mar 6, 2023, at 4:14 AM, Peter Psenak  wrote:

Acee,

if you ask me, I would not do anything. "IS" is correct in the text and it's 
well known.

my 2c,
Peter


On 05/03/2023 14:32, Acee Lindem wrote:
Hi Tony,
On Mar 4, 2023, at 4:42 PM, Tony Li  wrote:


Hi all,

IMHO, this erratum is correct, but the proposed fix is incorrect.

In this case, the original text seeks to use ‘IS’ as an abbreviation for 
‘Intermediate System’ (i.e., router). Thus, a better fix would be:

One of the limitations of IS-IS [ISO10589] is that the length of a
TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
TLV, there are a number of sub-sub-TLVs (defined below) that are
supported.  For a given Flex-Algorithm, it is possible that the total
number of octets required to completely define a FAD exceeds the
maximum length supported by a single FAD sub-TLV.  In such cases, the
FAD MAY be split into multiple such sub-TLVs, and the content of the
multiple FAD sub-TLVs are combined to provide a complete FAD for the
Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
Algorithm from a given IS (Intermediate System).

Please note the recurrence of the use of ‘IS’ in the next sentence and again in 
the next paragraph.
Strictly speaking, the expansion is not required as IS in the context of IS-IS 
is “well-known” as per 
https://urldefense.com/v3/__https://www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZdVtLolo$
 . However, I agree that expansion on first use is an improvement.
Thanks,
Acee

Regards,
Tony


On Mar 4, 2023, at 1:28 PM, RFC Errata System  wrote:

The following errata report has been submitted for RFC9350,
"IGP Flexible Algorithm".

--
You may review the report below and at:
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7376__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZBstDDr4$

--
Type: Editorial
Reported by: Nikolai Malykh 

Section: 6

Original Text
-
One of the limitations of IS-IS [ISO10589] is that the length of a
TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
TLV, there are a number of sub-sub-TLVs (defined below) that are
supported.  For a given Flex-Algorithm, it is possible that the total
number of octets required to completely define a FAD exceeds the
maximum length supported by a single FAD sub-TLV.  In such cases, the
FAD MAY be split into multiple such sub-TLVs, and the content of the
multiple FAD sub-TLVs are combined to provide a complete FAD for the
Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
Algorithm from a given IS.

Corrected Text
--
One of the limitations of IS-IS [ISO10589] is that the length of a
TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
TLV, there are a number of sub-sub-TLVs (defined below) that are
supported.  For a given Flex-Algorithm, it is possible that the total
number of octets required to completely define a FAD exceeds the
maximum length supported by a single FAD sub-TLV.  In such cases, the
FAD MAY be split into multiple such sub-TLVs, and the content of the
multiple FAD sub-TLVs are combined to provide a complete FAD for the
Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
Algorithm from a given IS-IS.

Notes
-
Incorrect name of protocol (IS instead IS-IS).

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC9350 (draft-ietf-lsr-flex-algo-26)
--
Title   : IGP Flexible Algorithm
Publication Date: February 2023
Author(s)   : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. 
Gulko
Category 

Re: [Lsr] Flags from draft-ietf-lsr-isis-srv6-extensions-19 and draft-ietf-lsr-ospfv3-srv6-extensions-08

[John Scudder]

> On Dec 15, 2022, at 8:45 AM, Acee Lindem  wrote:
> 
> Section 2 defines the flags field in the OSPFv3 SR capabilities TLV. I don’t 
> see an IANA registry defined for these flags.

Yes exactly. So, note to whoever does have the pen, please add that registry. 
(And I dropped the srv6-extensions author expansion from the cc.)

Thanks,

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

Re: [Lsr] Flags from draft-ietf-lsr-isis-srv6-extensions-19 and draft-ietf-lsr-ospfv3-srv6-extensions-08

[John Scudder]

Thanks, Peter.

Doesn’t this mean that the OSPFv3 draft needs to create its own registry for 
the flags, then?

—John

P.S.: I see 8 instances of “ISIS” in version 19 of isis-srv6, but maybe you’re 
looking at the RFCEd version.

> On Dec 15, 2022, at 6:29 AM, Peter Psenak  wrote:
> 
> John,
> 
> On 14/12/2022 22:59, John Scudder wrote:
>> Hi Authors, WG,
>> 
>> As part of my review of draft-ietf-idr-bgpls-srv6-ext-12 I was looking at 
>> these documents and came up with a few comments that would otherwise become 
>> part of my AD review for ospfv3-srv6-extensions, so I thought I’d share them 
>> now.
>> 
>> draft-ietf-lsr-isis-srv6-extensions-19 is currently in RFC-EDITOR state so 
>> it may or may not be reasonable to make any changes, but I’m going to 
>> mention them below anyway. I’m sorry I didn’t notice this before we got 
>> through IESG review.
>> 
>> draft-ietf-lsr-ospfv3-srv6-extensions-08 Section 2 defines the flags field 
>> in a way that (as per usual) conveniently happens to be identical to how the 
>> IS-IS document defines it. However, I don’t see any language in 
>> draft-ietf-lsr-ospfv3-srv6-extensions-08 saying that the IANA Registry from 
>> the IS-IS draft MUST be used for the assignment of flags for the OSPFv3 
>> field. Shouldn’t you say this?
> 
> we kept the ISIS and OSPF SRv6 capabilities separate. One day they may
> diverge.
> 
>> 
>> Also, the registry should probably refer back to both (all three, if we 
>> include the BGP-LS one, but that's another story) specs that make 
>> assignments from it, shouldn’t it? So where the IS-IS document says,
>> 
>> "This document requests a new IANA registry be created under the IS-IS TLV 
>> Codepoints registry to control the assignment of bits 0 to 15 in the Flags 
>> field of the ISIS SRv6 Capabilities sub-TLV specified in this document 
>> (Section 2):"
>> 
>> Maybe it should add something like “… as well as the corresponding field 
>> defined in Section 2 of draft-ietf-lsr-ospfv3-srv6-extensions-08.” (And 
>> maybe “and Section 3.1 of draft-ietf-idr-bgpls-srv6-ext-12”?). It might be 
>> easier to drop that change into the IS-IS draft now, before it exits 
>> RFC-EDITOR state (if agreed of course) but we could also do it by patching 
>> the registry text in the OSPFv3 (and BGP-LS?) draft’s IANA section.
>> 
>> Also, a minor point: draft-ietf-lsr-isis-srv6-extensions-19 uses 
>> inconsistent hyphenation for the protocol name — “ISIS” or “IS-IS”. My own 
>> preference is “IS-IS” as both more accurate and not as subject to conflation 
>> with other uses of “Isis”, but anyway please pick one and stick with it? I 
>> guess the RFC Editor will take care of this, but I apologize for not 
>> catching it during IESG review.
> 
> I see one occurrence of "ISIS" in the latest version of the draft, I
> will ask editors to fix that.
> 
>> 
>> (This also leads me to wonder why we even put this registry, that’s shared 
>> by two (three?) protocols, under the IS-IS TLV Codepoints registry instead 
>> of under Interior Gateway Protocol (IGP) Parameters, but given the 
>> publication stage we’re at it may not be worth trying to change that.)
> 
> no, the flags are kept independent in each protocol.
> 
> thanks,
> Peter
>> 
>> Thanks,
>> 
>> —John

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

[Lsr] Flags from draft-ietf-lsr-isis-srv6-extensions-19 and draft-ietf-lsr-ospfv3-srv6-extensions-08

[John Scudder]

Hi Authors, WG,

As part of my review of draft-ietf-idr-bgpls-srv6-ext-12 I was looking at these 
documents and came up with a few comments that would otherwise become part of 
my AD review for ospfv3-srv6-extensions, so I thought I’d share them now.

draft-ietf-lsr-isis-srv6-extensions-19 is currently in RFC-EDITOR state so it 
may or may not be reasonable to make any changes, but I’m going to mention them 
below anyway. I’m sorry I didn’t notice this before we got through IESG review.

draft-ietf-lsr-ospfv3-srv6-extensions-08 Section 2 defines the flags field in a 
way that (as per usual) conveniently happens to be identical to how the IS-IS 
document defines it. However, I don’t see any language in 
draft-ietf-lsr-ospfv3-srv6-extensions-08 saying that the IANA Registry from the 
IS-IS draft MUST be used for the assignment of flags for the OSPFv3 field. 
Shouldn’t you say this? 

Also, the registry should probably refer back to both (all three, if we include 
the BGP-LS one, but that's another story) specs that make assignments from it, 
shouldn’t it? So where the IS-IS document says,

"This document requests a new IANA registry be created under the IS-IS TLV 
Codepoints registry to control the assignment of bits 0 to 15 in the Flags 
field of the ISIS SRv6 Capabilities sub-TLV specified in this document (Section 
2):"

Maybe it should add something like “… as well as the corresponding field 
defined in Section 2 of draft-ietf-lsr-ospfv3-srv6-extensions-08.” (And maybe 
“and Section 3.1 of draft-ietf-idr-bgpls-srv6-ext-12”?). It might be easier to 
drop that change into the IS-IS draft now, before it exits RFC-EDITOR state (if 
agreed of course) but we could also do it by patching the registry text in the 
OSPFv3 (and BGP-LS?) draft’s IANA section.

Also, a minor point: draft-ietf-lsr-isis-srv6-extensions-19 uses inconsistent 
hyphenation for the protocol name — “ISIS” or “IS-IS”. My own preference is 
“IS-IS” as both more accurate and not as subject to conflation with other uses 
of “Isis”, but anyway please pick one and stick with it? I guess the RFC Editor 
will take care of this, but I apologize for not catching it during IESG review.

(This also leads me to wonder why we even put this registry, that’s shared by 
two (three?) protocols, under the IS-IS TLV Codepoints registry instead of 
under Interior Gateway Protocol (IGP) Parameters, but given the publication 
stage we’re at it may not be worth trying to change that.)

Thanks,

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

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[John Scudder]

Hi Lars,

There has been considerable discussion about the WG’s reason for structuring 
the document this way, and helpful updates made to the current document. I 
think we can conclude, or at least I conclude, that this was done with 
considered intent and for good reasons.

Do you feel your DISCUSS has been addressed?

Thanks,

—John

> On Sep 30, 2022, at 8:27 AM, Lars Eggert via Datatracker  
> wrote:
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-lsr-pce-discovery-security-support-11: Discuss
> 
> 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!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8J-BPa3$
> 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-pce-discovery-security-support/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt2I779yk$
> 
> 
> 
> --
> DISCUSS:
> --
> 
> # GEN AD review of draft-ietf-lsr-pce-discovery-security-support-11
> 
> CC @larseggert
> 
> ## Discuss
> 
> ### Section 4, paragraph 3
> ```
> Section 4 of [RFC5088] states that no new sub-TLVs will be added to
> the PCED TLV, and no new PCE information will be carried in the
> Router Information LSA.  This document updates [RFC5088] by allowing
> the two sub-TLVs defined in this document to be carried in the PCED
> TLV advertised in the Router Information LSA.
> 
> Section 4 of [RFC5089] states that no new sub-TLVs will be added to
> the PCED TLV, and no new PCE information will be carried in the
> Router CAPABLITY TLV.  This document updates [RFC5089] by allowing
> the two sub-TLVs defined in this document to be carried in the PCED
> TLV advertised in the Router CAPABILITY TLV.
> 
> This introduction of additional sub-TLVs should be viewed as an
> exception to the [RFC5088][RFC5089] policy, justified by the
> requirement to discover the PCEP security support prior to
> establishing a PCEP session.  The restrictions defined in
> [RFC5089][RFC5089] should still be considered to be in place.
> ```
> (This is mostly for discussion on the telechat, and I expect to clear
> during the call.)
> 
> Why were 5088/89 so strict on not allowing new sub-TLVs? This seems
> quite unusual for IETF specs. I'm not arguing that this document
> can't update those earlier RFCs to allow these new sub-TLVs, but it
> seems odd to do so and in the same sentence say "the restrictions
> should still be considered in place."
> 
> ### Section 8.2, paragraph 1
> ```
> The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they
> did not create a registry for it.  This document requests IANA to
> create a new registry called "PCED sub-TLV type indicators" under the
> "Interior Gateway Protocol (IGP) Parameters" grouping.  The
> registration policy for this registry is "IETF Review" [RFC8126].
> Values in this registry come from the range 0-65535.
> ```
> Should the registration policy not be stricter (e.g., Standards
> Action?) given that 5088/89 didn't even allow any new values?
> 
> 
> --
> COMMENT:
> --
> 
> ## Comments
> 
> ### Inclusive language
> 
> Found terminology that should be reviewed for inclusivity; see
> https://urldefense.com/v3/__https://www.rfc-editor.org/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt1fwrlFS$
>for background and more
> guidance:
> 
> * Term `master`; alternatives might be `active`, `central`, `initiator`,
>   `leader`, `main`, `orchestrator`, `parent`, `primary`, `server`
> * Term `man`; alternatives might be `individual`, `people`, `person`
> 
> ## Nits
> 
> All comments below are about very minor potential issues that you may choose 
> to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via 
> https://urldefense.com/v3/__https://github.com/larseggert/ietf-reviewtool__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjtxqHvOEf$
>   ), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> ### URLs
> 
> These URLs in the document can probably be converted to HTTPS:
> 
> * 
> 

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-ospf-l2bundles-06: (with DISCUSS and COMMENT)

[John Scudder]

[posting to keep the WG in the loop]

Hi Ketan,

As discussed in the parallel thread with Amanda @ IANA, this looks good, except 
that it would be a good idea to supply specific text for IANA to use as an 
annotation on the registry. Amanda pointed to the Note on 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-neighbor-information
 as an example of how to write it.

Thanks,

—John

> On Oct 6, 2022, at 10:46 AM, Ketan Talaulikar  wrote:
> 
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John,
> 
> We've posted an update of the draft with the changes as per option 1 below: 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-09
> 
> Please let us know if there are any other concerns. Will also let the IANA 
> team know of this update on the parallel thread so they can also check/review 
> the same.
> 
> Thanks,
> Ketan
> 
> 
> On Thu, Oct 6, 2022 at 6:37 PM John Scudder  wrote:
> Hi Ketan,
> 
> Thanks for the analysis. A few comments below.
> 
> > On Oct 6, 2022, at 8:30 AM, Ketan Talaulikar  wrote:
> > 
> > Hi John/Lars,
> > 
> > I hope this topic can be discussed in the upcoming telechat to conclude on 
> > the option to be adopted.
> > 
> > To make it easier, let me provide a pointer to the text for each inline 
> > below. I am not sure that I understand option 3 very well.
> > 
> > 
> > On Wed, Oct 5, 2022 at 9:42 PM John Scudder  wrote:
> > Hi All,
> > 
> > (To keep everyone in the loop since you weren’t all on the cc of the IANA 
> > review email.)
> > 
> > Amanda Baber at IANA pointed out that the added paragraph is a problem for 
> > IANA since it’s too imprecise for IANA to carry out. The options come down 
> > to:
> > 
> > 1. Revisit the WG decision, and add a field to the registry for the “Y/N” 
> > annotations that relate to this spec. 
> > 
> > KT> This was 
> > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-05#section-3
> > 
> >IANA is requested to introduce a column "Applicability to L2 Bundle
> >Member TLV" in the registry tables for the "OSPFv2 Extended Link TLV
> >Sub-TLVs" registry with the initial updates (Y/N) against allocations
> >as indicated in Figure 2.  Similarly, IANA is requested to introduce
> >a column "Applicability to L2 Bundle Member TLV" in the registry
> >tables for the "OSPFv3 Extended LSA Sub-TLVs" registry with the
> >initial updates (Y/N/X) against allocations as indicated in Figure 3.
> >Further allocations from these two registries are expected to
> >indicate the applicability of the introduced sub-TLV to the L2 Bundle
> >Member TLV that would get updated in these registries.
> 
> Thanks. As mentioned earlier, this is my preferred option — the more so after 
> looking through your analysis. I think all the gyrations after version 05 
> have demonstrated amply that “perfect is the enemy of good”.
> 
> > 2. Change the policy to something like "IETF Review (Additional Expert 
> > Review Required) or IESG Approval" and include advice to the experts in the 
> > document. (Thanks to Amanda for this suggestion.)
> > 
> > KT> This is a "quick" tweak on 
> > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-08#section-4
> >  as follows:
> > 
> >This document updates the guidance to IANA for further allocations
> >from the "OSPFv2 Extended Link TLV Sub-TLVs" and the "OSPFv3 Extended
> >LSA Sub-TLVs" registries to "IETF Review (Additional Expert Review
> > 
> >Required)" [RFC8126] and requests the addition of this document
> >as a reference to those registries.  It requires that the designated
> > 
> >expert appointed by IESG verify that any document
> >requesting allocation of code point from these two registries needs
> >to specify the applicability of the introduced sub-TLV to the L2
> >Bundle Member TLV in a manner similar to Figure 2 and Figure 3 that
> >cover existing allocations up to the point of publication of this
> >document.
> 
> That looks right. As previously mentioned I don’t see benefit to choosing 
> this option instead of (1) — all cost, no additional benefit.
> 
> > 3. Move the “it requires” text out of the IANA considerations and into a 
> > more appropriate section, and don’t try to put a gatekeeper into the 
> > registry (yet).
> > 
> > KT> I am not sure what this option invo

Re: [Lsr] Secdir last call review of draft-ietf-lsr-isis-flood-reflection-10

[John Scudder]

Thanks for the review, Rich. One tiny nit, mostly for the authors:

> On Oct 3, 2022, at 12:23 PM, Rich Salz via Datatracker  
> wrote:
> 
> s/could be in most extreme case/could be in THE most extreme case/

Please don’t put “the” in all caps when you do the edit. Even though there’s no 
formal restriction on using all caps for non-keywords in our documents, some 
reviewers get upset about it for anything that’s not an RFC 2119 keyword. Let’s 
not upset them.

Thanks,

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

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-ospf-l2bundles-06: (with DISCUSS and COMMENT)

[John Scudder]

Hi Ketan,

Thanks for the analysis. A few comments below.

> On Oct 6, 2022, at 8:30 AM, Ketan Talaulikar  wrote:
> 
> Hi John/Lars,
> 
> I hope this topic can be discussed in the upcoming telechat to conclude on 
> the option to be adopted.
> 
> To make it easier, let me provide a pointer to the text for each inline 
> below. I am not sure that I understand option 3 very well.
> 
> 
> On Wed, Oct 5, 2022 at 9:42 PM John Scudder  wrote:
> Hi All,
> 
> (To keep everyone in the loop since you weren’t all on the cc of the IANA 
> review email.)
> 
> Amanda Baber at IANA pointed out that the added paragraph is a problem for 
> IANA since it’s too imprecise for IANA to carry out. The options come down to:
> 
> 1. Revisit the WG decision, and add a field to the registry for the “Y/N” 
> annotations that relate to this spec. 
> 
> KT> This was 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-05#section-3
> 
>IANA is requested to introduce a column "Applicability to L2 Bundle
>Member TLV" in the registry tables for the "OSPFv2 Extended Link TLV
>Sub-TLVs" registry with the initial updates (Y/N) against allocations
>as indicated in Figure 2.  Similarly, IANA is requested to introduce
>a column "Applicability to L2 Bundle Member TLV" in the registry
>tables for the "OSPFv3 Extended LSA Sub-TLVs" registry with the
>initial updates (Y/N/X) against allocations as indicated in Figure 3.
>Further allocations from these two registries are expected to
>indicate the applicability of the introduced sub-TLV to the L2 Bundle
>Member TLV that would get updated in these registries.

Thanks. As mentioned earlier, this is my preferred option — the more so after 
looking through your analysis. I think all the gyrations after version 05 have 
demonstrated amply that “perfect is the enemy of good”.

> 2. Change the policy to something like "IETF Review (Additional Expert Review 
> Required) or IESG Approval" and include advice to the experts in the 
> document. (Thanks to Amanda for this suggestion.)
> 
> KT> This is a "quick" tweak on 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-08#section-4
>  as follows:
> 
>This document updates the guidance to IANA for further allocations
>from the "OSPFv2 Extended Link TLV Sub-TLVs" and the "OSPFv3 Extended
>LSA Sub-TLVs" registries to "IETF Review (Additional Expert Review
> 
>Required)" [RFC8126] and requests the addition of this document
>as a reference to those registries.  It requires that the designated
> 
>expert appointed by IESG verify that any document
>requesting allocation of code point from these two registries needs
>to specify the applicability of the introduced sub-TLV to the L2
>Bundle Member TLV in a manner similar to Figure 2 and Figure 3 that
>cover existing allocations up to the point of publication of this
>document.

That looks right. As previously mentioned I don’t see benefit to choosing this 
option instead of (1) — all cost, no additional benefit.

> 3. Move the “it requires” text out of the IANA considerations and into a more 
> appropriate section, and don’t try to put a gatekeeper into the registry 
> (yet).
> 
> KT> I am not sure what this option involves. Putting this document as a 
> reference but no IANA actions or gatekeeper seems odd to me. Isn't this 
> option - "do nothing" - which is the state in which this draft came out of 
> the WG and AD review?

Yes indeed, I guess I only mentioned it for completeness. It would resolve 
IANA’s concerns but wouldn’t satisfy Lars’s DISCUSS, so I think we can take 
this off the table.

—John

> What came out of the WG: 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-04#section-3
>  also same as at the end of John's AD review: 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-06#section-3
> 
> Thanks,
> Ketan
>  
> 
> I think either option 1 or option 2 would be fine insofar as resolving Lars 
> (et al)’s concern. Option 3 would amount to returning to the previous plan of 
> record, which was to ship the spec without a registry gatekeeper but ask the 
> WG to produce a registry reorg that does so in a more comprehensive way.
> 
> Of these plans, I’m least enthusiastic about option 2 since it would require 
> us to appoint and instruct an expert reviewer, for what I hope will be a 
> short-lived function. That implies — to me — that option 1 is the least bad 
> way of breaking the deadlock.
> 
> Until we resolve this the draft will be stuck in “IANA NOT OK”.
> 
> —John
> 
> >

Re: [Lsr] [Pce] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[John Scudder]

Silly me,

> On Oct 5, 2022, at 2:17 PM, John Scudder  wrote:
> 
>  see that warning from idnits pretty often too, I don’t know what triggers it,

… it’s right there in the warning:

 (Using the creation date from RFC5088, updated by this document, for
 RFC5378 checks: 2006-09-20)

Unless I’m misremembering, you aren’t copying blocks of text from 5088 or 5089 
into your document. Even where you directly update 5088/5089, in section 4, you 
paraphrase them, you don’t quote them. So if it were my draft, I would be 
comfortable leaving the disclaimer out.

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

Re: [Lsr] [Pce] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[John Scudder]

Hi Dhruv,

> On Oct 5, 2022, at 1:13 PM, Dhruv Dhody  wrote:
> 
> Yes, none of the changes require it! 
> But this existing idnits warning made sense to me and thus I added the 
> disclaimer. Let me know if that is a mistake, I can revert!  

Is there actually pre-2008 material in the draft? I didn’t do a detailed check 
with that in mind, but it seems like there shouldn’t be, it’s new work. I see 
that warning from idnits pretty often too, I don’t know what triggers it, so 
I’ve kind of trained myself to ignore it, probably not the best habit :-(. The 
main place I expect to see the pre-2008 disclaimer is on a bis of a pre-2008 
RFC.

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

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-ospf-l2bundles-06: (with DISCUSS and COMMENT)

[John Scudder]

Hi All,

(To keep everyone in the loop since you weren’t all on the cc of the IANA 
review email.)

Amanda Baber at IANA pointed out that the added paragraph is a problem for IANA 
since it’s too imprecise for IANA to carry out. The options come down to:

1. Revisit the WG decision, and add a field to the registry for the “Y/N” 
annotations that relate to this spec.  
2. Change the policy to something like "IETF Review (Additional Expert Review 
Required) or IESG Approval" and include advice to the experts in the document. 
(Thanks to Amanda for this suggestion.) 
3. Move the “it requires” text out of the IANA considerations and into a more 
appropriate section, and don’t try to put a gatekeeper into the registry (yet).

I think either option 1 or option 2 would be fine insofar as resolving Lars (et 
al)’s concern. Option 3 would amount to returning to the previous plan of 
record, which was to ship the spec without a registry gatekeeper but ask the WG 
to produce a registry reorg that does so in a more comprehensive way.

Of these plans, I’m least enthusiastic about option 2 since it would require us 
to appoint and instruct an expert reviewer, for what I hope will be a 
short-lived function. That implies — to me — that option 1 is the least bad way 
of breaking the deadlock.

Until we resolve this the draft will be stuck in “IANA NOT OK”.

—John

> Hi Lars,
> 
> Thanks for your confirmation.
> 
> Acee/John, I haven't received any response (objection or support) from the WG 
> on this change. I believe this may be a good interim step until the WG 
> considers any IANA registry reorganization. Can you please share your views 
> as shepherd and AD respectively?
> 
> Thanks,
> Ketan
> 
> 
> On Mon, Oct 3, 2022 at 6:31 PM Lars Eggert  wrote:
> Hi,
> 
> On 2022-9-30, at 16:37, Ketan Talaulikar  wrote:
> > In brief, the proposal was to introduce the following text in the IANA 
> > considerations:
> > 
> > 
> >This document updates the guidance to IANA for further allocations
> >from the "OSPFv2 Extended Link TLV Sub-TLVs" [1] and the
> >"OSPFv3 Extended LSA Sub-TLVs" [2] registries and requests the addition
> >of this document as a reference to those registries. It requires
> >that any document requesting allocation of code point from these
> >two registries need to indicate the applicability of the introduced
> >sub-TLV to the L2 Bundle Member TLV in that document.
> 
> something along those lines would work for me.
> 
> Thanks,
> Lars
> 
> 

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

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[John Scudder]

There’s also a spurious quotation mark in

   such as using [RFC6823]"

I was also wondering why the pre-2008 disclaimer got added? None of the changes 
in -12 require it. 

Thanks,

—John

> On Oct 5, 2022, at 11:46 AM, Acee Lindem (acee)  wrote:
> 
> 
> 
> Hi Dhruv, 
> Thanks for the quick turnaround. It looks good to me. One nit, I believe a 
> period was added to “However, as noted in [RFC6952].,” by mistake.
> Thanks,
> Acee
>  
> From: Lsr  on behalf of Dhruv Dhody 
> 
> Date: Wednesday, October 5, 2022 at 9:06 AM
> To: Lars Eggert 
> Cc: The IESG , 
> "draft-ietf-lsr-pce-discovery-security-supp...@ietf.org" 
> , 
> "lsr-cha...@ietf.org" , "lsr@ietf.org" , 
> Acee Lindem , "p...@ietf.org" , "Les Ginsberg 
> (ginsberg)" , Adrian Farrel , John 
> Scudder , Roman Danyliw 
> Subject: Re: [Lsr] Lars Eggert's Discuss on 
> draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)
>  
> Hi all, 
>  
> I have incorporated changes suggested by Les and Acee in the working copy 
> maintained at -
>  
> TXT - 
> https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt
> DIFF - 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-lsr-pce-discovery-security-support-11=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt
>  
> Also, see inline...
>  
>  
> On Fri, Sep 30, 2022 at 5:57 PM Lars Eggert via Datatracker 
>  wrote:
>> Lars Eggert has entered the following ballot position for
>> draft-ietf-lsr-pce-discovery-security-support-11: Discuss
>> 
>> 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/about/groups/iesg/statements/handling-ballot-positions/ 
>> for more information about how to handle DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/
>> 
>> 
>> 
>> --
>> DISCUSS:
>> --
>> 
>> # GEN AD review of draft-ietf-lsr-pce-discovery-security-support-11
>> 
>> CC @larseggert
>> 
>> ## Discuss
>> 
>> ### Section 4, paragraph 3
>> ```
>>  Section 4 of [RFC5088] states that no new sub-TLVs will be added to
>>  the PCED TLV, and no new PCE information will be carried in the
>>  Router Information LSA.  This document updates [RFC5088] by allowing
>>  the two sub-TLVs defined in this document to be carried in the PCED
>>  TLV advertised in the Router Information LSA.
>> 
>>  Section 4 of [RFC5089] states that no new sub-TLVs will be added to
>>  the PCED TLV, and no new PCE information will be carried in the
>>  Router CAPABLITY TLV.  This document updates [RFC5089] by allowing
>>  the two sub-TLVs defined in this document to be carried in the PCED
>>  TLV advertised in the Router CAPABILITY TLV.
>> 
>>  This introduction of additional sub-TLVs should be viewed as an
>>  exception to the [RFC5088][RFC5089] policy, justified by the
>>  requirement to discover the PCEP security support prior to
>>  establishing a PCEP session.  The restrictions defined in
>>  [RFC5089][RFC5089] should still be considered to be in place.
>> ```
>> (This is mostly for discussion on the telechat, and I expect to clear
>> during the call.)
>> 
>> Why were 5088/89 so strict on not allowing new sub-TLVs? This seems
>> quite unusual for IETF specs. I'm not arguing that this document
>> can't update those earlier RFCs to allow these new sub-TLVs, but it
>> seems odd to do so and in the same sentence say "the restrictions
>> should still be considered in place."
>> 
>> ### Section 8.2, paragraph 1
>> ```
>>  The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they
>>  did not create a registry for it.  This document requests IANA to
>>  create a new registry called "PCED sub-TLV type indicators" under the
>>  "Interior Gateway Protocol (IGP) Parameters" grouping.  The
>>  registration policy for this registry is "IETF Review" [RFC8126].
>>  Values in this registry come from the rang

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)

[John Scudder]

Hi Acee,

> On Oct 4, 2022, at 12:57 PM, Acee Lindem (acee) 
>  wrote:
> 
>> From: "Rob Wilton (rwilton)" 
...
>> Is there somewhere for these new config knobs are being tracked - so that 
>> they don’t get forgotten?
>  
> We have the Datatracker for that…

I don’t follow — what datatracker feature are you thinking of using to keep 
track of the fact that draft-ietf-lsr-ospf-l2bundles said “hey this should be 
configurable with YANG” but didn’t actually specify the YANG? 

Thanks,

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

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[John Scudder]

Hi Les,

Thanks, that’s helpful. One comment, regarding

> Hard for me to justify modifying RFC 5088/5089 simply to add a pointer to 
> GENINFO/OSPF-GT even if such an addition might be relevant.

what I was actually suggesting was that the paragraph in 
draft-ietf-lsr-pce-discovery-security-support could be updated to add the 
pointer. Since draft-ietf-lsr-pce-discovery-security-support formally updates 
RFCs 5088/5089, that would establish at least some mechanism less unreliable 
than trolling through old mailing lists, to help a new implementor find this 
old history, while still not requiring us to do the heavy lift of bis’ing 
5088/5089 (which I agree would be crazy to do just for this).

—John

> On Oct 4, 2022, at 3:24 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> John -
> 
> Thanx for finding the old email thread.
> Folks also might want to look at this thread:  
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/NhezQqKwIvHK_9dDUmW0iuhyjDA/__;!!NEt6yMaO-gk!BsexV0igrfCC6797R-5WEj654ycPt6DwvDJJ9cKMToAWSjm6GzCfKem3ylr0c4DezgdzY3N-mB2epg$
> 
> In summary, I raised these points when the draft was adopted - but eventually 
> agreed to allow the draft to go forward.
> 
> The intent of the restrictions in RFC5088/5089 is to discourage carrying 
> additional "non-routing" information in the IGPs.
> The practical matter in this case is that trying to advertise the additional 
> information using some other mechanism is quite costly and awkward. The fact 
> that the additional information are sub-sub-TLVs of the PCED sub-TLV speaks 
> to the coupling of the new information with the existing information.
> 
> I think we want to keep restrictions in place so as to discourage new 
> advertisements, but recognize that we compromise when it seems practical. 
> This isn’t ideal - and I understand why Lars would want to discuss this - but 
> I don't have a cleaner solution.
> The fact that we introduced PCE advertisements into the IGPs in the first 
> place makes it difficult to adhere to the restrictions for PCE related 
> advertisements.
> 
> Section 4 of the draft states:
> 
> "This introduction of additional sub-TLVs should be viewed as an exception to 
> the [RFC5088][RFC5089] policy, justified by the requirement to discover the 
> PCEP security support prior to establishing a PCEP session. The restrictions 
> defined in [RFC5089][RFC5089] should still be considered to be in place."
> 
> which is an accurate summary.
> 
> Hard for me to justify modifying RFC 5088/5089 simply to add a pointer to 
> GENINFO/OSPF-GT even if such an addition might be relevant.
> 
>   Les
> 
>> -Original Message-
>> From: John Scudder 
>> Sent: Tuesday, October 4, 2022 11:16 AM
>> To: Acee Lindem (acee) 
>> Cc: Lars Eggert ; The IESG ; draft-ietf-lsr-
>> pce-discovery-security-supp...@ietf.org; lsr-cha...@ietf.org; lsr
>> ; p...@ietf.org; Hannes Gredler ; Les
>> Ginsberg (ginsberg) ; JP Vasseur (jvasseur)
>> ; meral.shirazip...@polymtl.ca; Adrian Farrel
>> 
>> Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-
>> security-support-11: (with DISCUSS and COMMENT)
>> 
>> Hi Acee,
>> 
>> Thanks. I have a few followups (addressed to the WG at large, not just you).
>> 
>> First, your point relates to OSPF. In the mail thread I cited, Les is 
>> talking about
>> IS-IS. Are the concerns there similar?
>> 
>> Second, you say "For non-routing information or advertising more
>> information without impacting unicast routing, I'd recommend OSPF-GT”.
>> That seems similar to Les’s advice (in
>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/isis-wg/-__;!!NEt6yMaO-gk!BsexV0igrfCC6797R-5WEj654ycPt6DwvDJJ9cKMToAWSjm6GzCfKem3ylr0c4DezgdzY3NUtSlhyQ$
>> YjCC5vzHkBY4aVWLJGP2w5OJHM/) to use IS-IS GENINFO (RFC 6823). I can
>> see that extending the PCED (sub-)TLV was the most obvious and expedient
>> thing to do, but was it the right thing? I’m thinking about your advice and
>> Les’s, to use the generalized/generic transport options instead — was that
>> option considered/discussed, or had everyone forgotten about the “please
>> use GENINFO” suggestion by the time work on this draft began (after all,
>> more than ten years after the base document was developed)? (I don’t see
>> evidence in a review of the mailing list archives that this was ever 
>> considered,
>> but I might have missed something.)
>> 
>> Third, if indeed the restriction in question is no longer relevant, is this
>> paragraph in the new spec really needed or even appropriate?
>> 
>>   This introduction of additional sub-TLVs shou

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[John Scudder]

Hi Acee,

Thanks. I have a few followups (addressed to the WG at large, not just you).

First, your point relates to OSPF. In the mail thread I cited, Les is talking 
about IS-IS. Are the concerns there similar?

Second, you say "For non-routing information or advertising more information 
without impacting unicast routing, I'd recommend OSPF-GT”. That seems similar 
to Les’s advice (in 
https://mailarchive.ietf.org/arch/msg/isis-wg/-YjCC5vzHkBY4aVWLJGP2w5OJHM/) to 
use IS-IS GENINFO (RFC 6823). I can see that extending the PCED (sub-)TLV was 
the most obvious and expedient thing to do, but was it the right thing? I’m 
thinking about your advice and Les’s, to use the generalized/generic transport 
options instead — was that option considered/discussed, or had everyone 
forgotten about the “please use GENINFO” suggestion by the time work on this 
draft began (after all, more than ten years after the base document was 
developed)? (I don’t see evidence in a review of the mailing list archives that 
this was ever considered, but I might have missed something.)

Third, if indeed the restriction in question is no longer relevant, is this 
paragraph in the new spec really needed or even appropriate?

   This introduction of additional sub-TLVs should be viewed as an
   exception to the [RFC5088][RFC5089] policy, justified by the
   requirement to discover the PCEP security support prior to
   establishing a PCEP session.  The restrictions defined in
   [RFC5089][RFC5089] should still be considered to be in place.

Maybe it should just get rid of the restriction completely! On the other hand, 
if it *is* appropriate to leave that paragraph in, maybe it should be a little 
more helpful, by mentioning IS-IS GENINFO and OSPF-GT as being the preferred 
options for any future work, so that next time we are less likely to have the 
same oversight?

Thanks,

—John

> On Oct 4, 2022, at 1:52 PM, Acee Lindem (acee)  wrote:
> 
> Speaking as long-time LSR/OSPF WG Member and Co-author of RFC 4970 and RFC 
> 7770:
> 
> When RFC 5088 was being standardized, there was concern over both advertising 
> non-routing information in OSPF and exceeding the maximum size of an OSPF 
> Router Information LSA which was limited to a single LSA instance per OSPF 
> router (RFC 4970).  The controversial statement below was added to assuage 
> these concerns. With the publication of RFC 7770, an OSPF router can 
> advertise multiple Router Instance LSAs with different instance IDs. At the 
> same time, we have evolved to using Router Instance LSAs for limited 
> capability information associated with routing applications (e.g., PCE). For 
> non-routing information or advertising more information without impacting 
> unicast routing, I'd recommend OSPF-GT 
> (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/__;!!NEt6yMaO-gk!F84pVCWbzGhoRsiBwEaOLHv7h4wykjYtXlrBXBrhnhZHtCGHtry0Z17ASBG2PUMF_yYzechg$
>   ).
> 
> Thanks,
> Acee
> 
> On 10/4/22, 1:29 PM, "John Scudder"  wrote:
> 
>Hi Everyone,
> 
>+Adrian since he appears to have been the shepherd for RFC 5088, which is 
> the root of Lars’ DISCUSS.
>+Hannes, Les, JP, Meral as people who may have more context on the question
> 
>Since I haven’t seen any replies to this DISCUSS yet I did a little 
> digging. The text in question:
> 
>   No additional sub-TLVs will be added to the PCED TLV in the future.
>   If a future application requires the advertisement of additional PCE
>   information in OSPF, this will not be carried in the Router
>   Information LSA.
> 
>Was introduced in draft-ietf-pce-disco-proto-ospf-07, September 2007. 
> Checking in the archives, I see one relevant mail thread: 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/pce/UERk8vF5e7cFQoblkDAVA74Ojh0/__;!!NEt6yMaO-gk!F84pVCWbzGhoRsiBwEaOLHv7h4wykjYtXlrBXBrhnhZHtCGHtry0Z17ASBG2PUMF_994CNrH$
>is the beginning, but then it seems to have been indexed wrong so you 
> should continue from here: 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/isis-wg/BpUVKsjr46ha9kbF3jwgKyymEBo/__;!!NEt6yMaO-gk!F84pVCWbzGhoRsiBwEaOLHv7h4wykjYtXlrBXBrhnhZHtCGHtry0Z17ASBG2PUMF_4C7YoXF$
>to pick up Les’s reply as well. There are four relevant messages in total, 
> from Meral Shirazipour, JP Vasseur, Hannes Gredler, and Les Ginsberg.
> 
>Rather than try to summarize I’m going to ask people to go look at the 
> short mail thread for themselves. Perhaps this will jog people’s memories 
> enough to allow a discussion on why we’re opening a registry for new code 
> points that was explicitly defined as being closed.
> 
>Thanks,
> 
>—John
> 
>> On Sep 30, 2022, at 8:27 AM, Lars Eggert via Datatracker  
>> wrote:
>> 
>

Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[John Scudder]

Hi Everyone,

+Adrian since he appears to have been the shepherd for RFC 5088, which is the 
root of Lars’ DISCUSS.
+Hannes, Les, JP, Meral as people who may have more context on the question

Since I haven’t seen any replies to this DISCUSS yet I did a little digging. 
The text in question:

   No additional sub-TLVs will be added to the PCED TLV in the future.
   If a future application requires the advertisement of additional PCE
   information in OSPF, this will not be carried in the Router
   Information LSA.

Was introduced in draft-ietf-pce-disco-proto-ospf-07, September 2007. Checking 
in the archives, I see one relevant mail thread: 
https://mailarchive.ietf.org/arch/msg/pce/UERk8vF5e7cFQoblkDAVA74Ojh0/ is the 
beginning, but then it seems to have been indexed wrong so you should continue 
from here: 
https://mailarchive.ietf.org/arch/msg/isis-wg/BpUVKsjr46ha9kbF3jwgKyymEBo/ to 
pick up Les’s reply as well. There are four relevant messages in total, from 
Meral Shirazipour, JP Vasseur, Hannes Gredler, and Les Ginsberg.

Rather than try to summarize I’m going to ask people to go look at the short 
mail thread for themselves. Perhaps this will jog people’s memories enough to 
allow a discussion on why we’re opening a registry for new code points that was 
explicitly defined as being closed.

Thanks,

—John

> On Sep 30, 2022, at 8:27 AM, Lars Eggert via Datatracker  
> wrote:
> 
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-lsr-pce-discovery-security-support-11: Discuss
> 
> 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!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8J-BPa3$
> 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-pce-discovery-security-support/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt2I779yk$
> 
> 
> 
> --
> DISCUSS:
> --
> 
> # GEN AD review of draft-ietf-lsr-pce-discovery-security-support-11
> 
> CC @larseggert
> 
> ## Discuss
> 
> ### Section 4, paragraph 3
> ```
> Section 4 of [RFC5088] states that no new sub-TLVs will be added to
> the PCED TLV, and no new PCE information will be carried in the
> Router Information LSA.  This document updates [RFC5088] by allowing
> the two sub-TLVs defined in this document to be carried in the PCED
> TLV advertised in the Router Information LSA.
> 
> Section 4 of [RFC5089] states that no new sub-TLVs will be added to
> the PCED TLV, and no new PCE information will be carried in the
> Router CAPABLITY TLV.  This document updates [RFC5089] by allowing
> the two sub-TLVs defined in this document to be carried in the PCED
> TLV advertised in the Router CAPABILITY TLV.
> 
> This introduction of additional sub-TLVs should be viewed as an
> exception to the [RFC5088][RFC5089] policy, justified by the
> requirement to discover the PCEP security support prior to
> establishing a PCEP session.  The restrictions defined in
> [RFC5089][RFC5089] should still be considered to be in place.
> ```
> (This is mostly for discussion on the telechat, and I expect to clear
> during the call.)
> 
> Why were 5088/89 so strict on not allowing new sub-TLVs? This seems
> quite unusual for IETF specs. I'm not arguing that this document
> can't update those earlier RFCs to allow these new sub-TLVs, but it
> seems odd to do so and in the same sentence say "the restrictions
> should still be considered in place."
> 
> ### Section 8.2, paragraph 1
> ```
> The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they
> did not create a registry for it.  This document requests IANA to
> create a new registry called "PCED sub-TLV type indicators" under the
> "Interior Gateway Protocol (IGP) Parameters" grouping.  The
> registration policy for this registry is "IETF Review" [RFC8126].
> Values in this registry come from the range 0-65535.
> ```
> Should the registration policy not be stricter (e.g., Standards
> Action?) given that 5088/89 didn't even allow any new values?
> 
> 
> --
> COMMENT:
> --
> 
> ## Comments
> 
> ### Inclusive language
> 
> Found terminology that should be reviewed for inclusivity; see
> 

Re: [Lsr] [Teas] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)

[John Scudder]

Hi Les and other authors,

I didn’t see a reply to Murray’s comment. It’s not a DISCUSS so not mandatory 
for you to reply but it would be appreciated.

Of Murray’s comments, I personally don’t think RFC 7981 needs to be normative, 
the test being that if you never looked at 7981 you’d still know how to update 
the registry as Section 6.3 requests.

On looking at the RFC 4271 references, in looking at the second reference to it:

   Note further that if BGP is used to exchange TE
   information as described in Section 4.1, the inter-AS BGP session
   SHOULD be secured using mechanisms as described in [RFC4271] to
   provide authentication and integrity checks.

I noticed a more serious concern of my own; I’m not sure how I missed this. To 
wit, RFC 4271 specifies use of TCP-MD5 [RFC 2385] for authentication/integrity. 
But 2385 was obsoleted by TCP-AO [RFC 5925]. Probably it would be better to say 
something like

   Note further that if BGP is used to exchange TE
   information as described in Section 4.1, the inter-AS BGP session
   SHOULD be secured using mechanisms such as those described in [RFC5925] to
   provide authentication and integrity checks.

And then add 5925 as, I suppose, a normative reference. Although I did sneak 
“such as” in there, since there are other ways to secure BGP as well (for 
example it’s been known to run it over IPSec, or people do use TCP-MD5 despite 
it being obsoleted). 

I apologize for not noticing this sooner!

Regarding Murray’s comments on SHOULDs, it looks as though the ones regarding 
Section 3 (all subsections) are overtaken by events (Murray, check if you like; 
most of the SHOULDs are gone and IMO the ones in §3.1 are sufficiently 
qualified). The points about Section 4 are unchanged but I’d like to point out 
that Section 4 itself is unchanged vs. the base RFC 5316 so I had chosen to let 
sleeping dogs lie. 

—John

> On Sep 22, 2022, at 2:17 AM, Murray Kucherawy via Datatracker 
>  wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-lsr-isis-rfc5316bis-04: 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!HB2wVApMPYK0lcGJi-MJje2u_7UwRYvbgYV8xUgKlMyST3sMGh33yhvlbOGfQcFEZ2AE-vijj-SY$
> 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-isis-rfc5316bis/__;!!NEt6yMaO-gk!HB2wVApMPYK0lcGJi-MJje2u_7UwRYvbgYV8xUgKlMyST3sMGh33yhvlbOGfQcFEZ2AE-sFQ5Tno$
> 
> 
> 
> --
> COMMENT:
> --
> 
> I support Alvaro's DISCUSS, and add my own comments related to his first 
> point:
> 
> The first two SHOULDs in Section 3.1 would benefit from some guidance about
> when an implementer might opt to deviate from that advice.  This occurs again
> Sections 3.3.4, 3.4.1, 3.4.2, the top of Section 4 (two SHOULDs) and the 
> bottom
> of Section 4 (two SHOULD NOTs).
> 
> Given Section 6.3, I think RFC7981 should be a normative reference rather than
> an informative one.
> 
> I think RFC4271 also needs to be normative since it's referenced by a SHOULD.
> 
> 
> 
> ___
> Teas mailing list
> t...@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!HB2wVApMPYK0lcGJi-MJje2u_7UwRYvbgYV8xUgKlMyST3sMGh33yhvlbOGfQcFEZ2AE-i-Sv7mQ$

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

Re: [Lsr] Opsdir last call review of draft-ietf-lsr-ospf-l2bundles-06

[John Scudder]

> On Sep 24, 2022, at 3:55 AM, Dan Romascanu via Datatracker  
> wrote:
> 
> I would also suggest sending the document for review to the IEEE 802.1 WG via
> the IETF-IEEE coordination team.

N.b. I’ve pinged the coordination team leads and 802.1 liaison manager with 
this suggestion. 

Thanks,

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

Re: [Lsr] [Teas] Éric Vyncke's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)

[John Scudder]

Les,

If I read Tom’s last comment correctly, the entire substance of the change he’s 
suggesting is:

OLD
which contains the IPv4 Router ID of the router which
NEW
which identifies the router which

That seems reasonable to me considering that as Tom explains, the “IPv4 Router 
ID” is *not a thing that exists*. The “TE Router ID” exists, and you make the 
case that it should probably have been named the “IPv4 TE Router ID", but that 
isn’t what the text in question is referring to. Why would you *not* want to 
make this change, which seems to be both accurate and harmless?

Based only on the text shown in the OLD/NEW one might also suppose you could 
correct it to “NEW: which contains the Traffic Engineering Router ID of the 
router which”. But taken in context of the overall paragraph, that doesn’t work:

   The Router ID field of the inter-AS reachability TLV is 4 octets in
   length, which contains the IPv4 Router ID of the router who generates
   the inter-AS reachability TLV.  The Router ID SHOULD be identical to
   the value advertised in the Traffic Engineering Router ID TLV
   [RFC5305].  If no Traffic Engineering Router ID is assigned, the

The sentence after the one in question says it SHOULD be identical to the… TE 
Router ID. Which is the exception that proves the rule (that your text “IPv4 
Router ID” must not be referring directly to the TE Router ID).

Another fix could be to simply remove the clause in question, as in

   The Router ID field of the inter-AS reachability TLV is 4 octets in
   length.  The Router ID SHOULD be identical to
   the value advertised in the Traffic Engineering Router ID TLV
   [RFC5305].  If no Traffic Engineering Router ID is assigned, the

Thanks,

—John

> On Sep 21, 2022, at 9:49 AM, Les Ginsberg (ginsberg)  
> wrote:
> 
> 
> Tom -
>  
> > -Original Message-
> > From: t petch 
> > Sent: Wednesday, September 21, 2022 3:45 AM
> > To: Les Ginsberg (ginsberg) ; John Scudder
> > 
> > Cc: Eric Vyncke (evyncke) ; The IESG ;
> > draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; lsr 
> > ;
> > cho...@chopps.org; t...@ietf.org
> > Subject: Re: [Lsr] [Teas] Éric Vyncke's No Objection on draft-ietf-lsr-isis-
> > rfc5316bis-04: (with COMMENT)
> > 
> > On 21/09/2022 05:16, Les Ginsberg (ginsberg) wrote:
> > > Top posting here - and my response applies to the discussion between Eric,
> > John, and Tom regarding Section 3.1 (and also to Alvaro - though I will 
> > reply
> > directly to Alvaro's email as he has some specific questions not covered in 
> > the
> > discussion below...)
> > >
> > > The text in Section 3.1 is currently:
> > >
> > > " The Router ID field of the inter-AS reachability TLV is 4 octets in 
> > > length,
> > which contains the IPv4 Router ID of the router who generates the inter-AS
> > reachability TLV. The Router ID SHOULD be identical to the value advertised
> > in the Traffic Engineering Router ID TLV [RFC5305]. If no Traffic 
> > Engineering
> > Router ID is assigned, the Router ID SHOULD be identical to an IP Interface
> > Address [RFC1195] advertised by the originating IS. If the originating node
> > does not support IPv4, then the reserved value 0.0.0.0 MUST be used in the
> > Router ID field and the IPv6 Router ID sub-TLV MUST be present in the inter-
> > AS reachability TLV. The Router ID could be used to indicate the source of 
> > the
> > inter-AS reachability TLV."
> > >
> > >
> > > Tom suggests this should be modified to state:
> > >
> > > "> If a Traffic Engineering Router ID TLV
> > >> [RFC5305] is available for the router which generates
> > >> the inter-AS reachability TLV, then that value MUST be used.
> > >
> > > I am reluctant to do this. The use of MUST suggests that receivers should
> > do a check to see if the router referred to in the Router ID field actually
> > advertised a TE Router ID (TLV 134) and if it did and the value in the 
> > inter-AS
> > reachability TLV is non-zero and does not match the value advertised in TLV
> > 134 then the receiver is obligated to reject the inter-AS Reachability TLV 
> > as
> > "invalid". This is unnecessarily strict and onerous.
> > >
> > > If a node advertises TLV 134 then that value SHOULD be used in the inter-
> > AS reachability TLV. But if an implementation were to choose to use a value
> > advertised in an IPv4 Address TLV by the same node no harm would be done.
> > So I believe the existing text is more appropriate.
> > > Note that I am not suggesting that the router ID be ignored (the use of
> > SHOULD is

Re: [Lsr] [Teas] Éric Vyncke's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)

[John Scudder]

Hi Tom,

Thanks for your comments!

> On Sep 16, 2022, at 11:56 AM, t petch  wrote:
> 
> On 16/09/2022 14:13, John Scudder wrote:
>> Hi Éric,
>> 
>> A few comments below.
>> 
>>> On Sep 16, 2022, at 4:27 AM, Éric Vyncke via Datatracker  
>>> wrote:
>>> 
>>> ## COMMENTS
>>> 
>>> ### Section 3.1
>>> 
>>> ```
>>>   The Router ID field of the inter-AS reachability TLV is 4 octets in
>>>   length, which contains the IPv4 Router ID of the router who generates
>>>   the inter-AS reachability TLV.  The Router ID SHOULD be identical to
>>>   the value advertised in the Traffic Engineering Router ID TLV
>>>   [RFC5305].  If no Traffic Engineering Router ID is assigned, the
>>>   Router ID SHOULD be identical to an IP Interface Address [RFC1195]
>>>   advertised by the originating IS.
>>> ```
>>> 
>>> AFAIK, the router ID is 'just' a 32-bit value that it is protocol version
>>> agnostic. So, s/IPv4 Router ID/Router ID/ ?
>>> 
>>> Suggest: s/IP Interface Address [RFC1195]/IPv4 Interface Address [RFC1195]/ 
>>> ?
>> 
>> I wondered about this too when I was reviewing the document, and indeed RFC 
>> 5305 just calls the TE Router ID a 4-octet value. But then RFC 6119 says,
>> 
>>The TE Router ID TLV contains a stable IPv4 address that is routable,
>>regardless of the state of each interface.
>> 
>>Similarly, for IPv6, it is useful to have a stable IPv6 address
>>identifying a TE node.  The IPv6 TE Router ID TLV is defined in
>>Section 4.1.
>> 
>> So even though it was after the fact, I suppose calling the former the “IPv4 
>> Router ID” makes sense and just codifies what is apparently already the 
>> practice. The existence of the IPv6 TE Router ID, so named, is “the 
>> exception that proves the rule”.
> 
> Well, not really.
> 
> The router id is 32 bits with no semantics, often displayed as dotted
> quad.  It is used in a number of protocols, in both IPv4 and IPv6, as in
> OSPFv3.  A YANG type for it is defined in routing-types (RFC8294) and
> you will find it in such as draft-ietf-opsawg-l2nm.  It has nothing to
> do with IP of any version and so cannot be relied on for the transfer of
> packets.  (I see it used to add semantics about a router, such as OSPF
> Area, although others conflate it with an IPv4 loopback address).
> 
> TE needed a routable address and so created Traffic Engineering
> Router-ID, one for IPv4 and a different one for IPv6.  Try
> draft-ietf-ospf-yang s.2.4 for usage and references.  The terminology is
> not that of the original TE RFC (RFC3630) but I find the ospf-yang
> terminology clear and used elsewhere.  This I-D under review is a
> product of the LSR WG and I would have hoped that a draft-ietf-lsr would
> get this distinction between the router-id, with no semantics, and the
> TE router ID, IPv4 or IPv6, right:-(
> 
> Tom Petch

Actually now that you have sent me back to look again, I’m second-guessing 
myself. The text in question is from Section 3.1, which is about the Inter-AS 
Reachability TLV, and NOT the TE Router ID. So, the analysis I provided above 
doesn’t seem to be applicable. Looking at what RFC 5316 said, it’s

   The Router ID field of the inter-AS reachability TLV is 4 octets in
   length, which contains the Router ID of the router who generates the
   inter-AS reachability TLV.

The term “Router ID” is used as though it were an agreed term of art in IS-IS, 
but it’s not, to my knowledge. This is probably the root of the problem: IS-IS 
has a System Identifier or System-ID, which is notionally 1-8 bytes variable 
but AFAIK is generally (always?) 6 bytes. So it seems as though RFC 5316 could 
have been clearer in that regard, but quite probably did mean what you say 
above. 

So, I take it back, I think you and Éric are right, strictly speaking. 
Unfortunately it doesn’t look like simply removing the adjective “IPv4” will be 
sufficient, though. Let’s look at the whole paragraph in RFC 5316:

   The Router ID field of the inter-AS reachability TLV is 4 octets in
   length, which contains the Router ID of the router who generates the
   inter-AS reachability TLV.  The Router ID MUST be unique within the
   ISIS area.  If the router generates inter-AS reachability TLV with
   entire ISIS routing domain flooding scope, then the Router ID MUST
   also be unique within the entire ISIS routing domain.  The Router ID
   could be used to indicate the source of the inter-AS reachability
   TLV.

Now let’s look at the replacement paragraph:

   The Router ID field of the inter-AS reachability TLV is 4 octets in
   length, which contains the IPv4 Router ID of the router who generates
  

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

[John Scudder]

Hi Éric,

A few comments below.

> On Sep 16, 2022, at 4:27 AM, Éric Vyncke via Datatracker  
> wrote:
> 
> ## COMMENTS
> 
> ### Section 3.1
> 
> ```
>   The Router ID field of the inter-AS reachability TLV is 4 octets in
>   length, which contains the IPv4 Router ID of the router who generates
>   the inter-AS reachability TLV.  The Router ID SHOULD be identical to
>   the value advertised in the Traffic Engineering Router ID TLV
>   [RFC5305].  If no Traffic Engineering Router ID is assigned, the
>   Router ID SHOULD be identical to an IP Interface Address [RFC1195]
>   advertised by the originating IS.
> ```
> 
> AFAIK, the router ID is 'just' a 32-bit value that it is protocol version
> agnostic. So, s/IPv4 Router ID/Router ID/ ?
> 
> Suggest: s/IP Interface Address [RFC1195]/IPv4 Interface Address [RFC1195]/ ?

I wondered about this too when I was reviewing the document, and indeed RFC 
5305 just calls the TE Router ID a 4-octet value. But then RFC 6119 says,

   The TE Router ID TLV contains a stable IPv4 address that is routable,
   regardless of the state of each interface.

   Similarly, for IPv6, it is useful to have a stable IPv6 address
   identifying a TE node.  The IPv6 TE Router ID TLV is defined in
   Section 4.1.

So even though it was after the fact, I suppose calling the former the “IPv4 
Router ID” makes sense and just codifies what is apparently already the 
practice. The existence of the IPv6 TE Router ID, so named, is “the exception 
that proves the rule”. 

$0.02. The authors might have additional comments of course.

> ### Section 7
> 
> While Les was not an author of RFC 5316, he is an author of this I-D, so no
> more need to acknowledge him ;-)

I did make this point during my review and the authors chose to clarify that 
the supplied acknowledgments are a verbatim copy of what was in RFC 5316. So 
although this is a little unusual, it was a deliberate choice.

FYI, FWIW,

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

Re: [Lsr] [IANA #1239655] Re: Request for early allocation for pending IANA allocation for draft-ietf-lsr-ospfv3-srv6-extensions

[John Scudder]

Make it so. ;-)

—John

> On Sep 13, 2022, at 8:11 PM, Amanda Baber via RT  
> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John,
> 
> As the AD for this document, can you approve this early allocation request?
> 
> Document: 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-07*section-13.3__;Iw!!NEt6yMaO-gk!ENCElBIJKp0l6dmXPSMh7uvsQneP23JpuP2EZZRselhPORo72_eaQ0jhh39-m1lOgFtYMGYV-k9a7Qz8GCoxYDg$
> 
> Registry: 
> https://urldefense.com/v3/__https://www.iana.org/assignments/ospfv3-parameters__;!!NEt6yMaO-gk!ENCElBIJKp0l6dmXPSMh7uvsQneP23JpuP2EZZRselhPORo72_eaQ0jhh39-m1lOgFtYMGYV-k9a7Qz8mR545do$
> 
> thanks,
> Amanda
> 
>> On Tue Sep 13 20:11:54 2022, a...@cisco.com wrote:
>> IANA,
>> 
>> Please add the AC-Bit as documented in Section 13.3 to the early
>> codepoint allocations associated with this draft.
>> 
>> Thanks,
>> Acee
>> 
>> From: Ketan Talaulikar 
>> Date: Tuesday, August 30, 2022 at 11:54 AM
>> To: Acee Lindem 
>> Cc: Acee Lindem , lsr , "draft-ietf-lsr-
>> ospfv3-srv6-extensi...@ietf.org" > extensi...@ietf.org>
>> Subject: Request for early allocation for pending IANA allocation for
>> draft-ietf-lsr-ospfv3-srv6-extensions
>> 
>> Hi Acee/Chris,
>> 
>> Now that the WGLC is done for this document, would it be a good time
>> to request for early allocation for the pending item (OSPFv3
>> PrefixOption)?
>> 
>> Please refer: 
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-__;!!NEt6yMaO-gk!ENCElBIJKp0l6dmXPSMh7uvsQneP23JpuP2EZZRselhPORo72_eaQ0jhh39-m1lOgFtYMGYV-k9a7Qz8DhmX1J8$
>> ospfv3-srv6-extensions-07#section-13.3
>> 
>> Thanks,
>> Ketan
>> 
>> On Wed, Aug 24, 2022 at 12:11 AM Acee Lindem (acee)
>> mailto:a...@cisco.com>> wrote:
>> The Working Group Last Call (WGLC) has completed. There is more than
>> sufficient support for publication. As result of the WGLC discussion,
>> there have been some changes and these reflected in the -07 version.
>> 
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-__;!!NEt6yMaO-gk!ENCElBIJKp0l6dmXPSMh7uvsQneP23JpuP2EZZRselhPORo72_eaQ0jhh39-m1lOgFtYMGYV-k9a7Qz8mGshWSE$
>> extensions-07
>> 
>> Please review the changes resulting from the WGLC discussion. Note
>> that the locator TLV will now use the PrefixOptions field common to
>> other OSPFv3 LSAs advertising prefixes and will contain the Anycast
>> (AC-bit). This change is reflected in sections 6 and 7.1.
>> 
>> Thanks,
>> Acee
>> 
>> 
>> From: Lsr mailto:lsr-boun...@ietf.org>> on
>> behalf of "Acee Lindem (acee)"
>> mailto:40cisco@dmarc.ietf.org>>
>> Date: Friday, July 29, 2022 at 1:18 PM
>> To: lsr mailto:lsr@ietf.org>>
>> Cc: "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org> lsr-ospfv3-srv6-extensi...@ietf.org>" > extensi...@ietf.org> extensi...@ietf.org>>
>> Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for
>> SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected
>> Address)
>> 
>> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-__;!!NEt6yMaO-gk!ENCElBIJKp0l6dmXPSMh7uvsQneP23JpuP2EZZRselhPORo72_eaQ0jhh39-m1lOgFtYMGYV-k9a7Qz84oIwPFE$
>> extensions/
>> 
>> 
>> Thanks,
>> Acee & Chris
>> 
>> 
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[John Scudder]

Hi Tom,

Needless (?) to say, I’m sympathetic with your position, and thanks for 
bringing up the parallel case. I take it however, that you aren’t taking the 
position that this reorganization/restructuring/call it what you will needs to 
be done by draft-ietf-lsr-ospf-l2bundles, though? Right now it looks to me as 
though there’s not consensus that it *should* be done in 
draft-ietf-lsr-ospf-l2bundles, which suggests to me that,

- We should ask Ketan to revert to the version where the registry is left 
untouched (the “nothing” option),
- We should then send draft-ietf-lsr-ospf-l2bundles for IETF LC and proceed 
with the publication process, and concurrently,
- Someone who sees value in reorganizing the registry should write a standalone 
draft to do that, and propose it as a WG draft.

Any objection to that approach?

Thanks,

—John

> On Sep 12, 2022, at 5:33 AM, tom petch  wrote:
> 
> From: Lsr  on behalf of John Scudder 
> 
> Sent: 06 September 2022 22:04
> 
>> On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee)  wrote:
>> 
>>   I guess if we do decide to either abandon the reorganization suggestion 
>> altogether, or to pursue it as a separate draft, then 
>> draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of 
>> listing restrictions in their own subsections of the main spec, do you 
>> agree? Recall that we got here (in part) because it seemed strange to me to 
>> update the registry to list some restrictions, but not all of them.
>> 
>> [ACEE] This would be my choice except I wouldn't add the "L2 Member Bundle 
>> Attributes" restriction to the IANA registry unless we do it for all the 
>> Sub-TLVs as you suggest.
> 
> We agree; that was what I meant. All or nothing, either do the whole 
> reorganization (or whatever you want to call it) or back out the 05 change to 
> the IANA section and just roll with what was in 04 and earlier. Halfway 
> doesn’t make a lot of sense to me.
> 
> 
> All; you have to do it sometime, better sooner than later.
> 
> I see a close parallel with MPLS which got itself into a tangle, attempts to 
> clarify were rebuffed until eventually the problems were just too great and 
> the work was done.
> 
> Look at the TLVs registry in the IANA Multiprotocol Label Switching 
> Architecture (MPLS) Group.  I think that you need a strong reason not to 
> adopt a similar approach (if only for users who use MPLS as well as OSPF).  
> No need for ten columns, just a structured approach.
> 
> It took a lot of detailed review to get it right - Loa knows that well - but 
> I believe that the effort was worth it.
> 
> Tom Petch
> 
> —John

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

Re: [Lsr] AD review of draft-ietf-lsr-flex-algo-20

[John Scudder]

Hi Peter,

Thanks. I’ve requested IETF LC.

—John

> On Sep 12, 2022, at 7:36 AM, Peter Psenak  wrote:
> 
> 
> Hi John,
> 
> please see inline (##PP2)
> 
> On 09/09/2022 17:29, John Scudder wrote:
>> Hi Peter,
>> 
>> Thanks for your reply and for the ping.
>> 
>> Where necessary I’ve replied in line below. I’ve snipped any points that
>> are agreed and don’t need further discussion. I’ve also reviewed the -21
>> diffs, basically LGTM. It looks like you missed a few of the nits, I
>> don’t know if this was by choice or oversight. I’ve attached an edited
>> version of -21 that captures the remaining ones, plus a few new ones I
>> noticed. You can diff if you want to pick those up for inclusion in -22.
> 
> ##PP2
> I fixed all nits, hopefully.
> 
>> 
>>> On Aug 31, 2022, at 10:23 AM, Peter Psenak 
>>>  wrote:
>>> 
>>> [External Email. Be cautious of content]
>>> 
>>> 
>>> Hi John,
>>> 
>>> thanks a lot for the thorough review.
>>> 
>>> I incorporated all your edits and almost all of your comments.
>>> 
>>> For the few that I have not, please see inline (loop for ##PP):
>> 
>> [snip]
>> 
>>>>  Any change in the Flex-Algorithm definition may result in temporary
>>>>  disruption of traffic that is forwarded based on such Flex-Algorithm
>>>>  paths.  The impact is similar to any other event that requires
>>>>  network-wide convergence.
>>>> +
>>>> +jgs: IMO this would merit discussion in the Operational Considerations
>>>> +section.  In particular, is there any advice regarding how to
>>>> +stage/sequence FAD config changes in order to minimize disruption?
>>> 
>>> ##PP
>>> I don't really see much to add here. FAD changes the constraints used
>>> during the algo specific SPF and as such any change in it requires all
>>> routers to recompute the entire topology. In terms of the order of
>>> changes, I don't see why that would be significant and why someone would
>>> not want to advertise all changes at once if there are any multiple
>>> changes in the FAD.
>> 
>> I take your point, thanks. I guess about the most that you could say in
>> Operational Considerations would be something like
>> 
>> ---
>> 15.X  FAD Changes
>> 
>> As [Section 5.3] notes, a change in the Flex-Algorithm definition may
>> require network-wide SPF recomputation and network reconvergence. This
>> potential for disruption should be taken into consideration when
>> planning and making changes to the FAD.
> 
> ##PP2
> Added above to the Operational Consideration section.
> 
>> ---
>> 
>> Obvs, re-word as appropriate. IMHO it's worth elevating in the O.C.
>> section even if only briefly, but I don’t insist.
>> 
>> [snip]
>> 
>>>> +jgs: Are "sender" and "receiver" sufficiently clear to OSPF practitioners
>>>> +that there would be no ambiguity? I can think of two different ways
>>>> +to read them -- one is that the "sender" is the router that
>>>> +originates the LSA, and the "receiver" is any router that processes
>>>> +the LSA. I think that's what you mean. The other, pedantic, reading,
>>>> +is the "sender" is any router that puts the LSA on the wire, and the
>>>> +"receiver" is any router that takes the LSA from the wire, so anyone
>>>> +participating in flooding would be both a "sender" and a "receiver"
>>>> +at times.
>>>> +
>>>> +If this is how people write OSPF specs and talk about OSPF, fine.
>>>> +But if there are more precise terms than "sender" and "receiver" in
>>>> +use, it would be nice to use them.
>>> 
>>> ##PP
>>> send/receive is the standard term used, e.g
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8665*section-5__;Iw!!NEt6yMaO-gk!HAdyT2s3c5I_fktGSY3YPuQdVeF95m5Yb-utZWsGn9214bNEm1SkQ1dDgtbTL2tEJz4kJBwXudGrWyHF3P9zB8IEVqDz$
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8665*section-5__;Iw!!NEt6yMaO-gk!HAdyT2s3c5I_fktGSY3YPuQdVeF95m5Yb-utZWsGn9214bNEm1SkQ1dDgtbTL2tEJz4kJBwXudGrWyHF3P9zB8IEVqDz$>
>>> 
>>> I can replace sender with originator, if you prefer, but receiver would
>>> remain.
>> 
>> As you prefer. It’s not a big deal. I agree, by the way, that receiver
>> is unambiguous.
> 
> ##PP
&

Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[John Scudder]

> On Sep 6, 2022, at 5:00 PM, Acee Lindem (acee)  wrote:
> 
>I guess if we do decide to either abandon the reorganization suggestion 
> altogether, or to pursue it as a separate draft, then 
> draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of 
> listing restrictions in their own subsections of the main spec, do you agree? 
> Recall that we got here (in part) because it seemed strange to me to update 
> the registry to list some restrictions, but not all of them.
> 
> [ACEE] This would be my choice except I wouldn't add the "L2 Member Bundle 
> Attributes" restriction to the IANA registry unless we do it for all the 
> Sub-TLVs as you suggest.

We agree; that was what I meant. All or nothing, either do the whole 
reorganization (or whatever you want to call it) or back out the 05 change to 
the IANA section and just roll with what was in 04 and earlier. Halfway doesn’t 
make a lot of sense to me.

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

Re: [Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[John Scudder]

Hi Acee,

> On Sep 5, 2022, at 1:23 PM, Acee Lindem (acee)  wrote:
> 
> First of all, I think this IANA OSPFv3 Extended-LSA Sub-TLV specification, if 
> it is to be done at all, should be done in a separate draft.

I guess by “specification” you mean “registry reorganization”, right? I’m OK 
with that, though I think I will wait a little longer to see if other WG 
contributors want to weigh in.
 
> When we originally created the registry for RFC 8362, the purpose was avoid 
> Sub-TLV code point collisions while affording maximum reuse of Sub-TLV 
> definitions. It was NOT to avoid reading the specifications in order to 
> determine everywhere a Sub-TLV is allowed.

I agree that reading all the RFCs is (or should be) sufficient. My thoughts are 
as I mentioned in my earlier reply to Ketan — organizing the registry to 
reflect the restrictions imposed by the RFCs serves two possibly-useful 
purposes. First, it gathers the information in one place for quick reference. 
Second and more important, it reduces the chance that the author of a future 
spec might overlook the need to carefully specify where their sub-TLV can and 
can’t be used.

> In fact, I don’t believe IS-IS had yet adopted this IANA practice when this 
> became a WG document in 2007. OSPFv3 Extended LSAs took some time to 
> standardize as we held it until there were implementations and there weren’t 
> implementations until Segment Routing offered a strong incentive. 
>  
> If this information is to be represented in the IANA registry, I’d stay away 
> from columns with Y’s and N’s. Note that Sub-TLVs can nested so conceivably a 
> given Sub-TLV could be used by other Sub-TLVs.

Are there existing restrictions on the use of one sub-TLV within other sub-TLVs 
that would need to be captured, or are you just mentioning that for 
completeness? (Completeness is good of course.) If the latter, maybe one option 
could be a catch-all column, called something like “other restrictions on use” 
that can list other restrictions either in line or in a footnote with 
sub-bullets as you suggest.

> Rather, one could list the Sub-TLVs with the individual usages and references 
> (if different from the creation reference) as sub-bullets.

I can’t comment because I can’t quite picture what you’re describing, and how 
the registry would look?

I guess if we do decide to either abandon the reorganization suggestion 
altogether, or to pursue it as a separate draft, then 
draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of 
listing restrictions in their own subsections of the main spec, do you agree? 
Recall that we got here (in part) because it seemed strange to me to update the 
registry to list some restrictions, but not all of them.

Thanks,

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

Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[John Scudder]

Thanks Qin, modulo a few remaining editorial nits (that can be taken care of by 
the RFC editor if need be) this looks ready to me; I’ve requested IETF last 
call.

—John

> On Sep 5, 2022, at 9:22 AM, Qin Wu  
> wrote:
> 
> 
> Hi, John:
> The v-10 is posted, see our diff below:
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-10__;!!NEt6yMaO-gk!HwD1Ifh0JYKZJd08a0_G-rVhAdKeeLZpK7-YXH9YdLqDvEzqivIQ2g6vRxWDh2c_dlPglDDYH3qcYVer_d9zLGutJPam$
> 
> -Qin (on behalf of authors)
> -邮件原件-
> 发件人: John Scudder [mailto:jgs=40juniper@dmarc.ietf.org]
> 发送时间: 2022年9月5日 2:38
> 收件人: Qin Wu 
> 抄送: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr@ietf.org; 
> Dhruv Dhody ; Acee Lindem (acee) ; Les 
> Ginsberg (ginsberg) 
> 主题: Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09
> 
> Hi Qin and all,
> 
> Looks like we’ve agreed on all the points under discussion, I’ll look forward 
> to reviewing the next revision.
> 
> Thanks,
> 
> —John

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

[Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[John Scudder]

Hi Ketan,

Seems like a good plan. Comments below.

> On Sep 5, 2022, at 3:31 AM, Ketan Talaulikar  wrote:
> 
> I am personally OK with adopting the "boy scout" approach here - even if it 
> might be seen as a scope creep. 
> 
> Following is a proposal for feedback from you and the WG:
> 
> We'll first need 9 columns in the "OSPFv3 Extended-LSAs Sub-TLVs" registry at 
> this point to indicate the applicability of each sub-TLV to its parent 
> TLV(s). More may be required as we go along and new TLVs are added.
> 
> 1) Router Link (RL)
> 2) Attached Routers (AR)
> 3) Inter-Area Prefix (IeAP)
> 4) Inter-Area Router (IAR)
> 5) External Prefix (EP)
> 6) Intra-Area Prefix (IaAP)
> 7) IPv6 Link-Local Address (6LL)
> 8 IPv4 Link-Local Address (4LL)
> 9) Extended Prefix Range (EPR)
> 
> Then we will need the 10th column to indicate applicability to the L2 Bundle 
> Member Attribute (L2BM) Sub-TLV.
> 
> These columns may become very complicated and not sure how they would look in 
> the IANA registry. 

When you say “very complicated” do you simply mean that the table would be 
wide? Because all I’m envisioning is ten additional columns in the registry, 
with each cell containing either “Y” or “N”; this doesn’t seem inherently 
complex to me. This approach is familiar from some of the IS-IS registries, 
consider 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-neighbor-information
 for example. Only six columns in that one, not ten, but the idea is the same. 

> I am not aware of discussions (if any) that took place during RFC8362 on this 
> sharing of sub-TLV space. Perhaps the authors of RFC8362 and chairs can also 
> share their inputs. The other (more cleaner and traditional approach IMHO) 
> might have been to have separate spaces for each TLV.

True, the WG could decide to reorganize it to give each type its own space in 
its own registry, where the first 32 code points in each space just happen to 
be the same. I guess the downside would be, for any sub-TLV that’s applicable 
to more than one type, you’d have to do multiple registrations — but you have 
to specify applicability for the multiple types in the unified registry anyway, 
so it all works out to the same thing. (I think we did this kind of 
reorganization for BMP, if I recall correctly.)

If the sub-TLV number space were small, there would be a stronger motivation to 
reorganize into multiple registries, to conserve space, but with a 2^16 space 
it doesn’t seem like a real concern. So AFAICT it comes down to a matter of 
taste.

> In any case, I think we should wait for WG's input before making such 
> (feature creep) changes.

Agreed. To raise visibility and hopefully elicit more input, I’ve updated the 
subject line and explicitly cc’d Acee (in his capacity as shepherd). Probably 
there will be more engagement after the U.S. Labor Day holiday is over.

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

Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[John Scudder]

Hi Qin and all,

Looks like we’ve agreed on all the points under discussion, I’ll look forward 
to reviewing the next revision.

Thanks,

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

Re: [Lsr] AD review of draft-ietf-lsr-ospf-l2bundles-04

[John Scudder]

> On Sep 3, 2022, at 4:46 AM, Ketan Talaulikar  wrote:
> 
> Hi John,
> 
> Thanks again for your quick response.
> 
> Regarding the OSPFv3 Extended LSA registries, it is a bit challenging to do 
> what (I think) you are asking for. We have a bunch (8 today and a remote 
> possibility of more being added) of E-LSAs and all of them share the same 
> E-LSA TLV space (where more TLVs can be expected to be defined). And then, 
> for all of these E-LSA TLVs, we have a single shared E-LSA sub-TLV (at any 
> level of hierarchy). So potentially, we can have a rather complicated set of 
> columns depending on how we want to go about it.

So, are you saying it would be too messy to structure the registry that way (I 
don’t think it would), or that doing that work represents scope creep for the 
present spec (I agree)?

Regarding scope creep, there are at least two ways to think of this —

1. It’s worth doing but this is not the place. Let’s propose a new WG draft 
that’s just a registry maintenance draft.

2. It’s worth doing, and we will take on the extra effort of doing it in this 
draft, to spare the WG the overhead of processing a whole new draft. Kind of 
the Boy Scout ethos of leaving the campsite cleaner than you found it.

In case 1, I guess the question then becomes, if there’s a registry maintenance 
draft in the offing, is it even worth introducing the “X” state, which IMO 
seems like a bit of a forced fit compared to a simple matrix with Y/N in each 
cell? Maybe since you’ve already done that much of an audit on the registry, 
introduce two columns, one for L2BMA sub-TLV and one for RL sub-TLV, with Y/N 
in each column?

> That is why, here, we are limiting to the current need - to indicate the 
> applicability of a sub-TLV to L2 Bundle Member TLV.
> 
> I am open to your and WG's suggestions on this.

I, too, would like to hear the WG’s input.

Thanks,

—John

> 
> Thanks,
> Ketan
> 
> 
> On Fri, Sep 2, 2022 at 10:23 PM John Scudder  wrote:
> Hi Ketan,
> 
> Thanks for the update.
> 
> > On Sep 2, 2022, at 9:16 AM, Ketan Talaulikar  wrote:
> > 
> > Since the OSPFv3 registry is shared for all OSPFv3 Extended LSA TLVs' 
> > sub-TLVs, we need another flag X for those sub-TLVs that are not associated 
> > with the Router Link TLV.
> 
> Good point. But, doesn’t that suggest that if we’re going to annotate the 
> registry anyway, it should be annotated to indicate applicability for each 
> sub-TLV type? That would clean up the presentation from Y/N/X to just Y/N per 
> column. It would add a lot more columns but we don’t pay by the column. :-)
> 
> If there’s some reason this wouldn’t be valuable that’s OK but I’d like to 
> understand what makes Router Link and L2 Bundle Member need special treatment 
> that the other sub-TLVs don’t need.
> 
> Thanks,
> 
> —John

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

Re: [Lsr] AD review of draft-ietf-lsr-ospf-reverse-metric-05

[John Scudder]

LGTM. IETF LC requested.

—John

> On Sep 3, 2022, at 4:51 AM, Ketan Talaulikar  wrote:
> 
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John,
> 
> Thanks for your quick response and please check inline below for response 
> with KT2.
> 
> We've also posted an update with the changes discussed below: 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-07
> 
> 
> On Sat, Sep 3, 2022 at 1:03 AM John Scudder  wrote:
> Hi Ketan,
> 
> LGTM generally. Regarding your uses of SHOULD, the updates to refer to 
> Section 7 are helpful. I agree that the other uses are innocuous enough as to 
> be obvious to “one versed in the art”; we shall see if other reviewers agree. 
> I personally am not crazy about RFC 2119 keywords directed at operators 
> rather than implementors (e.g. the first use in Section 10) but I accept that 
> it’s a common pattern.
> 
> Regarding the “don’t write bugs” text, if I were reviewing the prior RFC I 
> would also have flagged that one too. I don’t insist that it be removed, but 
> gosh it doesn’t seem to add anything actionable.
> 
> KT2> I agree and I've removed that text.
>  
> 
> Remaining open items —
> 
> Minor: 
> 
> For this text:
> 
>For the use case in Section 2.1, it is RECOMMENDED that the network
>operator limit the period of enablement of the reverse metric
>mechanism only for the duration of a network maintenance window.
> 
> I suggest
> 
>For the use case in Section 2.1, it is RECOMMENDED that the network
>operator limit the period of enablement of the reverse metric
>mechanism to be only the duration of a network maintenance window.
> 
> 
> KT2> Ack
>  
> Nits:
> 
> - I had suggested changing “4 octet” to “4 octets”, was this missed or 
> deliberately not adopted?
> - s/safegaurd/safeguard/
> 
> KT2> Missed and now fixed.
> 
> Thanks,
> Ketan
>  
> 
> Regards,
> 
> —John

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

Re: [Lsr] AD review of draft-ietf-lsr-ospf-bfd-strict-mode-05

[John Scudder]

Thanks, Ketan. Enough tweaking :-), I’ve requested it move to IETF last call.

—John

> On Sep 3, 2022, at 5:03 AM, Ketan Talaulikar  wrote:
> 
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John,
> 
> Thanks for your quick response and clarifications. Please check inline below 
> for responses with KT3.
> 
> We've also posted an update with the changes discussed below as well as the 
> formal "updates RFC2328" point that was discussed earlier in this thread: 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-07
> 
> 
> On Sat, Sep 3, 2022 at 2:06 AM John Scudder  wrote:
> Hi Ketan,
> 
> My comments in line below.
> 
> > On Sep 2, 2022, at 6:37 AM, Ketan Talaulikar  wrote:
> > 
> > Hi John,
> > 
> > Please check inline below for responses with KT2
> > 
> > 
> > On Thu, Sep 1, 2022 at 10:42 PM John Scudder  wrote:
> > Hi Ketan,
> > 
> > Thanks for the prompt update. I have one question about your edits. In 
> > Section 6, I had suggested
> > 
> > OLD:
> >Implementations MAY
> >provide a local configuration option to specifically enable BFD
> >operation in OSPF BFD strict-mode only. 
> > 
> > NEW (my suggestion):
> >Implementations MAY
> >provide a local configuration option to require BFD strict-mode.
> > 
> > NEW (your revision):
> >Implementations MAY
> >provide a local configuration option to require BFD operation in OSPF
> >BFD strict-mode only.  
> > 
> > I’m wrestling with whether this option is supposed to mean “the adjacency 
> > must not establish unless BFD comes up first” or “if the neighbor supports 
> > BFD, then BFD must come up first before the adjacency is allowed to 
> > establish”.
> > 
> > KT2> I meant the former. So this is like "force" BFD strict-mode operation. 
> > The default mode is negotiation when strict-mode is enabled.
> >  
> > I.e., as written I can make the argument that if my neighbor doesn’t 
> > advertise the B-bit, then it’s fine for the adjacency to come up as long as 
> > BFD isn’t run at all. The former interpretation seems more operationally 
> > useful, but the spec text is ambiguous.
> > 
> > I’m not sure my proposed text even resolved that problem, on reflection. In 
> > any case, I would be happier if the ambiguity were resolved somehow.
> > 
> > KT2> How about the following?
> > 
> > Implementations MAY provide a local configuration option to force BFD 
> > operation only in 
> > OSPF BFD strict-mode (i.e, adjacency will not come up unless BFD session is 
> > established).
> 
> It gets the job done; good enough.
> 
> KT3> Thanks. 
>  
> 
> [snip]
> 
> > > Whenever the neighbor state transitions to Down state, the removal of
> > > the BFD session associated with that neighbor SHOULD be requested by
> > > @@ -246,6 +281,14 @@
> > > result in the deletion and creation of the BFD session respectively
> > > when OSPF is the only client interested in the BFD session with the
> > > neighbor address.
> > > +   
> > > +jgs: Please do a global search for the RFC 2119 keyword SHOULD and in
> > > +each instance, consider whether it can be a MUST, or the normal English
> > > +word "should" (in lower or mixed case).  If SHOULD is the appropriate
> > > +keyword, please supply some detail about when it would be appropriate
> > > +for an implementor to disregard the SHOULD.  (The one place where I
> > > +thought "should" might be the appropriate choice is in the Operations &
> > > +Management Considerations section.)
> > > 
> > > KT> In this specific case, we are discussing implementation specifics 
> > > that are also applicable without the strict-mode, and hence introducing a 
> > > MUST here was not appropriate. We could change it to "should" if that 
> > > would be more appropriate. Looking for feedback if this change is 
> > > required.
> > 
> > This actually motivates the question, why does that paragraph need to be 
> > there at all? Was the base behavior underspecified and in need of update?
> > 
> > KT2> Yes, I believe has been underspecified in RFC5882.
> >  
> > Is this just a nota bene for the implementor? Should you more clearly 
> > signal that’s what it is? But this is in any case tangential to the main 
> > point; we can return to it later perhaps. I did note the peculiar nature of 
> > the parag

Re: [Lsr] AD review of draft-ietf-lsr-ospf-bfd-strict-mode-05

[John Scudder]

Hi Ketan,

My comments in line below.

> On Sep 2, 2022, at 6:37 AM, Ketan Talaulikar  wrote:
> 
> Hi John,
> 
> Please check inline below for responses with KT2
> 
> 
> On Thu, Sep 1, 2022 at 10:42 PM John Scudder  wrote:
> Hi Ketan,
> 
> Thanks for the prompt update. I have one question about your edits. In 
> Section 6, I had suggested
> 
> OLD:
>Implementations MAY
>provide a local configuration option to specifically enable BFD
>operation in OSPF BFD strict-mode only. 
> 
> NEW (my suggestion):
>Implementations MAY
>provide a local configuration option to require BFD strict-mode.
> 
> NEW (your revision):
>Implementations MAY
>provide a local configuration option to require BFD operation in OSPF
>BFD strict-mode only.  
> 
> I’m wrestling with whether this option is supposed to mean “the adjacency 
> must not establish unless BFD comes up first” or “if the neighbor supports 
> BFD, then BFD must come up first before the adjacency is allowed to 
> establish”.
> 
> KT2> I meant the former. So this is like "force" BFD strict-mode operation. 
> The default mode is negotiation when strict-mode is enabled.
>  
> I.e., as written I can make the argument that if my neighbor doesn’t 
> advertise the B-bit, then it’s fine for the adjacency to come up as long as 
> BFD isn’t run at all. The former interpretation seems more operationally 
> useful, but the spec text is ambiguous.
> 
> I’m not sure my proposed text even resolved that problem, on reflection. In 
> any case, I would be happier if the ambiguity were resolved somehow.
> 
> KT2> How about the following?
> 
> Implementations MAY provide a local configuration option to force BFD 
> operation only in 
> OSPF BFD strict-mode (i.e, adjacency will not come up unless BFD session is 
> established).

It gets the job done; good enough.
 
[snip]

> > Whenever the neighbor state transitions to Down state, the removal of
> > the BFD session associated with that neighbor SHOULD be requested by
> > @@ -246,6 +281,14 @@
> > result in the deletion and creation of the BFD session respectively
> > when OSPF is the only client interested in the BFD session with the
> > neighbor address.
> > +   
> > +jgs: Please do a global search for the RFC 2119 keyword SHOULD and in
> > +each instance, consider whether it can be a MUST, or the normal English
> > +word "should" (in lower or mixed case).  If SHOULD is the appropriate
> > +keyword, please supply some detail about when it would be appropriate
> > +for an implementor to disregard the SHOULD.  (The one place where I
> > +thought "should" might be the appropriate choice is in the Operations &
> > +Management Considerations section.)
> > 
> > KT> In this specific case, we are discussing implementation specifics that 
> > are also applicable without the strict-mode, and hence introducing a MUST 
> > here was not appropriate. We could change it to "should" if that would be 
> > more appropriate. Looking for feedback if this change is required.
> 
> This actually motivates the question, why does that paragraph need to be 
> there at all? Was the base behavior underspecified and in need of update?
> 
> KT2> Yes, I believe has been underspecified in RFC5882.
>  
> Is this just a nota bene for the implementor? Should you more clearly signal 
> that’s what it is? But this is in any case tangential to the main point; we 
> can return to it later perhaps. I did note the peculiar nature of the 
> paragraph on my first read-through, and figured it did no harm to clarify 
> that this is how implementations should be done regardless — but in any case 
> I don’t see why that makes MUST inappropriate.
> 
> KT2> This is at the end and internal behavior between OSPF and BFD within a 
> system. It may be possible to do this differently and yet exhibit the same 
> external behavior. That is why either SHOULD or should seem more appropriate.

If I understand the situation correctly (and I haven’t gone and re-checked what 
RFC 5882 says), that sounds like a case for “should”. You can change it (and 
the one subsequent SHOULD that’s in the same category, total three) or not, at 
your discretion.

> > In some other places, the behavior may be applicable and shared with "base" 
> > BFD and hence we felt not appropriate to make it a MUST. However, we have 
> > taken the opportunity to suggest a desirable behavior. We look for feedback 
> > if any specific instance needs change or clarification.
> 
> I have a different take on the appropriate use of SHOULD vs. MUST. Let’s look 
> at what RFC 211

Re: [Lsr] AD review of draft-ietf-lsr-ospf-reverse-metric-05

[John Scudder]

Hi Ketan,

LGTM generally. Regarding your uses of SHOULD, the updates to refer to Section 
7 are helpful. I agree that the other uses are innocuous enough as to be 
obvious to “one versed in the art”; we shall see if other reviewers agree. I 
personally am not crazy about RFC 2119 keywords directed at operators rather 
than implementors (e.g. the first use in Section 10) but I accept that it’s a 
common pattern.

Regarding the “don’t write bugs” text, if I were reviewing the prior RFC I 
would also have flagged that one too. I don’t insist that it be removed, but 
gosh it doesn’t seem to add anything actionable.

Remaining open items —

Minor: 

For this text:

   For the use case in Section 2.1, it is RECOMMENDED that the network
   operator limit the period of enablement of the reverse metric
   mechanism only for the duration of a network maintenance window.

I suggest

   For the use case in Section 2.1, it is RECOMMENDED that the network
   operator limit the period of enablement of the reverse metric
   mechanism to be only the duration of a network maintenance window.

Nits:

- I had suggested changing “4 octet” to “4 octets”, was this missed or 
deliberately not adopted?
- s/safegaurd/safeguard/

Regards,

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

Re: [Lsr] AD review of draft-ietf-lsr-ospf-l2bundles-04

[John Scudder]

Hi Ketan,

Thanks for the update.

> On Sep 2, 2022, at 9:16 AM, Ketan Talaulikar  wrote:
> 
> Since the OSPFv3 registry is shared for all OSPFv3 Extended LSA TLVs' 
> sub-TLVs, we need another flag X for those sub-TLVs that are not associated 
> with the Router Link TLV.

Good point. But, doesn’t that suggest that if we’re going to annotate the 
registry anyway, it should be annotated to indicate applicability for each 
sub-TLV type? That would clean up the presentation from Y/N/X to just Y/N per 
column. It would add a lot more columns but we don’t pay by the column. :-)

If there’s some reason this wouldn’t be valuable that’s OK but I’d like to 
understand what makes Router Link and L2 Bundle Member need special treatment 
that the other sub-TLVs don’t need.

Thanks,

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

Re: [Lsr] [Editorial Errata Reported] RFC2328 (7112)

[John Scudder]

This looks right. If there are any objections to verifying it, please let me 
know.

—John

> On Sep 1, 2022, at 2:39 PM, RFC Errata System  
> wrote:
> 
> 
> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
> 
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7112__;!!NEt6yMaO-gk!FJynD-y4c4yWDb91yTvFViobefnoM7wxDCIcBMiV4r0jFG8WE4jsCzW7xMBABvx2TwtPDHYBucjBuYoTMPupgw$
> 
> --
> Type: Editorial
> Reported by: Renato Westphal 
> 
> Section: 10.2
> 
> Original Text
> -
>NegotiationDone
>The Master/Slave relationship has been negotiated, and DD
>sequence numbers have been exchanged.  This signals the
>start of the sending/receiving of Database Description
>packets.  For more information on the generation of this
>event, consult Section 10.8.
> 
> Corrected Text
> --
>NegotiationDone
>The Master/Slave relationship has been negotiated, and DD
>sequence numbers have been exchanged.  This signals the
>start of the sending/receiving of Database Description
>packets.  For more information on the generation of this
>event, consult Section 10.6.
> 
> Notes
> -
> The generation of the NegotiationDone event is specified in Section 10.6 (not 
> Section 10.8).
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --
> RFC2328 (no draft string recorded)
> --
> Title   : OSPF Version 2
> Publication Date: April 1998
> Author(s)   : J. Moy
> Category: INTERNET STANDARD
> Source  : Open Shortest Path First IGP
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG

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

Re: [Lsr] AD review of draft-ietf-lsr-ospf-bfd-strict-mode-05

[John Scudder]

Hi Ketan,

Thanks for the prompt update. I have one question about your edits. In Section 
6, I had suggested

OLD:
   Implementations MAY
   provide a local configuration option to specifically enable BFD
   operation in OSPF BFD strict-mode only. 

NEW (my suggestion):
   Implementations MAY
   provide a local configuration option to require BFD strict-mode.

NEW (your revision):
   Implementations MAY
   provide a local configuration option to require BFD operation in OSPF
   BFD strict-mode only.  

I’m wrestling with whether this option is supposed to mean “the adjacency must 
not establish unless BFD comes up first” or “if the neighbor supports BFD, then 
BFD must come up first before the adjacency is allowed to establish”. I.e., as 
written I can make the argument that if my neighbor doesn’t advertise the 
B-bit, then it’s fine for the adjacency to come up as long as BFD isn’t run at 
all. The former interpretation seems more operationally useful, but the spec 
text is ambiguous.

I’m not sure my proposed text even resolved that problem, on reflection. In any 
case, I would be happier if the ambiguity were resolved somehow.

Other comments below.

> On Sep 1, 2022, at 11:36 AM, Ketan Talaulikar  wrote:

[snip]

>  Status of This Memo
> @@ -92,10 +92,19 @@
> protocols like OSPFv2 [RFC2328] and OSPFv3 [RFC5340] to detect
> connectivity failures for established adjacencies faster than the
> OSPF hello dead timer detection and trigger rerouting of traffic
> -   around the failure.  The use of BFD for monitoring routing protocols
> +   around the failure.  The use of BFD for monitoring routing protocol
> adjacencies is described in [RFC5882].
>  
> -   When BFD monitoring is enabled for OSPF adjacencies, the BFD session
> +jgs: In the paragraph below, I found the flow of reading disrupted by
> +the dawning realization that it's describing the status quo prior to
> +introduction of this spec, i.e. the shortcomings that drove development
> +of the spec. I've proposed an additional first clause that might help
> +mitigate that, feel free to use it if you like.  (It's a little 
> +inelegant, you might want to do a more intrusive edit instead, up to
> +you.)
> 
> KT> Ack. I've modified the text a little differently than your suggestion. 
> Please let me know if it works.

Yes, that’s fine, thanks.

[snip]

> +jgs: I expect that taken as a whole, this document is clear enough to
> +enable an implementor to do the right thing, and that's the main goal.
> +It does seem to me however that "updating the state machine" by means
> +of putting a few notes into one of the states isn't the most thorough
> +way of doing it -- probably if you were doing this from the get-go you'd
> +introduce a new substate called "waiting for BFD establishment" or 
> +something like that, and then transition to it from Init at the appropriate
> +time. Or something like that, I'm just making things up on the fly here. 
> +Likewise you'd introduce a new "BFD comes up" event that gets you out of
> +your new state and back to the main flow of the state machine. Instead 
> +that's encapsulated in the note you've added to Init.
> +
> +I don't want a return to the Bad Old Days where we spent months of our
> +lives wrangling over state machines in the Routing Area (if you missed
> +that time count yourself lucky). However, it would make me feel better to
> +know that the WG has at least considered the question and decided to move
> +ahead without doing a full update to the state machine. So, I'd appreciate
> +a bit of discussion on this point, thanks.
> 
> KT> I don't remember this discussion on the mailer. I do remember some 
> discussion during an initial presentation of this draft to the WG though not 
> sure if it was during the session or offline. The introduction of a new state 
> would result in far more intrusive changes to implementations. We would have 
> this state whether or not the strict-mode is in use (BFD itself is optional). 
> It was simpler to update the INIT state as proposed by the draft instead. 
> We've added text in the Operations section so implementations show this 
> additional BFD wait information along with the adjacency state and 
> transitions. That should help in troubleshooting and operations.

I’m satisfied that you’ve considered it, that the issue has been raised on the 
WG list (it has now) and that anyone who wants to comment has had the 
opportunity (they do, now).

> +Also: when you write "This document updates ... [RFC2328]" it seems like
> +there's a decent chance that someone's going to ask if the document should
> +formally Update RFC 2328.  If you're not going to use the updates header
> +(and I don't insist you do) you might at least consider the reasons such
> +an update isn't called for. It might be helpful too, to update the 
> +shepherd write-up with some text saying the WG considered the question.
> 
> KT> This is a good point and at least I was not sure if doing the formal 
> 

[Lsr] AD review of draft-ietf-lsr-ospf-l2bundles-04

[John Scudder]

Dear Authors,

Thanks for this short, clean, document. I have no nits (!!) and only one 
substantive comment to discuss.

In Figures 2 and 3, you annotate all the sub-TLVs from the relevant OSPFv2 and 
OSPFv3 registries, to indicate whether those sub-TLVs are, or are not, 
applicable in the context of the L2 Bundle Member Attribute Sub-TLV. It seems 
to me that it would be helpful to update the registries themselves, to add a 
column with this information. In addition to making the information easier to 
find, it would also reduce the risk of future document authors forgetting to 
specify this information. (It’s all very well for your spec to say that future 
documents MUST supply this information, but such mandates on future document 
authors are hard to enforce consistently, absent some process. Updating the 
IANA registry would provide that process.)

Related, the OSPFv3 registry now has three additional code points, beyond those 
you annotate. I guess you should update Figure 3 to specify Y/N for code points 
30-32.

Thanks,

—John


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

Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[John Scudder]

Hi Qin,

Thanks for your reply, and Dhruv, Acee, and Les for your subsequent remarks. 
I’m rolling all my comments together into this reply to Qin’s message. Anything 
that’s settled I’ve snipped out, remaining items discussed in line.

> On Aug 25, 2022, at 5:21 AM, Qin Wu  
> wrote:

[snip]

> +jgs: I don't find any place where you explicitly mention that the 
> +sub-TLVs you define are identical for both OSPF and IS-IS. Please 
> +do make this explicit.
>  
> 
> [Qin Wu] We authors add explicit statement in section 3 to say
> 
> “
> 
>  
> 
>In addition, the sub-TLVs defined in this document (i.e.,Section 3.2,
> 
> Section 3.3) are used identically in both OSPF and IS-IS.
> 
> ”
> 
> Hope this addresses your comment.

Les’s subsequent remarks have convinced me that it will be better to explicitly 
define the sub-TLVs separately for the two protocols. Assuming you do so, this 
becomes moot.

>  3.2.  KEY-ID Sub-TLV
>  
> -   The KEY-ID sub-TLV specifies a key that can be used by the PCC to
> +   The KEY-ID sub-TLV specifies an identifier that can be used by the PCC to
> identify the TCP-AO key [RFC5925].
>  
> The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried within
> @@ -233,6 +267,14 @@
>  
>Reserved: MUST be set to zero while sending and ignored on
>receipt.
> +  
> +jgs: what is the size of the Reserved field?  I'm guessing it's three 
> +octets, to align the sub-TLV to a word boundary, but you need to say.
> +[Qin Wu] Yes, it can be inferred from 4 octets length and 1 octet KEY ID.
> 
> But we can make it explicitly.

Actually, why do you have a Reserved field anyway? If it’s just padding to get 
32-bit alignment — in OSPF, doesn’t that come “for free” without need for 
explicitly defining the field (as we covered in our discussion of the 
key-chain-name sub-TLV), and in IS-IS there is no need for padding, so why burn 
the bytes?

If you’re reserving the field on purpose for some contemplated future use, 
that’s fine of course. But otherwise it seems to me you could remove it. 
However, see also my further comments below under KEY-CHAIN-NAME.

> +A diagram of the style used in RFC 5088 would make this more evident 
> +since presumably you'd show the Reserved field in the diagram.  I 
> +don't insist you add diagrams, but they do tend to help the document's
> +readability so maybe consider it for this and also §3.3.
>  [Qin Wu] This has been discussed on the list before, it is intentional not 
> use diagram
> 
> for IGP since OSPF uses diagram for TLV format while ISIS not.

This also becomes moot assuming you follow Les’s recommendation to have 
separate definitions for the OSPF and IS-IS sub-TLVs. In that case you would 
presumably follow the OSPF format for the OSPF definition, and the IS-IS format 
for the IS-IS definition.

>  3.3.  KEY-CHAIN-NAME Sub-TLV
>  
> @@ -241,9 +283,9 @@
>  
> The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV carried
> within the IS-IS Router Information Capability TLV when the
> -   capability flag bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to
> +   capability flag bit of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to
> indicate TCP Authentication Option (TCP-AO) support.  Similarly, this
> -   sub-TLV MAY be present in the PCED TLV carried within OSPF Router
> +   sub-TLV MAY be present in the PCED TLV carried within the OSPF Router
> Information LSA when the capability flag bit of PCE-CAP-FLAGS sub-TLV
> in OSPF is set to indicate TCP-AO support.
>  
> @@ -257,6 +299,57 @@
>identify the key chain.  It SHOULD be a string of printable ASCII
>characters, without a NULL terminator.  The sub-TLV MUST be zero-
>padded so that the sub-TLV is 4-octet aligned.
> +  
> +jgs: Shouldn't your SHOULD be a MUST? If not, what are the non-ASCII 
> +characters that are allowed, and under what circumstances? 
> +
> +For that matter, why are you restricting the key chain name to ASCII?
> +You cite RFC 8177 above. Looking at 8177, it defines a key-chain name
> +as a YANG string, and RFC 7950 tells us that for a YANG string:
> +
> +   Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646]
> +   characters, including tab, carriage return, and line feed but
> +   excluding the other C0 control characters, the surrogate blocks, and
> +   the noncharacters.
> +   
> +If you really do want to restrict the alphabet in your extension, I 
> +think you need to explain why, or otherwise you need to support the
> +same alphabet RFC 8177 does.
> 
> 
> [Qin Wu]: Okay.We can align with what RFC8177 does.

N.b. I think Dhruv and Acee’s suggestions are on point.

> +Next question, what does the Length field indicate, exactly?  Is it the
> +length of the string?  Presumably so, since there is no termination
> +character.  Please say so, and say what the units are (e.g., "Length:
> +length of the Key Name field, in octets").
> +
> +Finally, at the end of the description of the Key Name field, 

Re: [Lsr] AD review of draft-ietf-lsr-pce-discovery-security-support-09

[John Scudder]

Les, thanks for the followup, and the sanity-check.

> On Aug 26, 2022, at 3:04 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Rather than do what John suggests below (have two lengths in the encoding), 
> please define distinct formats for each protocol.
> This should be done for the KEY-ID sub-TLV as well.
> This is not only consistent with the behavior of each protocol, it is 
> consistent with what has been done in RFCs 5088/5089.
>  
> Using the same sub-TLV code point across both protocols is fine since we 
> constrain it to sub-TLVs under the PCED advertisement – but please - protocol 
> specific sub-TLV format definitions always.

This makes good sense to me. It will take another page or two in the draft, but 
will make it more readable and implementable, IMO.

Thanks,

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

Re: [Lsr] AD review of draft-ietf-lsr-isis-rfc5316bis-02

[John Scudder]

LGTM, thanks.

—John

> On Aug 19, 2022, at 1:38 AM, Les Ginsberg (ginsberg)  
> wrote:
> 
> John -
> 
> V3 of the draft has been posted which I believe addresses all of your 
> comments.
> 
> Please let me know if there are remaining issues.
> 
> Note that a few additional format diffs were introduced by the new author 
> tools (not directly by me).
> 
>   Les
> 
>> -Original Message-
>> From: John Scudder 
>> Sent: Thursday, August 18, 2022 8:46 AM
>> To: Les Ginsberg (ginsberg) 
>> Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr@ietf.org
>> Subject: Re: AD review of draft-ietf-lsr-isis-rfc5316bis-02
>> 
>> Hi Les,
>> 
>> Thanks for your prompt reply. My comments in line below.
>> 
>>> On Aug 18, 2022, at 12:49 AM, Les Ginsberg (ginsberg)
>>  wrote:
>> 
>> [snipped]
>> 
>>> I have a couple of other points I’ll raise here instead of in line.
>>> 
>>> 1. I was a little surprised in the Acknowledgements to see that Les is
>> thanking Les. :-) It’s OK of course if you want to do it that way, but maybe
>> you want to give that section one more look?
>>> 
>>> [LES:] As you no doubt surmised; we simply copied that text verbatim from
>> RFC 5316 – on which I was not an author. That statement is true as regards
>> RFC 5316, which is explicitly mentioned in the paragraph.
>>> I have no particular preference here – if the IETF has a policy on this I am
>> happy to follow it. 
>> 
>> [JGS]
>> 
>> There’s no IETF-wide policy, Acks are at the author’s discretion more than
>> any other section. I’m not going to go dig up other bis documents but I seem
>> to recall seeing a format more like this used in others —
>> 
>> ---
>> NN. Acknowledgements
>> 
>> The authors of the present document would like to thank (authors’
>> discretion; if nobody then just leave this out).
>> 
>> RFC 5316 included the following Acknowledgements section:
>> 
>>   The authors would like to thank Adrian Farrel, Jean-Louis Le Roux,
>>   Christian Hopps, Les Ginsberg, and Hannes Gredler for their review
>>   and comments on this document.
>> —
>> 
>> Or sometimes the old acks are not carried forward but left to decorate the
>> original document only, although in this case where you’re doing a tightly-
>> scoped update I can see why you want to retain them.
>> 
>> [/JGS]
>> 
>>> 2. More substantively, the phrase “… when the TE Router ID is needed to
>> reach all routers …” or one like it, occurs many places in the document. I 
>> see
>> that this was part of the base RFC 5306 but it did introduce some confusion
>> for me, because there’s more than one possible reading, including
>>> 
>>> - when the TE Router ID has to be known by all routers
>>> - when in order to establish reachability to all routers, the TE Router ID 
>>> is
>> needed
>>> 
>>> [LES:] I think the latter interpretation is the correct one. And I think the
>> existing text conveys that when the text is “the TE Router ID is needed to
>> reach all routers”. But there are some places where the text is “the TE 
>> Router
>> ID needs to reach all
>>>   Routers” – the use of the active tense (“needs”) is inappropriate.
>>> Would it be acceptable to change only the places where the in appropriate
>> text is used?
>> 
>> [JGS]
>> 
>> That seems fine. I continue to think that the passive voice text is
>> unnecessarily ambiguous too, but it’s at worst a minor impediment to
>> consuming the spec so I’m happy to leave it to your discretion.
>> 
>> [/JGS]
>> 
>>> I leave it to you to decide whether or not to fix this. Clearly RFC 5306 
>>> stood
>> for years with that wording and presumably it didn’t create a problem (or at
>> least nobody raised an erratum) so I’m comfortable with either outcome.
>>> 
>>> Thanks,
>>> 
>>> —John
>>> 
>>> --- draft-ietf-lsr-isis-rfc5316bis-02.txt   2022-08-17 
>>> 14:21:33.0 -
>> 0400
>>> +++ draft-ietf-lsr-isis-rfc5316bis-02-jgs-comments.txt  2022-08-17
>> 14:42:45.0 -0400
>>> @@ -22,14 +22,15 @@
>>>This document describes extensions to the Intermediate System to
>>>Intermediate System (IS-IS) protocol to support Multiprotocol Label
>>>Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
>>> -   (TE) for multiple Autonomous Systems (

Re: [Lsr] AD review of draft-ietf-lsr-flex-algo-20

[John Scudder]

Hi Acee,

> On Aug 18, 2022, at 1:10 PM, Acee Lindem (acee) 
>  wrote:
> 
> Speaking as Document Shepherd:
>  
> Hi John, 
>  
> Thanks much for your review and suggested text. I think these will improve 
> the both the precision of the specification and the readability. I read 
> though the comments and I don’t see any show stoppers although the additional 
> operational considerations may take some thinking. Note that the main editor 
> just went on PTO after you completed you review and it will be at least a 3 
> weeks before you receive a response (and maybe more).

Yes, Peter also mentioned that to me unicast, thanks.

[snip]

> The Opaque ID field is an arbitrary value used to maintain multiple
> OSPFv2 EIA-ASBR LSAs.  For OSPFv2 EIA-ASBR LSAs, the Opaque ID has no
> @@ -1220,11 +1305,28 @@
> TLV is padded to 4-octet alignment; padding is not included in the
> Length field (so a 3-octet value would have a length of 3, but the
> total size of the TLV would be 8 octets).  Nested TLVs are also
> -   32-bit aligned.  For example, a 1-byte value would have the Length
> +   32-bit aligned.  For example, a 1-octet value would have the Length
> field set to 1, and 3 octets of padding would be added to the end of
> the value portion of the TLV.  The padding is composed of zeros.
> -
> -
> +   
> +jgs: I have mixed feelings about how you cut-and-paste the definition from
> +RFC 3630 Section 2.3.2 instead of just referencing it. On one hand, the
> +material starting with "for example" is new, provides more clarity, and
> +the requirement for padding to be zeroes is new. On the other hand, your
> +reference to the Length field, which makes sense in the original context
> +of RFC 3630 §2.3.2, is confusing here -- you have a diagram above with a
> +field called Length, but that is NOT what you're talking about here.
> +In 3630 there's a TLV diagram that makes it clear at a glance what's 
> +being talked about.
> +
> +Again I think the easiest fix is to leave the first sentence (adding
> +"Section 2.3.2" to the reference) and remove the rest, although if it's
> +important to specify zero-padding then leave that sentence.
> +
> +On the other hand if you feel the full detail is needed for clarity,
> +then go all the way and make this its own subsection and don't just
> +copy-paste the definition portion from 3630, copy the TLV diagram too,
> +so the reader isn't led astray.
> 
> Since the included text is only a couple sentences, I think it is clearer to 
> include it as has been done in other OSPF documents. To avoid the ambiguity 
> that you have pointed out, we can replace “Length field” with “TLV or Sub-TLV 
> length”. While I don’t think replication of the TLV format in a diagram is 
> needed, it better to have the very brief text rather than require going to 
> RFC 3630 to learn the encoding rules. One only has to cite the infamous RFC 
> 7752 as a document that is unwieldy, in part, due to the number of external 
> references required for the encodings.

Any solution that makes it clear what’s being referred to is OK of course. I do 
think it would be a cheap and easy thing to add a section break before that 
paragraph in support of that goal, something like the below. 

--- 10.1-para   2022-08-18 13:26:20.0 -0400
+++ 10.1-para-jgs-edits 2022-08-18 13:26:07.0 -0400
@@ -1,14 +1,17 @@
+10.1.1. EIA-ASBR TLVs
+
The format of the TLVs within the body of the OSPFv2 EIA-ASBR LSA is
the same as the format used by the Traffic Engineering Extensions to
OSPFv2 [RFC3630].  The variable TLV section consists of one or more
-   nested TLV tuples.  Nested TLVs are also referred to as sub- TLVs.
-   The Length field defines the length of the value portion in octets
+   nested TLV tuples.  Nested TLVs are also referred to as sub-TLVs.
+   
+   The TLV or Sub-TLV length field defines the length of the value portion in 
octets
(thus, a TLV with no value portion would have a length of 0).  The
TLV is padded to 4-octet alignment; padding is not included in the
Length field (so a 3-octet value would have a length of 3, but the
total size of the TLV would be 8 octets).  Nested TLVs are also
-   32-bit aligned.  For example, a 1-byte value would have the Length
+   32-bit aligned.  For example, a 1-octet value would have the TLV or Sub-TLV 
length
field set to 1, and 3 octets of padding would be added to the end of
the value portion of the TLV.  The padding is composed of zeros.
 
-10.1.1.  OSPFv2 Extended Inter-Area ASBR TLV
+10.1.1.1.  OSPFv2 Extended Inter-Area ASBR TLV

That adds one level of subsection nesting but I don’t see that as problematic.

$0.02,

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

Re: [Lsr] AD review of draft-ietf-lsr-isis-rfc5316bis-02

[John Scudder]

Hi Les,

Thanks for your prompt reply. My comments in line below.

> On Aug 18, 2022, at 12:49 AM, Les Ginsberg (ginsberg) 
>  wrote:

[snipped]

> I have a couple of other points I’ll raise here instead of in line.
> 
> 1. I was a little surprised in the Acknowledgements to see that Les is 
> thanking Les. :-) It’s OK of course if you want to do it that way, but maybe 
> you want to give that section one more look?
> 
> [LES:] As you no doubt surmised; we simply copied that text verbatim from RFC 
> 5316 – on which I was not an author. That statement is true as regards RFC 
> 5316, which is explicitly mentioned in the paragraph.
> I have no particular preference here – if the IETF has a policy on this I am 
> happy to follow it. 

[JGS]

There’s no IETF-wide policy, Acks are at the author’s discretion more than any 
other section. I’m not going to go dig up other bis documents but I seem to 
recall seeing a format more like this used in others —

---
NN. Acknowledgements

The authors of the present document would like to thank (authors’ discretion; 
if nobody then just leave this out).

RFC 5316 included the following Acknowledgements section:

   The authors would like to thank Adrian Farrel, Jean-Louis Le Roux,
   Christian Hopps, Les Ginsberg, and Hannes Gredler for their review
   and comments on this document.
—

Or sometimes the old acks are not carried forward but left to decorate the 
original document only, although in this case where you’re doing a 
tightly-scoped update I can see why you want to retain them.

[/JGS]

> 2. More substantively, the phrase “… when the TE Router ID is needed to reach 
> all routers …” or one like it, occurs many places in the document. I see that 
> this was part of the base RFC 5306 but it did introduce some confusion for 
> me, because there’s more than one possible reading, including
> 
> - when the TE Router ID has to be known by all routers
> - when in order to establish reachability to all routers, the TE Router ID is 
> needed
> 
> [LES:] I think the latter interpretation is the correct one. And I think the 
> existing text conveys that when the text is “the TE Router ID is needed to 
> reach all routers”. But there are some places where the text is “the TE 
> Router ID needs to reach all
>Routers” – the use of the active tense (“needs”) is inappropriate.
> Would it be acceptable to change only the places where the in appropriate 
> text is used?

[JGS]

That seems fine. I continue to think that the passive voice text is 
unnecessarily ambiguous too, but it’s at worst a minor impediment to consuming 
the spec so I’m happy to leave it to your discretion.

[/JGS]

> I leave it to you to decide whether or not to fix this. Clearly RFC 5306 
> stood for years with that wording and presumably it didn’t create a problem 
> (or at least nobody raised an erratum) so I’m comfortable with either outcome.
> 
> Thanks,
> 
> —John
> 
> --- draft-ietf-lsr-isis-rfc5316bis-02.txt   2022-08-17 14:21:33.0 
> -0400
> +++ draft-ietf-lsr-isis-rfc5316bis-02-jgs-comments.txt  2022-08-17 
> 14:42:45.0 -0400
> @@ -22,14 +22,15 @@
> This document describes extensions to the Intermediate System to
> Intermediate System (IS-IS) protocol to support Multiprotocol Label
> Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
> -   (TE) for multiple Autonomous Systems (ASs).  It defines IS-IS
> +   (TE) for multiple Autonomous Systems (ASes).  It defines IS-IS
> extensions for the flooding of TE information about inter-AS links,
> which can be used to perform inter-AS TE path computation.
>  
> No support for flooding information from within one AS to another AS
> is proposed or defined in this document.
>  
> -   This document obsoletes RFC 5316.
> +   This document builds on RFC 5316 by adding support for IPv6-only
> +   operation.  This document obsoletes RFC 5316.
> 
> [LES:] Accepted – but I prefer to use a separate paragraph for each sentence.
> ??

[JGS]

Totally fine.

[/JGS]

[remainder snipped]

Thanks,

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

[Lsr] AD review of draft-ietf-lsr-isis-rfc5316bis-02

[John Scudder]

Hi Authors,

Thanks for your patience as this clean and easy-to-review document sat in my 
queue for too long. :-( Here’s my review.

I’ve supplied my comments in the form of an edited copy of the draft. Minor 
editorial suggestions (including at least two reversions to the language of the 
base document) I’ve made in place without further comment. You can use your 
favorite diff tool to review them; I’ve attached a PDF of the iddiff output for 
your convenience if you’d like to use it. I’ve also pasted a traditional diff 
below in case you want to use it for in-line reply. I’d appreciate feedback 
regarding whether you found this a useful way to receive my comments as 
compared to a more traditional numbered list of comments with selective 
quotation from the draft.

I have a couple of other points I’ll raise here instead of in line.

1. I was a little surprised in the Acknowledgements to see that Les is thanking 
Les. :-) It’s OK of course if you want to do it that way, but maybe you want to 
give that section one more look?

2. More substantively, the phrase “… when the TE Router ID is needed to reach 
all routers …” or one like it, occurs many places in the document. I see that 
this was part of the base RFC 5306 but it did introduce some confusion for me, 
because there’s more than one possible reading, including

- when the TE Router ID has to be known by all routers
- when in order to establish reachability to all routers, the TE Router ID is 
needed

I leave it to you to decide whether or not to fix this. Clearly RFC 5306 stood 
for years with that wording and presumably it didn’t create a problem (or at 
least nobody raised an erratum) so I’m comfortable with either outcome.

Thanks,

—John

--- draft-ietf-lsr-isis-rfc5316bis-02.txt   2022-08-17 14:21:33.0 
-0400
+++ draft-ietf-lsr-isis-rfc5316bis-02-jgs-comments.txt  2022-08-17 
14:42:45.0 -0400
@@ -22,14 +22,15 @@
This document describes extensions to the Intermediate System to
Intermediate System (IS-IS) protocol to support Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
-   (TE) for multiple Autonomous Systems (ASs).  It defines IS-IS
+   (TE) for multiple Autonomous Systems (ASes).  It defines IS-IS
extensions for the flooding of TE information about inter-AS links,
which can be used to perform inter-AS TE path computation.
 
No support for flooding information from within one AS to another AS
is proposed or defined in this document.
 
-   This document obsoletes RFC 5316.
+   This document builds on RFC 5316 by adding support for IPv6-only
+   operation.  This document obsoletes RFC 5316.
 
 Requirements Language
 
@@ -147,7 +148,7 @@
 
In this document, a new TLV, which is referred to as the inter-AS
reachability TLV, is defined to advertise inter-AS TE information,
-   three new sub-TLVs are defined for inclusion in the inter-AS
+   and three new sub-TLVs are defined for inclusion in the inter-AS
reachability TLV to carry the information about the remote AS number
and remote ASBR ID.  The sub-TLVs defined in [RFC5305][RFC6119] and
other documents for inclusion in the extended IS reachability TLV for
@@ -600,7 +601,7 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
The remote AS number field has 4 octets.  When only 2 octets are used
-   for the AS number, as in current deployments, the left (high-order) 2
+   for the AS number, the left (high-order) 2
octets MUST be set to 0.  The remote AS number sub-TLV MUST be
included when a router advertises an inter-AS TE link.
 
@@ -863,7 +864,7 @@
 
This is achieved by the ASBR advertising, internally to its AS,
information about both directions of the TE link to the next AS.  The
-   ASBR will normally generate a LSP describing its own side of a link;
+   ASBR will normally generate an LSP describing its own side of a link;
here we have it 'proxy' for the ASBR at the edge of the other AS and
generate an additional LSP that describes that device's 'view' of the
link.
@@ -975,7 +976,7 @@
This document defines the following new sub-TLV types (described in
Sections 3.3.1, 3.3.2, 3.3.3, and, 3.3.4) of top-level TLV 141 (see
Section 6.1 above).  Three of these sub-TLVs have been registered in
-   the IS-IS sub-TLV registry for TLVs 22, 23, 25, 141, 222, and 223 by
+   the IS-IS Sub-TLVs for TLVs Advertising Neighbor Information registry by
[RFC5316].  One additional sub-TLV (IPv6 local ASBR identifier) is
introduced by this document and needs to be added to the same
registry.
@@ -998,8 +999,8 @@
 
This document defines the following new sub-TLV types, described in
Sections 3.4.1 and 3.4.2, of top-level TLV 242 (which is defined in
-   [RFC7981]) that have been registered in the IS-IS sub-TLV registry
-   for TLV 242:
+   [RFC7981]) that have been registered in the IS-IS Sub-TLVs for IS-IS 
+   Router 

Re: [Lsr] Early allocation request for code points in draft-ietf-lsr-ospfv3-srv6-extensions

[John Scudder]

Thanks. Approved.

—John

On Jul 8, 2022, at 7:25 PM, Acee Lindem (acee)  wrote:


Hi John,

From: John Scudder 
Date: Friday, July 8, 2022 at 7:13 PM
To: Acee Lindem 
Cc: IANA , lsr , 
draft-ietf-lsr-ospfv3-srv6-extensions 

Subject: Re: Early allocation request for code points in 
draft-ietf-lsr-ospfv3-srv6-extensions

Hi Acee,

Can I assume you’ve already checked on the RFC 7120 Section 2 conditions being 
met?

Yes – I recently reviewed the document and I don’t expect non-backward 
compatible changes to the specifications since an implementation is in progress.

Thanks,
Acee

Thanks,

—John

On Jul 8, 2022, at 6:38 PM, Acee Lindem (acee)  wrote:
Hi IANA Team, John,

The authors of the subject draft have requested early codepoint allocation as 
there are implementations in progress and I, as document shepherd, believe that 
this is overdue. Can we start the approval/allocation process?

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