[Lsr] Re: IPR Poll for Coinciding with the WG Adoption Poll for IS-IS PICs drafts

[Les Ginsberg (ginsberg)]

I am not aware of any IPR relevant to any of the three drafts listed below.

   Les

> -Original Message-
> From: Acee Lindem 
> Sent: Tuesday, October 8, 2024 12:10 PM
> To: draft-qgp-lsr-isis-pics-y...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] IPR Poll for Coinciding with the WG Adoption Poll for IS-IS 
> PICs
> drafts
> 
> Co-Authors,
> 
> Are you aware of any IPR that applies to the IS-IS PICs drafts:
> 
> 
> "YANG Model for IS-IS Protocol Implementation Conformance Statement
> (PICS)" - draft-qgp-lsr-isis-pics-yang-04
> "YANG Data Model for IS-IS Segment Routing MPLS PICS" - draft-qgp-lsr-isis-
> pics-srmpls-yang-03
> "YANG Data Model for IS-IS L2 Bundle Member Link Attributes PICS" - draft-
> qgp-lsr-isis-pics-l2member-attr-yang-00
> 
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> If you are listed as a document author or contributor please respond
> to this email regardless of whether or not you are aware of any
> relevant IPR. *The response needs to be sent to the LSR WG mailing
> list.* The document will not advance to the next stage until a
> response has been received from each author and contributor.
> 
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
> 
> 
> Thanks,
> Acee
> ___
> Lsr mailing list -- lsr@ietf.org
> To unsubscribe send an email to lsr-le...@ietf.org
___
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Bruno –

We do not disagree about what may be helpful – we only disagree regarding what 
should be normative.

I also remind you, once an operator introduces a configuration which requires 
MP-TLV, whether you have disabled MP-TLV or whether you have enabled it and you 
have some nodes which cannot handle MP-TLV (transmit or receive) – network 
operation will be negatively impacted.
There is no knob setting – regardless of default – which will guarantee that 
the network is not compromised under these circumstances.

I think, working together, we have resolved many issues to our mutual 
satisfaction. I understand we have a difference of opinion on this one 
remaining issue. I would ask that you consider the totality of what we have 
achieved.

WG chairs – friendly reminder – please indicate last call status.
Thanx.

   Les


From: bruno.decra...@orange.com 
Sent: Monday, September 30, 2024 5:37 AM
To: Les Ginsberg (ginsberg) 
Cc: Yingzhen Qu ; lsr ; lsr-chairs 
; Tony Li 
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi Les,

From my perspective, it’s not about “making it easier to use/deploy”, it’s 
about “not breaking existing networks” (and even not bothering the ones which 
didn’t ask for it).

(Although “making it easier to use” may be relevant for people who want to use 
it, that’s not really my point, quite the contrary.)


--Bruno
From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Wednesday, September 25, 2024 4:29 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>; Tony Li 
mailto:tony...@tony.li>>
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Bruno –

In my mind there is a difference between defining what is necessary to 
guarantee interoperability and defining what makes things easier to use (or - 
if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to 
want them to be treated the same. I don’t agree with this – not least because 
“easy to use” is a very subjective criteria. People may legitimately have very 
different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol 
advertisements which deviate from the expected content in some way – and it 
does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 
modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
   alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., 
RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.

These are all the modifications the authors are prepared to make in response to 
your comments.
Thanx again for the good discussion.

WG chairs – please let us know the status of WG last call as no further updates 
to the draft are planned.

Les

From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
mailto:bruno.decra...@orange.com>>
Sent: Tuesday, September 24, 2024 5:53 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>; Tony Li 
mailto:tony...@tony.li>>
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Les,

Thanks for the summary and for your effort.
Please see inline [Bruno]

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, September 24, 2024 7:36 AM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)


Folks –



I appreciate the good discussion that went on over the last couple weeks.

There are three potential textual changes being considered:



Section 4.1



"The set of link identifiers SHOULD be identical in all TLVs which are part of 
the MP-TLV set."



Possibly changing "SHOULD" to MUST".



Section 7.1



"It is RECOMMENDED that implementations which support the sending of MP-TLVs 
provide configuration controls to enable/disable generation of MP-TLVs. "



Possibly changing RECOMMENDED to REQUIRED



Section 7



"Providing appropriate controls to enable/disable the sending of MP-TLVs as 
discussed in Section 7.1 is essential to avoid interoperability issues."



C

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Robert –

I have read your email twice and it makes no sense to me.

I stated – and Bruno agreed – that one of the points of discussion was:


Section 7.1
"It is RECOMMENDED that implementations which support the sending of MP-TLVs 
provide configuration controls to enable/disable generation of MP-TLVs. "
Possibly changing RECOMMENDED to REQUIRED


So enabling/disabling MP via configuration is a point of discussion.

Given that Bruno and I understand each other (even if we do not agree) – I do 
not find your post helpful – just confusing.

   Les

From: Robert Raszuk 
Sent: Wednesday, September 25, 2024 8:43 AM
To: Les Ginsberg (ginsberg) 
Cc: bruno.decra...@orange.com; Tony Li ; Yingzhen Qu 
; lsr ; lsr-chairs 
Subject: Re: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)


Les,



> Example: One can imagine a network where MP is the norm and a given operator

> might wish to NOT have to configure enablement in the interest of

> configuration simplification.



Wrong example .. or not related to this discussion.



There is no mandate to enable MP-TLVs by configuration. It can be enabled by 
default and perhaps you can even put this into the text of the draft.



The discussion is about ALWAYS having ability to disable MP-TLV by complient 
with the draft/rfc implementations.



Thx,

R

















On Tue, Sep 24, 2024 at 7:41 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:

Folks –



I appreciate the good discussion that went on over the last couple weeks.

There are three potential textual changes being considered:



Section 4.1



"The set of link identifiers SHOULD be identical in all TLVs which are part of 
the MP-TLV set."



Possibly changing "SHOULD" to MUST".



Section 7.1



"It is RECOMMENDED that implementations which support the sending of MP-TLVs 
provide configuration controls to enable/disable generation of MP-TLVs. "



Possibly changing RECOMMENDED to REQUIRED



Section 7



"Providing appropriate controls to enable/disable the sending of MP-TLVs as 
discussed in Section 7.1 is essential to avoid interoperability issues."



Changing "essential" to "important"

Note: This is a consistency issue - if we do NOT use REQUIRED in Section 7.1

then it would be better NOT to use "essential" in Section 7.



DISCUSSION



Regarding Section 7/7.1



The argument is being made that using “REQUIRED/essential” reduces the

potential for interoperability problems. This assumes that some vendors who

might otherwise NOT implement the recommended practices would be more likely

to do so if normative language were used. This in turn presumes that the

chance of interoperability problems would be reduced as a result.



I am sympathetic to the goal. Many of us have had real world

experiences with interoperability issues and they are costly.

But I believe mandating aspects of an implementation which are unenforceable

and undetectable is not guaranteed to reduce interoperability issues.



The incidence of interoperability issues is most effectively reduced by

robustness in implementations. As Tony Li has stated:



"You do not make the network safer by mandate.  You make it safer by writing 
more forgiving code."



What is REQUIRED in a protocol specification are normative statements about

what is sent on the wire. But asserting that there is "one correct way" for

an implementation to support enablement/disablement is not appropriate -

not least because the benefits of a given approach may well depend upon the use 
case.



Example: One can imagine a network where MP is the norm and a given operator

might wish to NOT have to configure enablement in the interest of

configuration simplification. I see no reason why this should be declared

"illegal" just because others might not use that deployment strategy.



Suggestions/recommendations as to how an implementation might ease

deployment are valuable and these are discussed in the draft - and I believe

we do have consensus as to recommended best practices.



I therefore believe the current wording is appropriate and should not be

changed. The only change that needs to be made to the draft

is to change "essential" to "important" in Section 7 (for consistency).



I appreciate the passion associated with this discussion - but I am hopeful

that this resolution is acceptable to all.



Regarding Section 4.1, any interoperability issues with link identifiers

are not introduced by MP. If the WG feels there is an issue here, it should

be taken up outside of MP as it could impact two-way connectivity checks

even in non MP-TLV cases.



I am not suggesting that such work is necessary - only indicating the correct

context in which such work should be done if it is to be done at all.



As far as the current wording in Section 4.1, i

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Bruno –

In my mind there is a difference between defining what is necessary to 
guarantee interoperability and defining what makes things easier to use (or - 
if you prefer - easier to deploy).
The former demands normative language – the latter does not. But you seem to 
want them to be treated the same. I don’t agree with this – not least because 
“easy to use” is a very subjective criteria. People may legitimately have very 
different opinions on this.

That said, I took a look at RFC 7606 (thanx for the reference).
What that RFC does is discuss how to handle reception of protocol 
advertisements which deviate from the expected content in some way – and it 
does use MUST in requiring reporting of these anomalies.
With that in mind, V6 of MP-TLV draft has been published with Section 7.1 
modified to use MUST in reporting alarms:

“Implementations which support disablement of MP-TLVs MUST report
   alarms under the following conditions…”

We have not, however, modified the language in the previous paragraph i.e., 
RECOMMENDED is still used as regards implementing suggested knobs.
This is consistent with the point I made above regarding “ease of use”.

These are all the modifications the authors are prepared to make in response to 
your comments.
Thanx again for the good discussion.

WG chairs – please let us know the status of WG last call as no further updates 
to the draft are planned.

Les

From: bruno.decra...@orange.com 
Sent: Tuesday, September 24, 2024 5:53 AM
To: Les Ginsberg (ginsberg) 
Cc: Yingzhen Qu ; lsr ; lsr-chairs 
; Tony Li 
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Les,

Thanks for the summary and for your effort.
Please see inline [Bruno]

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, September 24, 2024 7:36 AM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)


Folks –



I appreciate the good discussion that went on over the last couple weeks.

There are three potential textual changes being considered:



Section 4.1



"The set of link identifiers SHOULD be identical in all TLVs which are part of 
the MP-TLV set."



Possibly changing "SHOULD" to MUST".



Section 7.1



"It is RECOMMENDED that implementations which support the sending of MP-TLVs 
provide configuration controls to enable/disable generation of MP-TLVs. "



Possibly changing RECOMMENDED to REQUIRED



Section 7



"Providing appropriate controls to enable/disable the sending of MP-TLVs as 
discussed in Section 7.1 is essential to avoid interoperability issues."



Changing "essential" to "important"

Note: This is a consistency issue - if we do NOT use REQUIRED in Section 7.1

then it would be better NOT to use "essential" in Section 7.



[Bruno] I agree on the above summary.



DISCUSSION



Regarding Section 7/7.1



The argument is being made that using “REQUIRED/essential” reduces the

potential for interoperability problems. This assumes that some vendors who

might otherwise NOT implement the recommended practices would be more likely

to do so if normative language were used. This in turn presumes that the

chance of interoperability problems would be reduced as a result.



I am sympathetic to the goal. Many of us have had real world

experiences with interoperability issues and they are costly.

But I believe mandating aspects of an implementation which are unenforceable

and undetectable is not guaranteed to reduce interoperability issues.



The incidence of interoperability issues is most effectively reduced by

robustness in implementations. As Tony Li has stated:



"You do not make the network safer by mandate.



[Bruno] That is incorrect.

E.g. with regards to road safety, one can mandate safety belts, air bags, 
traffic lights with mandating a stop when red, School bus traffic stop laws … 
and this make the world safer. At least for the more fragile road users. Sure, 
one could argue that buying a tank is the way for being safer… at least for 
himself.

With regards to networks, RC7606 defines (or “mandates” if you want) new error 
handling and this makes the network safer.



You make it safer by writing more forgiving code."



What is REQUIRED in a protocol specification are normative statements about

what is sent on the wire.



[Bruno] We are discussing what to send on the wire and when.





But asserting that there is "one correct way" for

an implementation to support enablement/disablement is not appropriate –



[Bruno] That is not what we are discussing. Please re-read your above summary.

In particular I’m not asking for “on

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Folks -



I appreciate the good discussion that went on over the last couple weeks.

There are three potential textual changes being considered:



Section 4.1



"The set of link identifiers SHOULD be identical in all TLVs which are part of 
the MP-TLV set."



Possibly changing "SHOULD" to MUST".



Section 7.1



"It is RECOMMENDED that implementations which support the sending of MP-TLVs 
provide configuration controls to enable/disable generation of MP-TLVs. "



Possibly changing RECOMMENDED to REQUIRED



Section 7



"Providing appropriate controls to enable/disable the sending of MP-TLVs as 
discussed in Section 7.1 is essential to avoid interoperability issues."



Changing "essential" to "important"

Note: This is a consistency issue - if we do NOT use REQUIRED in Section 7.1

then it would be better NOT to use "essential" in Section 7.



DISCUSSION



Regarding Section 7/7.1



The argument is being made that using "REQUIRED/essential" reduces the

potential for interoperability problems. This assumes that some vendors who

might otherwise NOT implement the recommended practices would be more likely

to do so if normative language were used. This in turn presumes that the

chance of interoperability problems would be reduced as a result.



I am sympathetic to the goal. Many of us have had real world

experiences with interoperability issues and they are costly.

But I believe mandating aspects of an implementation which are unenforceable

and undetectable is not guaranteed to reduce interoperability issues.



The incidence of interoperability issues is most effectively reduced by

robustness in implementations. As Tony Li has stated:



"You do not make the network safer by mandate.  You make it safer by writing 
more forgiving code."



What is REQUIRED in a protocol specification are normative statements about

what is sent on the wire. But asserting that there is "one correct way" for

an implementation to support enablement/disablement is not appropriate -

not least because the benefits of a given approach may well depend upon the use 
case.



Example: One can imagine a network where MP is the norm and a given operator

might wish to NOT have to configure enablement in the interest of

configuration simplification. I see no reason why this should be declared

"illegal" just because others might not use that deployment strategy.



Suggestions/recommendations as to how an implementation might ease

deployment are valuable and these are discussed in the draft - and I believe

we do have consensus as to recommended best practices.



I therefore believe the current wording is appropriate and should not be

changed. The only change that needs to be made to the draft

is to change "essential" to "important" in Section 7 (for consistency).



I appreciate the passion associated with this discussion - but I am hopeful

that this resolution is acceptable to all.



Regarding Section 4.1, any interoperability issues with link identifiers

are not introduced by MP. If the WG feels there is an issue here, it should

be taken up outside of MP as it could impact two-way connectivity checks

even in non MP-TLV cases.



I am not suggesting that such work is necessary - only indicating the correct

context in which such work should be done if it is to be done at all.



As far as the current wording in Section 4.1, it intentionally allows

existing implementations which successfully interoperate sending a subset

of link identifiers to continue to do so.



   Les






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

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Yingzhen –


[Yingzhen]: No. I don't have a backward compatible solution. What I'd suggest 
is if there are TLVs that may grow too big, for future specs to add another 
sub-tlv, we should consider adding an explicit statement about MP-TLV support. 
But this is not within the scope of this document.


Ahhh, but we have done exactly that – please reread Section 6.
😊

   Les

From: Yingzhen Qu 
Sent: Tuesday, September 3, 2024 5:13 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem ; Christian Hopps ; 
Bruno Decraene ; lsr ; lsr-chairs 

Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi Les,

Thanks for the reply.

Please see my answers below inline.

Thanks,
Yingzhen

On Tue, Sep 3, 2024 at 12:14 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Yingzhen –

(Bruno – I hope you are reading this as well – since my reply is relevant to 
some of your comments.)

From: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Sent: Tuesday, September 3, 2024 11:36 AM
To: Acee Lindem mailto:acee.i...@gmail.com>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; Bruno Decraene 
mailto:bruno.decra...@orange.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Speaking as a WG member.

The following text is in section 7.3:
"

   Implementations SHOULD NOT send

   multiple TLVs unless MP-TLV is applicable to the TLV and the amount

   of information which is required to be sent exceeds the capacity of a

   single TLV.  For example, when additional space is required in an

   existing TLV, as long as there is space in the TLV, information

   SHOULD NOT be split into multiple TLVs.  If there is no space in the

   current LSP to fit the now larger TLV, the TLV SHOULD be moved to a

   new LSP.
"
To me, as a developer, it is clear that MP-TLV SHOULD NOT be used unless this 
TLV is too big to even fit into one LSP . If there is a configuration knob, it 
has to be enabled.

[LES:] I think you are agreeing with the text, but to be clear…

This text is only applicable when the use of MP-TLVs has been enabled. It is 
not trying to say that MP-TLVs can be sent when they have not been enabled.
Given that, we are following the old axiom of “be strict in what you send and 
generous in what you receive”.
So, don’t send two TLVs when one would do – but if an implementation receives 
two TLVs it should process them even if the info could have been sent in one 
TLV.

This should not be controversial – it is following well established practice.
And it is NOT enabling the sending of MP-TLVs when they have been disabled by 
the operator.

So, “yes” if you or I were writing code, we would do our best to never send two 
TLVs when one would do.
But, if some implementation falls short of this goal, receivers should not 
reject otherwise valid information simply because it was not sent in the 
optimal way.

An updated version of the draft will add text clarifying these points .

[Yingzhen]: Yes, I'm agreeing with the text. The text is using "SHOULD NOT" and 
"SHOULD", that's the right level of specification that a standard should do. We 
can't control what an implementation will do, but "be generous in what you 
receive" has always been a guideline for protocol implementations.

However, I'm wondering whether the following text from Section 7.1 is 
challenging to operators:
"

   Therefore, diligence is

   still required on the part of the operator to ensure that

   configurations which require the sending of MP-TLV for a given

   codepoint are not introduced on any node in the network until all

   nodes in the network support MP-TLV for the relevant codepoints.
"
Assuming an operator receives an alarm indicating that MP-TLV is triggered, I 
think adjusting the configuration can be challenging. Please correct me if I'm 
wrong.

[LES:] Deploying MP-TLV has to be done carefully.
If a mistake is made, the alarms alert the operator to that fact.
What action to take may not – as you suggest – be easy to decide.
There are some easy cases – such as the network is fully MP-TLV capable, but 
the operator forgot to enable MP-TLV on one node before adding config that 
requires more than 255 bytes of info to be sent.
But there are also difficult cases such as the introduction of config that 
requires more than 255 bytes to be sent before MP-TLV support is fully deployed.
How to change the config so that MP-TLV is not required may not be trivial.

[Yingzhen]:  This is what the challenge is: if the operators have to change the 
configuration to avoid MP-TLV.

But the protocol cannot prevent this. We can only do our best to advertise what 
the configuration requires us to advertise, adhere to the enablement 
restrictions, a

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Robert –

There is a necessary dependence on the operator because it is the operator who 
knows whether MP-TLV support exists network-wide.
This isn’t an unusual situation for any particular feature because the protocol 
does not advertise feature support – and for a very good reason – because even 
if this information were available, having the protocol automatically react to 
changes in the network-wide state invites instability, flooding storms, and 
oscillation which likely would be worse than informing the operator of the 
compromised state and allowing the operator to decide the best action to take.

The draft is explicit about the need for controls:

Section 4:
“Network operators should not enable Multi-part TLVs until ensuring that all 
implementations that will receive the Multi-part TLVs are capable of 
interpreting them correctly.”

Section 7.1 discusses recommended controls.

The statement you quoted below – which lacks the context in which it was 
written – does not argue against controls.

   Les

From: Robert Raszuk 
Sent: Tuesday, September 3, 2024 3:33 PM
To: Les Ginsberg (ginsberg) 
Cc: Yingzhen Qu ; Acee Lindem ; 
Christian Hopps ; Bruno Decraene 
; lsr ; lsr-chairs 

Subject: Re: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi Les,

> We can only do our best to advertise what the configuration requires us to 
> advertise,

Let's zoom on this important statement as if this would be really the case I 
don't think we would have this discussion.

The issue seems to be that the configuration may enable flooding various 
dynamic data with unknown size restrictions (at the cfg point/moment).

So pushing the issue back to the operator who enabled such distributions seems 
not proper if that causes network wide issues - especially on nodes which do 
not support MP-TLVs.

If your point however is that injection of MP-TLV MUST  be explicitly enabled 
under ISIS cfg on all nodes after the operator is 100% sure that all nodes can 
handle it - I do not see an issue.

So pls kindly clarify.

Many thx,
Robert

On Tue, Sep 3, 2024 at 9:15 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Yingzhen –

(Bruno – I hope you are reading this as well – since my reply is relevant to 
some of your comments.)

From: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Sent: Tuesday, September 3, 2024 11:36 AM
To: Acee Lindem mailto:acee.i...@gmail.com>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; Bruno Decraene 
mailto:bruno.decra...@orange.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Speaking as a WG member.

The following text is in section 7.3:
"

   Implementations SHOULD NOT send

   multiple TLVs unless MP-TLV is applicable to the TLV and the amount

   of information which is required to be sent exceeds the capacity of a

   single TLV.  For example, when additional space is required in an

   existing TLV, as long as there is space in the TLV, information

   SHOULD NOT be split into multiple TLVs.  If there is no space in the

   current LSP to fit the now larger TLV, the TLV SHOULD be moved to a

   new LSP.
"
To me, as a developer, it is clear that MP-TLV SHOULD NOT be used unless this 
TLV is too big to even fit into one LSP . If there is a configuration knob, it 
has to be enabled.

[LES:] I think you are agreeing with the text, but to be clear…

This text is only applicable when the use of MP-TLVs has been enabled. It is 
not trying to say that MP-TLVs can be sent when they have not been enabled.
Given that, we are following the old axiom of “be strict in what you send and 
generous in what you receive”.
So, don’t send two TLVs when one would do – but if an implementation receives 
two TLVs it should process them even if the info could have been sent in one 
TLV.

This should not be controversial – it is following well established practice.
And it is NOT enabling the sending of MP-TLVs when they have been disabled by 
the operator.

So, “yes” if you or I were writing code, we would do our best to never send two 
TLVs when one would do.
But, if some implementation falls short of this goal, receivers should not 
reject otherwise valid information simply because it was not sent in the 
optimal way.

An updated version of the draft will add text clarifying these points .

However, I'm wondering whether the following text from Section 7.1 is 
challenging to operators:
"

   Therefore, diligence is

   still required on the part of the operator to ensure that

   configurations which require the sending of MP-TLV for a given

   codepoint are not introduced on any node in the network until all

   nodes in the network support MP-TLV for the relevant codepoints.
"
Assuming an operator receives 

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Yingzhen –

(Bruno – I hope you are reading this as well – since my reply is relevant to 
some of your comments.)

From: Yingzhen Qu 
Sent: Tuesday, September 3, 2024 11:36 AM
To: Acee Lindem 
Cc: Les Ginsberg (ginsberg) ; Christian Hopps 
; Bruno Decraene ; lsr 
; lsr-chairs 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Speaking as a WG member.

The following text is in section 7.3:
"

   Implementations SHOULD NOT send

   multiple TLVs unless MP-TLV is applicable to the TLV and the amount

   of information which is required to be sent exceeds the capacity of a

   single TLV.  For example, when additional space is required in an

   existing TLV, as long as there is space in the TLV, information

   SHOULD NOT be split into multiple TLVs.  If there is no space in the

   current LSP to fit the now larger TLV, the TLV SHOULD be moved to a

   new LSP.
"
To me, as a developer, it is clear that MP-TLV SHOULD NOT be used unless this 
TLV is too big to even fit into one LSP . If there is a configuration knob, it 
has to be enabled.

[LES:] I think you are agreeing with the text, but to be clear…

This text is only applicable when the use of MP-TLVs has been enabled. It is 
not trying to say that MP-TLVs can be sent when they have not been enabled.
Given that, we are following the old axiom of “be strict in what you send and 
generous in what you receive”.
So, don’t send two TLVs when one would do – but if an implementation receives 
two TLVs it should process them even if the info could have been sent in one 
TLV.

This should not be controversial – it is following well established practice.
And it is NOT enabling the sending of MP-TLVs when they have been disabled by 
the operator.

So, “yes” if you or I were writing code, we would do our best to never send two 
TLVs when one would do.
But, if some implementation falls short of this goal, receivers should not 
reject otherwise valid information simply because it was not sent in the 
optimal way.

An updated version of the draft will add text clarifying these points .

However, I'm wondering whether the following text from Section 7.1 is 
challenging to operators:
"

   Therefore, diligence is

   still required on the part of the operator to ensure that

   configurations which require the sending of MP-TLV for a given

   codepoint are not introduced on any node in the network until all

   nodes in the network support MP-TLV for the relevant codepoints.
"
Assuming an operator receives an alarm indicating that MP-TLV is triggered, I 
think adjusting the configuration can be challenging. Please correct me if I'm 
wrong.

[LES:] Deploying MP-TLV has to be done carefully.
If a mistake is made, the alarms alert the operator to that fact.
What action to take may not – as you suggest – be easy to decide.
There are some easy cases – such as the network is fully MP-TLV capable, but 
the operator forgot to enable MP-TLV on one node before adding config that 
requires more than 255 bytes of info to be sent.
But there are also difficult cases such as the introduction of config that 
requires more than 255 bytes to be sent before MP-TLV support is fully deployed.
How to change the config so that MP-TLV is not required may not be trivial.

But the protocol cannot prevent this. We can only do our best to advertise what 
the configuration requires us to advertise, adhere to the enablement 
restrictions, and report occurrences where constraints have been violated.

Are you hinting that there is something else that should be done??
If so, please make a suggestion.

   Les

Thanks,
Yingzhen

On Tue, Sep 3, 2024 at 7:53 AM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Speaking as WG member:

> On Sep 2, 2024, at 17:42, Les Ginsberg (ginsberg) 
> mailto:ginsb...@cisco.com>> wrote:
>
> Chris -
>
> I am continuing to think on this - based both on Bruno's input and now your 
> input.
>
> However, this would seem to potentially put the WG in the role of being asked 
> to pass judgment on whether a given implementation's configuration options 
> are conformant or not.
> This is not a role I want to play - nor is it a responsibility I think the WG 
> should take on.

I feel this should be added to the “Management Considerations” though it should 
not be a “MUST”. Now should it be a “SHOULD” or a “MAY”?  I don’t have a strong 
opinion although I lean toward “MAY” since we’ve gotten along fine without it 
for so long and it doesn’t make sense to try mandate additional functionality.


Thanks,
Acee



>
> I would be interested in your thoughts in this regard (with or without your 
> WG chair hat on).
>
> Thanx.
>
>   Les
>
>> -Original Message-
>> From: Christian Hopps mailto:cho...@chopps.org>>
>> Sent: Monday, September 2, 2024 9:06 AM
>> To: bruno.decra...@orange.com<mailto:b

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Chris -

I am continuing to think on this - based both on Bruno's input and now your 
input.

However, this would seem to potentially put the WG in the role of being asked 
to pass judgment on whether a given implementation's configuration options are 
conformant or not.
This is not a role I want to play - nor is it a responsibility I think the WG 
should take on.

I would be interested in your thoughts in this regard (with or without your WG 
chair hat on).

Thanx.

   Les

> -Original Message-
> From: Christian Hopps 
> Sent: Monday, September 2, 2024 9:06 AM
> To: bruno.decra...@orange.com
> Cc: Christian Hopps ; Les Ginsberg (ginsberg)
> ; Yingzhen Qu ; lsr
> ; lsr-chairs 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 -
> 7/15/2024)
> 
> 
> 
> > On Sep 2, 2024, at 11:38, bruno.decra...@orange.com wrote:
> >
> >  It is not within the purview of an RFC to mandate that an implementation
> have a particular knob.
> > [Bruno]
> > • According to which document /rule?
> 
> [as wg-member]
> 
> Regardless of whether we choose to add this requirement, I'm pretty sure it's
> fine to mandate that something be configurable (e.g., disable/enable) in an
> RFC. I haven't done a search but I definitely have seen this in other
> documents.
> 
> What this would be saying is that in order to claim support for RFC one
> must have the given configuration option.
> 
> Thanks,
> Chris.
> [as wg-member]
___
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

[Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" - draft-ietf-lsr-distoptflood-05

[Les Ginsberg (ginsberg)]

Tony –

Thanx for detailed response.
And I emphasize I am not avoiding the technical discussion on a number of 
issues you have raised in this and previous emails – which I think we 
definitely should have – but just trying to get past the one draft/two draft 
issue before doing so.

To summarize where we are…

A number of folks in the WG have indicated that they prefer there be two drafts 
– one to define the new flooding algorithm (as in earlier versions of your 
draft) and one to define the control mechanism that you have introduced in 
later versions of your draft.

You clearly prefer to keep it as one draft.
Hence the current poll, started by the WG chairs to try to determine WG 
consensus.

While the poll continues, I ask that you consider voluntarily moving to two 
drafts, even though you would prefer not to do so.
Here are my suggested reasons as to why you might want to consider this.

Although there have (sadly) only been a handful of responses to the poll thus 
far, all of the respondents to date are highly experienced Link State Protocol 
folks, with decades of hands on experience in implementation and deployment. 
The majority of these folks have expressed a preference for two drafts.
Even though you disagree, moving to two drafts would be a sign of respect for 
experienced colleagues.

Also, we are discussing modifying the “crown jewel” of link state protocols – 
the reliable Update Process. It behooves us as a WG to do so with a great deal 
of diligence. Having separate drafts allows issues specific to each of the 
proposals to be discussed independently – which is helpful.
I appreciate that it is more work to write/progress two drafts than one draft, 
but I think the importance of the extensions warrants the extra effort.

Finally, doing so voluntarily would immediately resolve the issue and allow the 
real work of the WG to begin.

Obviously, this choice is up to you.

In the meantime, I take this opportunity to ask that more WG members respond to 
the poll started by the WG chairs. If you consider yourself an active member of 
LSR WG, this topic is as important as any that has come before the WG. Please 
take the time to provide your input.
The original email which started this thread can be found  
here<https://mailarchive.ietf.org/arch/msg/lsr/yj9x1AAjT2-74eb3qTu3qEQf4fo/>

   Les

From: Tony Przygienda 
Sent: Monday, August 19, 2024 1:46 AM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; Acee Lindem ; lsr 

Subject: Re: [Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" 
- draft-ietf-lsr-distoptflood-05

Hey Les, weekend over, quick inlines ;-)

On Sat, Aug 17, 2024 at 8:17 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Tony –

The points you raise are worthy of discussion in the WG – but they are not the 
subject of this thread.

agreed. I personally would further suggest actually that in the name of 
intellectual honesty and the spirit of delivering highest quality 
specifications in IETF those non-trivial operational considerations (which does 
affect a certain class of customers/networks) may be added as an according 
section, even if the dynamic flooding draft is experimental only and to avoid 
the 'stale election result in the network' to also possibly mandate SPT 
computation to the leader before deciding on the computation algorithm.


The subject of this thread is whether the draft should proceed in its current 
form (definition of a flooding algorithm + definition of new control 
procedures) or whether the two should be split into separate drafts.


I do not see why definition of a flooding algorithm – which is functionally 
independent of the mechanism used to enable the use of such an algorithm – 
should be defined in the same document as a control mechanism.

Les, we had the exchange on the mike and nothing in my position/reasoning 
changed which I laid out repeatedly. To save people the time of rewatching the 
recording and dense discussion I allow myself to jolt down the salient points 
quickly in here (and BTW, in case I missed any of your arguments except the "I 
think those are somehow two things and I personally like them in two drafts" I 
am always willing to address those)

on procedural grounds

1) there is nothing in an adoption call on drafts that limits its evolution 
(obviously as long the content is relevant to original work and emerging 
requirements). Just like dynamic flooding ended up evolving from centralized 
computation to add leader-distributed and then all kinds of mechanisms around 
it there are countless examples of drafts evolving to address the original 
problem properly and emerging new requirements to the solution.
2) there is nothing in terms of RFCs whether framework and solution using it 
are to be separated or not, operational has been bundled with drafts and split 
sometimes, applicability the same, requirements the same (in fact it's funny 
the dynamic flooding li

[Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" - draft-ietf-lsr-distoptflood-05

[Les Ginsberg (ginsberg)]

Tony –

The points you raise are worthy of discussion in the WG – but they are not the 
subject of this thread.

The subject of this thread is whether the draft should proceed in its current 
form (definition of a flooding algorithm + definition of new control 
procedures) or whether the two should be split into separate drafts.

I do not see why definition of a flooding algorithm – which is functionally 
independent of the mechanism used to enable the use of such an algorithm – 
should be defined in the same document as a control mechanism.

Could you please speak to this subject?

Thanx.

   Les


From: Tony Przygienda 
Sent: Saturday, August 17, 2024 5:36 AM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; Acee Lindem ; lsr 

Subject: Re: [Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" 
- draft-ietf-lsr-distoptflood-05

First, let's observe precisely that the framework does not mandate in any way 
multiple algorithms, it just allows them. the draft does not in any way suggest 
that presence of multiple algorithms is desirable or recommended. If clarifying 
text is needed, it can be easily added.

Second, contrary to assertions extended in this thread it is absolutely 
possible to mix algorithms in the framework provided as the draft proves by CDS 
induction. I expect the opponents claiming here otherwise to provide a clear 
counter example to put their claims on some substantiated base.

In fact, the draft can be mixed much easier than we thought with dynamic 
flooding, basically anything advertising dynamic flooding sub-TLV must be 
considered a component by itself and due to the CDS stitching rules the mix 
will work fine (i.e. a leader component and leaderless component will be glued 
at edges and since both are CDS the result will be a CDS).  A future version 
will improve what we have today.

Having said that, the multiple algorithms itself is red herring largely (except 
maybe during migration) since the driving requirement here is minimal blast 
radius under any condition required by many customers looking at deploying the 
technology now and dynamic flooding does not meet it.

And to point out why dynamic flooding does not meet its own requirement #4 in 
the draft, let us run the scenarios that make the suggested leaderless mode 
necessary:

1) if area leader and backup area leader are behind an articulation (and sorry, 
articulations are not uncommon in large and very large networks) the failure of 
the node partitioning the network may lead to large part of the network losing 
access to the leader or worse, rely on unreachable, old TLVs (and with that 
reduction being e.g. impossible to disable) and hence, in strictest sense the 
nodes relying on leader should always compute reachability to the leader before 
using its TLVs (as was done based on deployment experience in PNNI ultimately) 
. Dismissing "partition is not a problem" is basically telling lots of 
customers that the technology is not deployable for them without significant 
blast radius, configuration and placement risk. Leaderless framework does not 
expose them to such unnecessary risks and complexity.
2) The other significant blast radius in leader election occurs when an 
algorithm must be migrated to another one (bugs, better algorithm or some 
such). Yes, each node can be updated to a new algorithm separately in dynamic 
flooding but the switch on the leader ultimately leads to _all_ nodes involved 
changing behavior, generating basically blast radius of all nodes in the 
network using the reduction AFAIS. Leaderless framework contrary to that allows 
a node by node migration from one algorithm to another without all-nodes blast 
radius at certain point.
3) Ultimately, misconfiguration of the leader (by e.g. fat fingering the 
algorithm or introducing inadvertently misconfigured node with higher priority 
and so on and so on) can lead to change of behavior of all nodes running the 
algorithm, e.g. disabling it. Such outages are anything but theory on very 
large networks. Leaderless framework does not suffer from such possible blast 
radius.

In a  sense, one can consider the leaderless mode actually a simple extension 
of the dynamic flooding draft (and such was suggested to the authors). A new 
sub-TLV saying "active running leaderless algorithm" is necessary and it should 
be advertised w/o the dynamic flooding subTLV. Hence the nodes running leaders 
will run their algorithm and active running leaderless algorithm will use the 
rules in the leaderless framework to consider those a different component. 
Whether the leaderless algorithm number comes from the dynamic floodng registry 
or some other doesn't matter as long it's marked as "leaderless". Two versions 
can be put into registry for same algorithm, one leaderless, one not.

As to improvement of framework language/terms I'm more than happy to 
oblige/discuss though component/CDS and many other t

[Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" - draft-ietf-lsr-distoptflood-05

[Les Ginsberg (ginsberg)]

So, this is exactly why the current content of the draft, which combines both 
the definition of a flooding algorithm with the definition of a new mechanism 
to control which algorithm(s) are used is problematic.

Regarding the new control mechanism, my opinion is much the same as Tony Li - I 
think it is problematic.
Acee - it seems that you feel otherwise.

But I suspect all three of us can agree that the new flooding algorithm 
(defined in Section 2 of the draft) is something that is desirable.

By combining the two into a single draft, the WG is forced to gives a thumbs 
up/down on both - which is not logical since even the draft itself allows that 
the algorithm (Section 2) can be deployed by using either the procedures 
defined in https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/ or 
by the new procedures defined in Section 1 of this draft.

Please give the WG the opportunity to evaluate and progress (or not) these two 
logically independent elements in separate drafts.

   Les

> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Friday, August 16, 2024 8:06 AM
> To: Acee Lindem 
> Cc: lsr 
> Subject: [Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" -
> draft-ietf-lsr-distoptflood-05
> 
> 
> Hi Acee,
> 
> I beg to differ.  Without a consistent, uniform algorithm selection, havoc 
> will
> necessarily ensue.  The algorithm itself can be distributed. The decision of
> which algorithm to use cannot be inconsistent.
> 
> For this reason, I oppose moving forward as the document currently stands.
> 
> Tony
> 
> 
> > On Aug 16, 2024, at 7:48 AM, Acee Lindem  wrote:
> >
> > Speaking as WG member:
> >
> > From a technical standpoint, I don’t have a problem with the addition of the
> flooding signaling (though I’m not fond of the prunner/zero prunner
> terminology).
> >
> > The existing area leader election and flooding algorithm selection
> (https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/) was
> originally targeted at centralized flooding reduction. While it has been made 
> to
> work for distributed flooding reduction, electing an area leader is not 
> needed.
> Rather, the described one-hop signaling is all that is needed to assure 
> correct
> operation and more suited to distributed flooding reduction algorithms.
> >
> > Thanks,
> > Acee
> >
> >> On Aug 2, 2024, at 2:06 PM, Acee Lindem  wrote:
> >>
> >>
> >> The subject draft was adopted as a WG document containing only the
> flooding reduction algorithm (section 2).
> >>
> >> Procedures and signaling have been added to the current version allowing
> concurrent operation within an IS-IS area of IS-IS routers running different
> flooding reduction algorithms or no flooding reduction at all  (section 1).
> >>
> >> WG members are questioning if this extra requirement needs to be met and
> included in this document. There was an extensive discussion during the IETF
> 120 LSR meeting and a MeetEcho show-of-hands poll was taken -
> https://notes.ietf.org/notes-ietf-120-lsr
> >>
> >> Please indicate your preference and reasoning amongst the following
> options by August 17, 2024:
> >>
> >> 1) The document remains in its current form describing both the 
> >> flooding
> reduction algorithm signaling/procedures and the new flooding reduction
> algorithm.
> >> 2) The flooding reduction algorithm and procedures will be split into a
> separate document with its own LSR WG adoption call.
> >> 3) Some other resolution?
> >>
> >> Thanks,
> >> Yingzhen, Chris, and Acee (LSR Chairs)
> >
> >
> > ___
> > Lsr mailing list -- lsr@ietf.org
> > To unsubscribe send an email to lsr-le...@ietf.org
> 
> ___
> Lsr mailing list -- lsr@ietf.org
> To unsubscribe send an email to lsr-le...@ietf.org
___
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Bruno –

The reason for SHOULD rather than MUST has to do with the old axiom of being 
“strict in what you send – but generous in what you receive”.
Using two TLVs to send information when it could be sent in one TLV introduces 
more overhead for the receiver – it would be best if this were not done.
But (assuming MP-TLV support is fully deployed of course) we do not want the 
receiver to discard/ignore the information just because it was sent in a 
sub-optimal way.

Hope this makes sense.

   Les

From: bruno.decra...@orange.com 
Sent: Friday, August 9, 2024 7:50 AM
To: Les Ginsberg (ginsberg) 
Cc: Yingzhen Qu ; lsr ; lsr-chairs 
; DECRAENE Bruno INNOV/NET 
Subject: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Les, authors,

Sorry, one more comment
7.3. 
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-03#section-7.3> 
Restrictions on Generation of 
MP-TLVs<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-03#name-restrictions-on-generation->
“Implementations SHOULD NOT send multiple TLVs unless MP-TLV is applicable to 
the TLV and the amount of information which is required to be sent exceeds the 
capacity of a single TLV.”

Do you have a reason/example in mind for not complying with this?
If not, I would favor :s/SHOULD/MUST. At least for the second part (“not enough 
space”). This would avoid that some implementation send MP-TLV while not 
anticipated (and a priori for no reason since this could fit in a single TLV).

Thanks
Regards,
--Bruno

From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
mailto:bruno.decra...@orange.com>>
Sent: Friday, August 9, 2024 4:40 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Les,



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Friday, August 9, 2024 6:11 AM
Bruno –

Thanx for the detailed comments.

Thanks for taking the time to respond in detail.

Note that we have not yet fully determined what text changes should be made to 
the draft  – but hopefully this discussion will help us move forward.
I appreciate that this discussion is time consuming – but hopefully worth it 
for all of us.

+1.

BTW, I will be away for a few days the first part of next week (returning on 
Thursday August 15) – so responses may be delayed.

No problem, thanks Les. On my side, I’ll be away till August 26

Please see inline.

From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
mailto:bruno.decra...@orange.com>>
Sent: Wednesday, August 7, 2024 6:03 AM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi authors,

Please see below some possible comments on the draft.


1)
§3 says
“TLVs sometimes contain information, called a key, that indicates the 
applicability of the remaining contents of the TLV. If a router advertises 
multiple TLV tuples with the same Type code in an IS-IS IIH packet or in the 
set of LSPs for a level with the same key value, they are considered a 
multi-part TLV (MP-TLV).”

I’m reading this as: TLV not having a key can’t be a MP-TLV.
If this is not the intention please clarify. (e.g. same key value if that TLV 
has a key)
If this is the intention, this seems to contradict with other text such as
§4 “If a Multi-part TLV contains information that specifies the applicability 
of its contents (i.e., a key), the key information MUST be replicated”
§6 “However, Multi-Part TLV procedures are potentially applicable to any 
codepoint that allows sub-TLVs to be included as part of the information 
advertised.”

[LES:] In order for MP-TLV to be applicable to a codepoint, there has to be the 
potential for more than 255 bytes of information to be advertised. (obvious 😊)
And if multiple TLVs are sent, there has to be a way to identify them as being 
associated with the same object (which is what the “key” does).
This is consistent with the statement “TLV not having a key can’t be a MP-TLV.”.
But there are some subtleties.
To use your example of the admin tag sub-TLVs, I agree that it is conceivable 
(though unlikely) that one could need to advertise more than 255 bytes of tags, 
yet the tag sub-TLVs themselves do not have a “key”.
Functionally however, as they are associated with a single prefix, they inherit 
the key from the parent codepoint.
(More comments on admin tag below).

[Bruno] OK. The principle of the MP-TLV extension is clear. My concern is that 
the sender be more subtle than the receiver and hence the receiver gets 
surprised/lost.

In summary, I think we can do a better job of wording in this section – we

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Bruno –

Seems like we are converging.
Some additional responses inline – look for LES2:


From: bruno.decra...@orange.com 
Sent: Friday, August 9, 2024 7:40 AM
To: Les Ginsberg (ginsberg) 
Cc: Yingzhen Qu ; lsr ; lsr-chairs 

Subject: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Les,



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Friday, August 9, 2024 6:11 AM
Bruno –

Thanx for the detailed comments.

Thanks for taking the time to respond in detail.

Note that we have not yet fully determined what text changes should be made to 
the draft  – but hopefully this discussion will help us move forward.
I appreciate that this discussion is time consuming – but hopefully worth it 
for all of us.

+1.

BTW, I will be away for a few days the first part of next week (returning on 
Thursday August 15) – so responses may be delayed.

No problem, thanks Les. On my side, I’ll be away till August 26
[LES2:] Now I am jealous. 😊

Please see inline.

From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
mailto:bruno.decra...@orange.com>>
Sent: Wednesday, August 7, 2024 6:03 AM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi authors,

Please see below some possible comments on the draft.


1)
§3 says
“TLVs sometimes contain information, called a key, that indicates the 
applicability of the remaining contents of the TLV. If a router advertises 
multiple TLV tuples with the same Type code in an IS-IS IIH packet or in the 
set of LSPs for a level with the same key value, they are considered a 
multi-part TLV (MP-TLV).”

I’m reading this as: TLV not having a key can’t be a MP-TLV.
If this is not the intention please clarify. (e.g. same key value if that TLV 
has a key)
If this is the intention, this seems to contradict with other text such as
§4 “If a Multi-part TLV contains information that specifies the applicability 
of its contents (i.e., a key), the key information MUST be replicated”
§6 “However, Multi-Part TLV procedures are potentially applicable to any 
codepoint that allows sub-TLVs to be included as part of the information 
advertised.”

[LES:] In order for MP-TLV to be applicable to a codepoint, there has to be the 
potential for more than 255 bytes of information to be advertised. (obvious 😊)
And if multiple TLVs are sent, there has to be a way to identify them as being 
associated with the same object (which is what the “key” does).
This is consistent with the statement “TLV not having a key can’t be a MP-TLV.”.
But there are some subtleties.
To use your example of the admin tag sub-TLVs, I agree that it is conceivable 
(though unlikely) that one could need to advertise more than 255 bytes of tags, 
yet the tag sub-TLVs themselves do not have a “key”.
Functionally however, as they are associated with a single prefix, they inherit 
the key from the parent codepoint.
(More comments on admin tag below).

[Bruno] OK. The principle of the MP-TLV extension is clear. My concern is that 
the sender be more subtle than the receiver and hence the receiver gets 
surprised/lost.

In summary, I think we can do a better job of wording in this section – we will 
work on that.
But the existing text is correct in spirit.

[Bruno] OK, thanks.

2)
§4.1 (TLV 22)

“The key consists of the 7 octets of system ID and pseudonode number plus the 
link identifiers.”
OK. May be for extra clarify :s/the link identifiers/all links identifiers 
which are present

[LES:] We will make this change.

“The following key information MUST be replicated in each of the additional 
Extended IS Reachability TLVs:
  7 octets of system ID and pseudonode number
  At least one of the following identifiers”
It’s not clear to me whether you mean “all link identifiers” advertised in the 
first part (which would seem to match your above definition of the key) or “any 
(number) of links identifiers”.

That’s the typical example where the lack of a formal definition of the key for 
a (all) TLVs may brings interop issue. One implementer could believe that all 
link identifiers are needed in all parts, while another could believe that a 
subset is enough in some cases.
[LES:] We mean exactly what we say - "at least one".
It is not necessary to advertise all of the link identifiers in each TLV in 
order to correctly identify the two TLVs as having the same key.

There is a good deal that could be said here - but it is not the province of 
this document to do so. The issue you raise is applicable to a single TLV as 
well.
For example, A-B have an adjacency and advertise an IS-Neighbor TLV, the 
following works for the purposes of doing TWCC:

A advertises: (B system-id,  IPv4 endpoint addresses,   Local/Remote Link IDs)
B advertises: ( A system-id,  Local/Remote IDs)

[Bruno] Thanks f

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Acee –

There is no such thing as “MP-TLV encodings”.
There are only the encodings for each TLV which are defined in the respective 
RFCs that defined that code point.
As has been emphasized the multi-tlv draft makes no changes to TLV encodings.
(I am sure you understand this – but I needed to repeat in order to fully 
respond to your comment.)

The IANA section is only providing instructions to IANA as to what changes are 
required to the registries.
It is not a replacement for the registry nor intended to be a duplicate of the 
registry.
This is standard practice.

So I don’t see the point of duplicating information which is already in the 
registry.

   Les


From: Acee Lindem 
Sent: Friday, August 9, 2024 8:01 AM
To: Les Ginsberg (ginsberg) 
Cc: Aijun Wang ; Bruno Decraene 
; Yingzhen Qu ; lsr 
; lsr-chairs 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)




On Aug 9, 2024, at 10:44, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Acee –

Please note that the IS-IS registries already have a link to the RFC for each 
and every codepoint – so what you suggest has already been done.

Of course I already know this 
(https://datatracker.ietf.org/person/acee.i...@gmail.com) and use the IANA 
registry as a resource when IETF document authors have been lazy and haven’t 
provided the attendant references. My suggestion is to add the references to 
make the document more consumable. From this protracted discussion, it seems 
that the MP-TLV encodings aren’t known to everyone.

Acee





Section 8.2 is only documenting the changes we want IANA to make (adding the 
new column).

   Les

From: Acee Lindem mailto:acee.i...@gmail.com>>
Sent: Friday, August 9, 2024 6:49 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Bruno Decraene mailto:bruno.decra...@orange.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Speaking as a WG member:

Hi Aijun, Les, Bruno,

While my completely unbiased opinion is that the world would be a better place 
if everyone migrated to OSPFv3 (https://datatracker.ietf.org/doc/rfc5340/) with 
Extended LSAs (https://datatracker.ietf.org/doc/rfc8362/) and at the risk of 
further muddying the waters, I’ll offer a compromise here.

Perhaps, we could just add RFC references to MP-TLVs, MP-sub-TLVs, and 
MP-sub-….TLVs in section 8.2. That way, if anybody had any questions as to the 
encoding of these MP-TLVs (including the keys), they could simply access the 
html version of the document and click their way to enlightenment.

Thanks,
Acee




On Aug 9, 2024, at 05:14, Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:

Hi, Les:

Please reread Bruno’s questions and your responses。 I highlight the important 
parts for your reference.

It’s not clear to me whether you mean “all link identifiers” advertised in the 
first part (which would seem to match your above definition of the key) or “any 
(number) of links identifiers”.

That’s the typical example where the lack of a formal definition of the key for 
a (all) TLVs may brings interop issue. One implementer could believe that all 
link identifiers are needed in all parts, while another could believe that a 
subset is enough in some cases.
[LES:] We mean exactly what we say - "at least one".
It is not necessary to advertise all of the link identifiers in each TLV in 
order to correctly identify the two TLVs as having the same key.

You said “at least one”, but not “all link identifiers” is necessary. Then, the 
sender can select any of them to be included.
Even one sender can keep selecting only the same link identifier as the “key”, 
other sender from different vendor may select another, should the receivers 
accept one, discard another? Or depend on their own justification?
Won’t these undefined possibilities lead no interoperability?

Best Regards

Aijun Wang
China Telecom

发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
发送时间: 2024年8月9日 15:19
收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 'Yingzhen Qu' 
mailto:yingzhen.i...@gmail.com>>; 'lsr' 
mailto:lsr@ietf.org>>; 'lsr-chairs' 
mailto:lsr-cha...@ietf.org>>
主题: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

For the benefit of the WG…Aijun’s example is inconsistent with what the 
muti-tlv draft states as well as the example I provided in my response to Bruno.

The key phrase is:  “The following key information MUST be replicated…”

In the example Aijun provided (which is NOT the same as the example I provided) 
there is no replication of any of the possible identifiers:


…if some of the segmente

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Acee –

Please note that the IS-IS registries already have a link to the RFC for each 
and every codepoint – so what you suggest has already been done.

Section 8.2 is only documenting the changes we want IANA to make (adding the 
new column).

   Les

From: Acee Lindem 
Sent: Friday, August 9, 2024 6:49 AM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Bruno Decraene 
; Yingzhen Qu ; lsr 
; lsr-chairs 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Speaking as a WG member:

Hi Aijun, Les, Bruno,

While my completely unbiased opinion is that the world would be a better place 
if everyone migrated to OSPFv3 (https://datatracker.ietf.org/doc/rfc5340/) with 
Extended LSAs (https://datatracker.ietf.org/doc/rfc8362/) and at the risk of 
further muddying the waters, I’ll offer a compromise here.

Perhaps, we could just add RFC references to MP-TLVs, MP-sub-TLVs, and 
MP-sub-….TLVs in section 8.2. That way, if anybody had any questions as to the 
encoding of these MP-TLVs (including the keys), they could simply access the 
html version of the document and click their way to enlightenment.

Thanks,
Acee



On Aug 9, 2024, at 05:14, Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:

Hi, Les:

Please reread Bruno’s questions and your responses。 I highlight the important 
parts for your reference.

It’s not clear to me whether you mean “all link identifiers” advertised in the 
first part (which would seem to match your above definition of the key) or “any 
(number) of links identifiers”.

That’s the typical example where the lack of a formal definition of the key for 
a (all) TLVs may brings interop issue. One implementer could believe that all 
link identifiers are needed in all parts, while another could believe that a 
subset is enough in some cases.
[LES:] We mean exactly what we say - "at least one".
It is not necessary to advertise all of the link identifiers in each TLV in 
order to correctly identify the two TLVs as having the same key.

You said “at least one”, but not “all link identifiers” is necessary. Then, the 
sender can select any of them to be included.
Even one sender can keep selecting only the same link identifier as the “key”, 
other sender from different vendor may select another, should the receivers 
accept one, discard another? Or depend on their own justification?
Won’t these undefined possibilities lead no interoperability?

Best Regards

Aijun Wang
China Telecom

发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
发送时间: 2024年8月9日 15:19
收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 'Yingzhen Qu' 
mailto:yingzhen.i...@gmail.com>>; 'lsr' 
mailto:lsr@ietf.org>>; 'lsr-chairs' 
mailto:lsr-cha...@ietf.org>>
主题: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

For the benefit of the WG…Aijun’s example is inconsistent with what the 
muti-tlv draft states as well as the example I provided in my response to Bruno.

The key phrase is:  “The following key information MUST be replicated…”

In the example Aijun provided (which is NOT the same as the example I provided) 
there is no replication of any of the possible identifiers:


…if some of the segmented TLV includes (B System ID, Local/Remote Link IDs) , 
but other includes (B System ID, IPv4 neighbor address),


So Aijun’s example is wrong and he is not quoting me – despite his claims of 
doing so.

   Les


From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Friday, August 9, 2024 12:01 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 'Yingzhen Qu' 
mailto:yingzhen.i...@gmail.com>>; 'lsr' 
mailto:lsr@ietf.org>>; 'lsr-chairs' 
mailto:lsr-cha...@ietf.org>>
Subject: 答复: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi, Chris:

Let’s give you answer for your question, based on the responses from Les:

> [WAJ] Ambiguity exists in almost for every multi-TLV capable code points.

[Chris]I guess this goes with your assertion that no-one can figure this out. I 
think people disagree with you here so perhaps a couple examples of the readily 
available ambiguity would help?

【WAJ】Please see the following example provided by Les himself, and also 
question to Les:

How about the receiver to concatenate the multi-part TLVs together for one link 
if some of the segmented TLV includes (B System ID, Local/Remote Link IDs) , 
but other includes (B System ID, IPv4 neighbor address), and another includes 
(B System ID, IPv6 interface address)?
Or treat them as for information for different links of the neighbor (B System 
ID)?

From this example, we can see there will be how much chaos will be emerged for 
the undefined “key” field part of the one code point.

Any

[Lsr] Re: Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-labv-registration-03: (with COMMENT)

[Les Ginsberg (ginsberg)]

Zahed –

RFC 5029 was published in 2007 – years before RFC 7370 and the formalization of 
Expert Review as the choice for IS-IS registries.
So I don’t think we should read too much into the choice made back then.

Don’t know if that will alleviate your sadness – but I tried. 😊

   Les

From: Zaheduzzaman Sarker 
Sent: Friday, August 9, 2024 4:41 AM
To: Tony Li 
Cc: The IESG ; draft-ietf-lsr-labv-registrat...@ietf.org; 
lsr-chairs ; lsr ; Yingzhen Qu 

Subject: [Lsr] Re: Zaheduzzaman Sarker's No Objection on 
draft-ietf-lsr-labv-registration-03: (with COMMENT)

Hi Tony,

Thats sad!! So we don't know why that IANA policy was selected but we know that 
is not useful anymore hence the update.

//Zahed

On Thu, Aug 8, 2024 at 9:52 AM Tony Li 
mailto:tony...@tony.li>> wrote:

Hi Zaheduzzaman,

Unfortunately, the authors of RFC 5029 left us no note as to their motivations.

Regards,
Tony

> On Aug 8, 2024, at 12:43 AM, Zaheduzzaman Sarker via Datatracker 
> mailto:nore...@ietf.org>> wrote:
>
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-lsr-labv-registration-03: 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-labv-registration/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for working on this. It seems useful change to me. However, I or the
> reader would be benefited to know why this was "standard required" in the 
> first
> place, then describe why it is required to be changed.
>
>
>
___
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

For the benefit of the WG…Aijun’s example is inconsistent with what the 
muti-tlv draft states as well as the example I provided in my response to Bruno.

The key phrase is:  “The following key information MUST be replicated…”

In the example Aijun provided (which is NOT the same as the example I provided) 
there is no replication of any of the possible identifiers:


…if some of the segmented TLV includes (B System ID, Local/Remote Link IDs) , 
but other includes (B System ID, IPv4 neighbor address),


So Aijun’s example is wrong and he is not quoting me – despite his claims of 
doing so.

   Les


From: Aijun Wang 
Sent: Friday, August 9, 2024 12:01 AM
To: Les Ginsberg (ginsberg) ; bruno.decra...@orange.com; 
'Yingzhen Qu' ; 'lsr' ; 'lsr-chairs' 

Subject: 答复: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi, Chris:

Let’s give you answer for your question, based on the responses from Les:


> [WAJ] Ambiguity exists in almost for every multi-TLV capable code points.



[Chris]I guess this goes with your assertion that no-one can figure this out. I 
think people disagree with you here so perhaps a couple examples of the readily 
available ambiguity would help?

【WAJ】Please see the following example provided by Les himself, and also 
question to Les:

How about the receiver to concatenate the multi-part TLVs together for one link 
if some of the segmented TLV includes (B System ID, Local/Remote Link IDs) , 
but other includes (B System ID, IPv4 neighbor address), and another includes 
(B System ID, IPv6 interface address)?
Or treat them as for information for different links of the neighbor (B System 
ID)?

From this example, we can see there will be how much chaos will be emerged for 
the undefined “key” field part of the one code point.

Anyone understands the process of segment/concatenate process should be aware 
the exact “key” field, why do we argue it constantly for this obvious 
requirements?


Best Regards

Aijun Wang
China Telecom




“The following key information MUST be replicated in each of the additional 
Extended IS Reachability TLVs:
  7 octets of system ID and pseudonode number
  At least one of the following identifiers”
It’s not clear to me whether you mean “all link identifiers” advertised in the 
first part (which would seem to match your above definition of the key) or “any 
(number) of links identifiers”.

That’s the typical example where the lack of a formal definition of the key for 
a (all) TLVs may brings interop issue. One implementer could believe that all 
link identifiers are needed in all parts, while another could believe that a 
subset is enough in some cases.
[LES:] We mean exactly what we say - "at least one".
It is not necessary to advertise all of the link identifiers in each TLV in 
order to correctly identify the two TLVs as having the same key.

There is a good deal that could be said here - but it is not the province of 
this document to do so. The issue you raise is applicable to a single TLV as 
well.
For example, A-B have an adjacency and advertise an IS-Neighbor TLV, the 
following works for the purposes of doing TWCC:

A advertises: (B system-id,  IPv4 endpoint addresses,   Local/Remote Link IDs)
B advertises: ( A system-id,  Local/Remote IDs)

If it takes two TLVs for A to advertise all of the link attribute information 
associated with the adjacency to B, A could advertise:

TLV #1: (B system-id,  IPv4 endpoint addresses,  Local/Remote Link IDs)
TLV #2: (B system-id,  Local/Remote Link IDs)

Receivers can still correctly identify the two TLVs as being associated with 
the same adjacency to B.
You may wish this was written down in some document - but multi-tlv draft is 
not the right place to do this. If needed, some update to RFC 5305 (et al) 
could be done. That is a decision for the WG to make.
___
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Bruno –

Thanx for the detailed comments.

Note that we have not yet fully determined what text changes should be made to 
the draft  – but hopefully this discussion will help us move forward.
I appreciate that this discussion is time consuming – but hopefully worth it 
for all of us.

BTW, I will be away for a few days the first part of next week (returning on 
Thursday August 15) – so responses may be delayed.

Please see inline.

From: bruno.decra...@orange.com 
Sent: Wednesday, August 7, 2024 6:03 AM
To: Yingzhen Qu ; lsr ; lsr-chairs 

Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi authors,

Please see below some possible comments on the draft.


  1.
§3 says
“TLVs sometimes contain information, called a key, that indicates the 
applicability of the remaining contents of the TLV. If a router advertises 
multiple TLV tuples with the same Type code in an IS-IS IIH packet or in the 
set of LSPs for a level with the same key value, they are considered a 
multi-part TLV (MP-TLV).”

I’m reading this as: TLV not having a key can’t be a MP-TLV.
If this is not the intention please clarify. (e.g. same key value if that TLV 
has a key)
If this is the intention, this seems to contradict with other text such as
§4 “If a Multi-part TLV contains information that specifies the applicability 
of its contents (i.e., a key), the key information MUST be replicated”
§6 “However, Multi-Part TLV procedures are potentially applicable to any 
codepoint that allows sub-TLVs to be included as part of the information 
advertised.”

[LES:] In order for MP-TLV to be applicable to a codepoint, there has to be the 
potential for more than 255 bytes of information to be advertised. (obvious 😊)
And if multiple TLVs are sent, there has to be a way to identify them as being 
associated with the same object (which is what the “key” does).
This is consistent with the statement “TLV not having a key can’t be a MP-TLV.”.
But there are some subtleties.
To use your example of the admin tag sub-TLVs, I agree that it is conceivable 
(though unlikely) that one could need to advertise more than 255 bytes of tags, 
yet the tag sub-TLVs themselves do not have a “key”.
Functionally however, as they are associated with a single prefix, they inherit 
the key from the parent codepoint.
(More comments on admin tag below).

In summary, I think we can do a better job of wording in this section – we will 
work on that.
But the existing text is correct in spirit.

2)
§4.1 (TLV 22)

“The key consists of the 7 octets of system ID and pseudonode number plus the 
link identifiers.”
OK. May be for extra clarify :s/the link identifiers/all links identifiers 
which are present

[LES:] We will make this change.

“The following key information MUST be replicated in each of the additional 
Extended IS Reachability TLVs:
  7 octets of system ID and pseudonode number
  At least one of the following identifiers”
It’s not clear to me whether you mean “all link identifiers” advertised in the 
first part (which would seem to match your above definition of the key) or “any 
(number) of links identifiers”.

That’s the typical example where the lack of a formal definition of the key for 
a (all) TLVs may brings interop issue. One implementer could believe that all 
link identifiers are needed in all parts, while another could believe that a 
subset is enough in some cases.
[LES:] We mean exactly what we say - "at least one".
It is not necessary to advertise all of the link identifiers in each TLV in 
order to correctly identify the two TLVs as having the same key.

There is a good deal that could be said here - but it is not the province of 
this document to do so. The issue you raise is applicable to a single TLV as 
well.
For example, A-B have an adjacency and advertise an IS-Neighbor TLV, the 
following works for the purposes of doing TWCC:

A advertises: (B system-id,  IPv4 endpoint addresses,   Local/Remote Link IDs)
B advertises: ( A system-id,  Local/Remote IDs)

If it takes two TLVs for A to advertise all of the link attribute information 
associated with the adjacency to B, A could advertise:

TLV #1: (B system-id,  IPv4 endpoint addresses,  Local/Remote Link IDs)
TLV #2: (B system-id,  Local/Remote Link IDs)

Receivers can still correctly identify the two TLVs as being associated with 
the same adjacency to B.
You may wish this was written down in some document - but multi-tlv draft is 
not the right place to do this. If needed, some update to RFC 5305 (et al) 
could be done. That is a decision for the WG to make.
3)
§5 Procedure for Receiving Multi-part TLVs
“If the internals of the TLV contain key information, then replication of the 
key information should be taken to indicate that subsequent data MUST be 
processed as if the subsequent data were concatenated after a single copy of 
the key information.”
May be :s/should/MUST
[LES:] We will make this change.
4)
§5 Procedure for Receiving Multi-part TLVs
“A TLV may conta

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Bruno –

Thanx for the response – and especially for your detailed comments on the draft 
(which you sent in a separate email).
It will take some time for authors to reach consensus on what if any changes to 
the draft should be made – please be patient while the authors discuss that.

In the meantime, some responses to this email inline.

From: bruno.decra...@orange.com 
Sent: Wednesday, August 7, 2024 6:02 AM
To: Les Ginsberg (ginsberg) ; Ketan Talaulikar 
; Yingzhen Qu 
Cc: lsr ; lsr-chairs 
Subject: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi Les,

Thanks for your detailed answer.
Please see inline.

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, August 6, 2024 5:40 PM
Bruno –

Thanx for the concerns.

Let’s dig deeper into the concerns about “interoperability”.
I will use IS Neighbors advertisements in this discussion – but conceptually 
the discussion applies to all codepoints – though obviously the specifics are 
different in each case.

It is important to note that this draft has not introduced any modification to 
the encoding of any existing TLV. The format and the set of sub-TLVs associated 
with a given codepoint are defined in the respective RFCs for each codepoint 
and are not altered by this draft.

It is important to note that this draft defines and requires the notion of a 
“key”, on a per TLV basis, which may not have been formally specified in some 
of the existing TLVs.

[LES:] It is true that you won’t find the word “key” in any of the RFCs which 
define the existing codepoint formats – but that does not mean we have 
introduced anything new.
Obviously, what uniquely identifies the object of a particular codepoint 
advertisement differs based on the advertisement type.
We introduced the term “key” as a generic term for these codepoint unique 
values – but as I have been emphasizing this in no way alters the encoding of 
any TLV/sub-TLV nor does it alter the processing on reception.
It just allows us to discuss the operational aspects using succinct and easily 
understandable language.
I do not see that by doing so any confusion should result.


In the case of IS-Neighbor, the correct identification of keys is already 
required for two reasons:

1)It determines the identity of the link/neighbor being advertised
2)It is necessary in order to correctly do two-way connectivity checking

Independent of multi-TLV, implementations MUST correctly process the keys or 
operation of the network is compromised.

The interoperability issues associated with multi-tlv do not arise because 
existing specifications are ambiguous as to what constitutes a key.

Well that’s my question and presumably also the point raised by Ketan: have all 
existing (sub) TLVs specified their “key”? Because this is major requirement of 
this document.
I’ve raised a point in a sub-sequent email which includes comments on the 
draft. I may obviously be wrong but I’m finding the current definition of the 
key a bit under specified for this TLV. (these TLVs)

[LES:] If there is under specification, it is not within the scope of this 
draft to correct that.
That would fall to an errata/update to the document which defines the codepoint.
I also think it would be helpful if you (or anyone else) provided a specific 
example where you believe under specification exists. It would then be easier 
to discuss the best way to address it.
But for multi-tlv, we are simply making use of the existing content. Indeed, 
one of the advantages of multi-tlv vs other solutions that have been discussed 
is that no additional content needs to be added to existing advertisements in 
order to support more than 255 bytes/object.

Interoperability issues result from some implementations treating two TLVs with 
matching keys in different ways:

Historically two TLVs with the same key have been treated as replacements for 
each other i.e., one TLV is treated as “stale” and one TLV is treated as the 
“current”.

Possibly but I’m not excluding that some specification are treating this error 
condition as “underdefined”. (or “out of scope for this document” as written in 
this document)
[LES:] The draft does not preclude this either. When all nodes in the network 
do not support (at least) reception of multi-tlvs for the same object, problems 
can and do occur. One of the ways this could manifest itself is that an 
implementation could ignore both of the TLVs.
But it isn’t necessary to make an exhaustive list of all the ways things could 
break. It is sufficient to make the point that partial deployment is 
problematic (which we do).

With multi-TLV, two TLVs with the same key are treated as complementary i.e., 
the information in both TLVs is treated as current.

If all routers in the network don’t apply the same interpretation to multiple 
TLVs with the same key, then we have (obvious) interoperability issues.
This is what is discussed in the draft and is the proper subject of the

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Aijun –

Choosing my words carefully…

There always is a key.
It is part of each TLV sent even when multi-tlv is not in use.
It is processed on receive even when multi-tlv is not in use.
It hasn’t been changed by multi-tlv. (NOTE: No encoding changes introduced by 
multi-tlv.)

Any interoperability issue related to key processing exists even in the absence 
of multi-tlv.

That understanding is fundamental to understanding how multi-tlv works.

   Les

From: Aijun Wang 
Sent: Tuesday, August 6, 2024 6:59 PM
To: Les Ginsberg (ginsberg) ; bruno.decra...@orange.com; 
'Ketan Talaulikar' ; 'Yingzhen Qu' 

Cc: 'lsr' ; 'lsr-chairs' 
Subject: 答复: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi, Les:

If there is no key, how “focused on the conceptual use of the key in support of 
multi-TLV.”?
And, how do you distinguish the situation that you described as “stale/current” 
replacement and both “current”?  Will it arise another interoperable problem?


Best Regards

Aijun Wang
China Telecom

发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> 
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年8月6日 23:40
收件人: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; Ketan 
Talaulikar mailto:ketant.i...@gmail.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>
抄送: lsr mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
主题: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Bruno –

Thanx for the concerns.

Let’s dig deeper into the concerns about “interoperability”.
I will use IS Neighbors advertisements in this discussion – but conceptually 
the discussion applies to all codepoints – though obviously the specifics are 
different in each case.

It is important to note that this draft has not introduced any modification to 
the encoding of any existing TLV. The format and the set of sub-TLVs associated 
with a given codepoint are defined in the respective RFCs for each codepoint 
and are not altered by this draft.

In the case of IS-Neighbor, the correct identification of keys is already 
required for two reasons:

1)It determines the identity of the link/neighbor being advertised
2)It is necessary in order to correctly do two-way connectivity checking

Independent of multi-TLV, implementations MUST correctly process the keys or 
operation of the network is compromised.

The interoperability issues associated with multi-tlv do not arise because 
existing specifications are ambiguous as to what constitutes a key.
Interoperability issues result from some implementations treating two TLVs with 
matching keys in different ways:

Historically two TLVs with the same key have been treated as replacements for 
each other i.e., one TLV is treated as “stale” and one TLV is treated as the 
“current”.
With multi-TLV, two TLVs with the same key are treated as complementary i.e., 
the information in both TLVs is treated as current.

If all routers in the network don’t apply the same interpretation to multiple 
TLVs with the same key, then we have (obvious) interoperability issues.
This is what is discussed in the draft and is the proper subject of the draft.

Keys for each TLV are defined in the respective RFCs that define each codepoint.
Repeating that information in this draft is at best redundant – at worst 
unintentionally conflicting – and clearly does not scale (we have hundreds of 
codepoints to which multi-TLV can be applied).

This is why we made the decision not to specify/discuss the “key” for every TLV 
– but focused on the conceptual use of the key in support of multi-TLV.

   Les


From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
mailto:bruno.decra...@orange.com>>
Sent: Tuesday, August 6, 2024 3:36 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Ketan Talaulikar mailto:ketant.i...@gmail.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Thanks Les for your reply.
Please see 1 comment inline [Bruno]

From: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Wednesday, July 3, 2024 8:53 PM
To: Ketan Talaulikar mailto:ketant.i...@gmail.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

CAUTION : This email originated outside the company. Do not click on any links 
or open attachments unless you are expecting them from the sender.
ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas 
sur les liens ou n'ouvrez pas les pièces jointes à moins de conna

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Bruno –

Thanx for the concerns.

Let’s dig deeper into the concerns about “interoperability”.
I will use IS Neighbors advertisements in this discussion – but conceptually 
the discussion applies to all codepoints – though obviously the specifics are 
different in each case.

It is important to note that this draft has not introduced any modification to 
the encoding of any existing TLV. The format and the set of sub-TLVs associated 
with a given codepoint are defined in the respective RFCs for each codepoint 
and are not altered by this draft.

In the case of IS-Neighbor, the correct identification of keys is already 
required for two reasons:

1)It determines the identity of the link/neighbor being advertised
2)It is necessary in order to correctly do two-way connectivity checking

Independent of multi-TLV, implementations MUST correctly process the keys or 
operation of the network is compromised.

The interoperability issues associated with multi-tlv do not arise because 
existing specifications are ambiguous as to what constitutes a key.
Interoperability issues result from some implementations treating two TLVs with 
matching keys in different ways:

Historically two TLVs with the same key have been treated as replacements for 
each other i.e., one TLV is treated as “stale” and one TLV is treated as the 
“current”.
With multi-TLV, two TLVs with the same key are treated as complementary i.e., 
the information in both TLVs is treated as current.

If all routers in the network don’t apply the same interpretation to multiple 
TLVs with the same key, then we have (obvious) interoperability issues.
This is what is discussed in the draft and is the proper subject of the draft.

Keys for each TLV are defined in the respective RFCs that define each codepoint.
Repeating that information in this draft is at best redundant – at worst 
unintentionally conflicting – and clearly does not scale (we have hundreds of 
codepoints to which multi-TLV can be applied).

This is why we made the decision not to specify/discuss the “key” for every TLV 
– but focused on the conceptual use of the key in support of multi-TLV.

   Les


From: bruno.decra...@orange.com 
Sent: Tuesday, August 6, 2024 3:36 AM
To: Les Ginsberg (ginsberg) ; Ketan Talaulikar 
; Yingzhen Qu 
Cc: lsr ; lsr-chairs 
Subject: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Thanks Les for your reply.
Please see 1 comment inline [Bruno]

From: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Wednesday, July 3, 2024 8:53 PM
To: Ketan Talaulikar mailto:ketant.i...@gmail.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

CAUTION : This email originated outside the company. Do not click on any links 
or open attachments unless you are expecting them from the sender.
ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas 
sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre 
l'expéditeur.

Ketan –

Thanx for the support.
Responses inline.

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Wednesday, July 3, 2024 9:56 AM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi All,

I thank the authors for the work on this draft and support its publication. 
This work was very much needed for the enablement of new feature sets in ISIS 
networks and the specification will aid interoperability.

My only "grudge" is something that I have brought up previously on this draft 
[1] and perhaps there may still be some interest in the WG/authors to take care 
of them?

1) Mandate that the non-key part is identical in all the parts and if not 
recommend that the value in the first part is taken. Or, say something about 
handling this condition than saying "error and out of scope".

[LES:] The authors discussed this aspect.
What we decided was that the scope of this draft was to clearly define the 
generic aspects of multi-tlv – not to discuss the peculiarities of any specific 
codepoint.
With that in mind, Section 4 – and specifically the examples provided – is 
meant only to illustrate what a “key” is.
There is considerably more that could be said about each specific codepoint – 
but we believe that is out of scope for this document.


2) Since the early versions of the draft, a lot of effort has been put on 
cataloguing TLV/sub-TLVs and their applicability for MP. From there, it is only 
one more step to actually specify the "key" and "non-key" parts of TLVs (where 
this is not done already) in an appendix section. This is important for 
int

[Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" - draft-ietf-lsr-distoptflood-05

[Les Ginsberg (ginsberg)]

Option #2

For reasons I have stated both on the list and in the recent WG meeting

   Les

> -Original Message-
> From: Acee Lindem 
> Sent: Friday, August 2, 2024 11:06 AM
> To: lsr 
> Subject: [Lsr] Consensus Call on "IS-IS Distributed Flooding Reduction" - 
> draft-
> ietf-lsr-distoptflood-05
> 
> 
> The subject draft was adopted as a WG document containing only the flooding
> reduction algorithm (section 2).
> 
> Procedures and signaling have been added to the current version allowing
> concurrent operation within an IS-IS area of IS-IS routers running different
> flooding reduction algorithms or no flooding reduction at all  (section 1).
> 
> WG members are questioning if this extra requirement needs to be met and
> included in this document. There was an extensive discussion during the IETF
> 120 LSR meeting and a MeetEcho show-of-hands poll was taken -
> https://notes.ietf.org/notes-ietf-120-lsr
> 
> Please indicate your preference and reasoning amongst the following options
> by August 17, 2024:
> 
>   1) The document remains in its current form describing both the flooding
> reduction algorithm signaling/procedures and the new flooding reduction
> algorithm.
>   2) The flooding reduction algorithm and procedures will be split into a
> separate document with its own LSR WG adoption call.
>   3) Some other resolution?
> 
> Thanks,
> Yingzhen, Chris, and Acee (LSR Chairs)
> ___
> Lsr mailing list -- lsr@ietf.org
> To unsubscribe send an email to lsr-le...@ietf.org
___
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

[Lsr] Re: Roman Danyliw's No Objection on draft-ietf-lsr-labv-registration-02: (with COMMENT)

[Les Ginsberg (ginsberg)]

Roman -



I am not an author on this draft - and I defer responses to your comments on 
this draft to the author.

However, I am the author of RFC 7370 - and am therefore responding to your 
comments on that document.

I don’t think it is within the purview of this review to raise questions about 
the content of RFC 7370.
As an IETF member you are certainly entitled to make such comments, but 
draft-ietf-lsr-labv-registration-02 is not making changes to RFC 7370 nor 
should it - so this isn’t the right context to make such comments.
Nevertheless, I will respond to your comments below.

I suggest that if you want to continue the discussion of RFC 7370, please start 
a separate thread and I will do my best to respond.



Please see inline.



> -Original Message-

> From: Roman Danyliw via Datatracker 

> Sent: Monday, July 29, 2024 11:54 AM

> To: The IESG 

> Cc: draft-ietf-lsr-labv-registrat...@ietf.org; lsr-cha...@ietf.org; 
> lsr@ietf.org;

> yingzhen.i...@gmail.com

> Subject: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-labv-

> registration-02: (with COMMENT)

>

> Roman Danyliw has entered the following ballot position for

> draft-ietf-lsr-labv-registration-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-labv-registration/

>

>

>

> --

> COMMENT:

> --

>

> Thank you to Ines Robles for the GENART review.

>

> ** Section 2

>

>The registration procedure for the "IS-IS Neighbor Link-Attribute Bit

>Values" registry is changed to be "Expert Review".  General guidance

>for the designated experts is defined in [RFC7370] and more specific

>guidance can be found in [RFC5029].

>

> I read through RFC5029 and didn’t find any text scoped as guidance to the

> designated expert.



[LES:] Though in this case I defer, I will mention that this text was added in 
response to a comment from Sue Hares in her ops-dir review.

I think the comment was intended to cover the point that in order to fully 
understand assignment of Bit Values one has to be familiar with RFC 5029.

This reference will, in any case, be included by IANA in the registry itself - 
so I think mention of it in the draft is benign but unnecessary.



>

> I read through Section 4 of RFC7370 and had the following questions:

>

> -- Per “The Designated Experts SHOULD then review the assignment requests

>  on their technical merit”, is there any further guidance?  When would the DE

> not evaluate the request on technical merits?

>

[LES:] I am not sure what you expect.

I point out that https://www.rfc-editor.org/rfc/rfc8126#section-4.5 cites the 
following as excellent examples:





Extensible Authentication Protocol (EAP) [RFC3748], Sections 6 and

  7.2

  North-Bound Distribution of Link-State and TE Information Using

  BGP [RFC7752], Section 5.1





In reading those two examples, I think that 
https://www.rfc-editor.org/rfc/rfc7370.html#section-4 compares well (just my 
opinion of course).



> -- Is the WG confident that “expert review” is the correct registration 
> policy?

>  I ask because the text in this section seems to be preferring a reference of

> some kind which hints that “specification required” (which also includes an

> expert review and could be an I-D) might be more appropriate.

>

[LES:] RFC 7370 was written specifically for IS-IS IANA registries - and all 
other IS-IS registries use Expert Review.  So I am completely confident that 
this is the correct choice.

"Specification Required" allows that non-IETF documents (see 
https://www.rfc-editor.org/rfc/rfc8126#section-4.6 ) could serve as the place 
where codepoints are defined and we did not want to allow that.



Thanx.



Les



> ** Idnits reported:

>

>   -- The draft header indicates that this document updates RFC5029, but the

>  abstract doesn't seem to directly say this.  It does mention RFC5029

>  though, so this could be OK.

>

> The abstract text explicitly needs text to the effect of “This document 
> updated

> RFC5029 ...”

>

>

>

> ___

> Lsr mailing list -- lsr@ietf.org

> To unsubscribe send an email to lsr-le...@ietf.org
_

[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and Purge LSA

[Les Ginsberg (ginsberg)]

Liyan –

Thanx for the thoughtful post.

There are two issues associated with the non-stateful restart of a router:

1)Ensuring that stales LSAs from the previous incarnation are flushed/updated 
before paths via the restarting router are calculated by nodes in the network.

2)Allowing for forwarding plane update time on the restarting router to 
complete before paths via the restarting router are installed into the 
forwarding planes of other routers in the network.

The better-idbx draft addresses #1 – and does so in a backwards compatible way 
– which is a significant win.

The adj-suppress draft addresses #2 – though it requires cooperation from the 
neighbors of the restarting router.

Up to now, I have advocated for a combination of both solutions – whether in 
two drafts or a single combined draft.
However, Acee has pointed out that the restarting router could – without 
requiring changes on the neighbors – initially generate new versions of its 
LSAs (particularly the Router LSA) which omit advertisement of the newly 
acquired neighbors until the forwarding plane has been populated on the 
restarting router. This addresses #2 above.

Given that Acee seems agreeable to add text into better-idbx (non-normative) to 
mention this option, I now feel that the introduction of the SA bit is not 
required. It can still be argued (as you have below) that use of the SA bit may 
more reliably address flooding delays, but the added benefits seem minimal to 
non-existent. And Acee’s proposal has the added benefits of not requiring 
changes on the neighbors. It also likely makes it easier for the restarting 
router to introduce special SPF logic to utilize the local adjacencies even 
though they are not currently advertised – which is necessary for the 
restarting router to populate its forwarding plane in advance of sending LSAs 
which will actually attract traffic.

As a matter of history, the SA bit was introduced to IS-IS back in RFC 5306. 
Since IS-IS does not have database exchange as a requirement to bring an 
adjacency up, something new had to be introduced to address the startup issue. 
SA bit was considered less disruptive than introducing non-backwards compatible 
changes to the adjacency state machine. Since IS-IS has the Overload Bit to 
prevent other routers from prematurely using the restarting router for transit 
traffic, there was no need to use the SA bit for that purpose. Since OSPF does 
not have the equivalent of the Overload bit, the additional step of having the 
restarting router initially not advertise its adjacencies is needed.

If you can convince the authors of better-idbx to add the SA bit, I would be 
fine with that – but it is hard to strongly advocate for that at this point.

Les



From: Liyan Gong 
Sent: Wednesday, July 17, 2024 7:05 PM
To: Christian Hopps ; Aijun Wang 
Cc: Tony Przygienda ; Acee Lindem ; 
Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak) 
; Yingzhen Qu ; lsr-chairs 
; shraddha ; lsr 
Subject: Re:[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re: About Premature 
aging of LSA and Purge LSA


Hi All，

Thank you for all your insightful discussions. I've given thoughtful 
consideration to all the points you've raised.

In response, I am trying to explain the solution of 
draft-cheng-lsr-ospf-adjacency-suppress. Hope it can address your concerns.

I've aimed to be comprehensive, but if I've missed anything or misunderstood 
any aspect, please don't hesitate to correct me or provide additional feedback.



1. As we have discussed, it is difficult to find a precise delay time because 
of the uncertainty of flooding, so we introduce a timer to control it. It has 
several benefits:

1)it can avoid the complexity of realization.

2)it can reslove the remote neighbor scenario

3)it facilitates for forwarding plane programming

4)it can avoid the neighbor machine deadlock

5)it is valid for the whole restart router/ospf process,we do not need to start 
the timer for each interface.

6)it is valid for all types of lsas. As we have explained previously, even 
though router-Lsas and network-Lsas have been re-originated, Type 5 routes may 
still have  problems.

2. This solution is controlled by the restart router. The neighbors only need 
to respond to the restart router.The advantages are reflected in the following 
aspects.

1) It complies with other extended features, such as GR, NSR,stub-router, 
reverse-metric. Usually，if you do/not want traffic to be sent to a specific 
router, the  controls are on the router itself, not neighbor routers. 
Controlling on the same side can prevent the neighbor routers from identifying 
different features and performing special processing when some features take 
effect at the same time.

2) Restarting router can distinguish interface restart and router restart, but 
the neighbor router can not.

3) It can be enabled by default on the restart router. Or else, The neighbor 
routers should enable the configurat

[Lsr] Re: About Premature aging of LSA and Purge LSA

[Les Ginsberg (ginsberg)]

Tony –

What is important to me here is a common understanding and providing a complete 
solution.

Hopefully, you are at least understanding that the point I am making is valid 
i.e., traffic loss can occur even with better-idbx in place.
I would also argue that you are underestimating the effect of scale.

As to your argument below,  it could also be used to argue against doing 
anything – after all we know that current OSPF does converge in a modest amount 
of time.

Since you have decided to make things better (which I support) I do not see why 
we should not define a complete solution.
If you, as a vendor, choose not to implement SA because you consider the 
cost/benefit ratio unappealing – that is your choice. So long as you and your 
customers are satisfied …

But our mission here is to define a solution – and I am simply arguing for a 
more complete solution.

  Les

From: Tony Przygienda 
Sent: Friday, July 12, 2024 11:23 AM
To: Acee Lindem 
Cc: Les Ginsberg (ginsberg) ; Liyan Gong 
; Aijun Wang ; Peter 
Psenak (ppsenak) ; Yingzhen Qu ; 
lsr ; lsr-chairs ; shraddha 

Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA

Les, whatever you try to suggest here, you slide into direction of trying to 
guarantee common knowledge closure (that's the technical term for what you try) 
and based on distributed systems theory you end up ultimately with virtual 
clock synchronization of the network in some form if you _really_ want to solve 
the problem rather than "hey, my stuff may work 2 hops away rather than 1 hop 
so it's much better and let's not talk about 3 hops" (look up at Lampert's 
clock vectors/matrices for proper theoretical underpinnings of such 
undertakings if you'd like to take this discussion further) and this will slow 
things to a crawl. Worse, you will discover pretty soon that going down this 
path you will have to learn consistent cuts and basically transaction 
scheduling most likley ;-)

IGPs are just IGPs, i.e. they do guarantee "eventual consistency" (in proper 
technical terms epsilon consistency) and that makes them fast and reacting fast 
to failures and that's the base of their success. This also means you have 
transients and this here is just one, relatively simple fix of a local 
transient and that's about the best you can do to preserve the desirable 
properties (i.e. fastest possible eventual consistency with maximum resiliency 
[that's the CAP paradigm part which is another way to see IGPs as _AP type of 
solution]).

Without this kind of underlying understanding/language we are talking about "me 
likes my stuff with me bells and whistles better than ye' thing" and it's going 
in circles AFAIS.

so I'm with acee here in short (and I left the fact out that as I say, flavor 
of this stuff is deployed since long time and works fine at any scale in our 
experience and it's damn' simple to implement comparatively speaking and 
doesn't need any big rollouts on the network] compared to all the signalling 
machinery suggested)

-- tony

On Fri, Jul 12, 2024 at 6:44 PM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
So, I don’t think the case you are suggesting is plausible. Let’s say you have 
a hypothetical router somewhere in the same area that has the restarting 
router’s stale LSAs.

1. The restarting router’s neighbors will only advertise an adjacency once 
the stale LSAs have been updated or purged from their local databases.
2. Only then will the adjacency be advertised - so the update or purge 
precedes the adjacency advertisement.
3. How is the neighbor router’s LSA going to pass the restarting router’s 
LSA update or purge? It will take the same or possibly even better flooding 
path. Will it be flooded at warp speed?
4. Are you suggesting that the restarting router’s LSAs are dropped but the 
neighbor’s advertisement is not? If so, how would the restarting router know 
this and delay removing the adjacency suppression? Are you relying on the 
inherent inefficiencies and convergence delays with LLS signaling handshake 
between the two routers?

In any case, trying to prevent transient problems due to selective loss of 
updates is an exercise in futility.

Thanks,
Acee




On Jul 12, 2024, at 12:13, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Acee –

When the restarting router goes down, the state of the LSDB in the network 
becomes:

Restart Router LSA: All neighbors advertised
Neighbor Routers: Neighbor to Restarting Router is removed

When the restarting router comes back up, two changes will occur:

1)Restarting Router updates its LSAs
2)Neighbors updates their LSAs to indicate it once again has a neighbor to the 
restarting router

You cannot guarantee the flooding order of network-wide.
Because the stale LSAs from the Restarting Router are present in all nodes, as 
soon as a neighbor readvertises the adjace

[Lsr] Re: About Premature aging of LSA and Purge LSA

[Les Ginsberg (ginsberg)]

Acee –

After your step #2 below, there are (at a minimum) two LSAs for the neighbor to 
flood:

a)The updated self-originated LSA advertising the reestablished neighbor to the 
restarting router
b)The updated LSA re-originated by the restarting router – which could include 
or exclude the established adjacency to the neighbor

Given that the reestablishment of the adjacency on the restarting router does 
not reflect updated forwarding state on the restarting router, it means that on 
any node which sees TWC between the restarting router and its neighbors traffic 
may be forwarded towards the restarting router before the forwarding plane on 
the restarting router has been programmed, resulting in traffic loss.

There are two ways that such premature TWC can occur:

1)Nodes receive the updated LSA from the neighbor and still have the stale LSA 
from the restarting router
2)Nodes receive the updated LSA from both the restarting router and the 
neighbor – both with the reestablished adjacency advertised

You have proposed that the restarting router provide an updated LSA without the 
adjacency to the neighbor advertised – which addresses Case #2.
But you have no solution to Case #1.
Case #1 can only be addressed by having the neighbor delay advertisement of the 
reestablished adjacency – which is what the SA mechanism does.
It also means that Case #2 will not occur.

It is true that these are transient issues which will correct themselves – but 
as the problem you are trying to address with your draft is addressing a 
transient issue, it seems relevant to address all aspects – which is what the 
combination of “better-idx” and SA will achieve.

   Les


From: Acee Lindem 
Sent: Friday, July 12, 2024 9:45 AM
To: Les Ginsberg (ginsberg) 
Cc: Liyan Gong ; Aijun Wang 
; Peter Psenak (ppsenak) ; 
Yingzhen Qu ; lsr ; lsr-chairs 
; tony Przygienda ; shraddha 

Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA

So, I don’t think the case you are suggesting is plausible. Let’s say you have 
a hypothetical router somewhere in the same area that has the restarting 
router’s stale LSAs.

1. The restarting router’s neighbors will only advertise an adjacency once 
the stale LSAs have been updated or purged from their local databases.
2. Only then will the adjacency be advertised - so the update or purge 
precedes the adjacency advertisement.
3. How is the neighbor router’s LSA going to pass the restarting router’s 
LSA update or purge? It will take the same or possibly even better flooding 
path. Will it be flooded at warp speed?
4. Are you suggesting that the restarting router’s LSAs are dropped but the 
neighbor’s advertisement is not? If so, how would the restarting router know 
this and delay removing the adjacency suppression? Are you relying on the 
inherent inefficiencies and convergence delays with LLS signaling handshake 
between the two routers?

In any case, trying to prevent transient problems due to selective loss of 
updates is an exercise in futility.

Thanks,
Acee




On Jul 12, 2024, at 12:13, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Acee –

When the restarting router goes down, the state of the LSDB in the network 
becomes:

Restart Router LSA: All neighbors advertised
Neighbor Routers: Neighbor to Restarting Router is removed

When the restarting router comes back up, two changes will occur:

1)Restarting Router updates its LSAs
2)Neighbors updates their LSAs to indicate it once again has a neighbor to the 
restarting router

You cannot guarantee the flooding order of network-wide.
Because the stale LSAs from the Restarting Router are present in all nodes, as 
soon as a neighbor readvertises the adjacency to the restarting router, it is 
now possible that on some nodes in the network you will temporarily have an 
LSDB which has:

Stale LSA from restarting router + Updated LSA from neighbor

Whether the restarting router sends an updated LSA with neighbors or without 
neighbors (as you suggest) you cannot prevent the above transient condition 
from occurring because doing so requires guaranteeing that the update to the 
Neighbor LSA and the update to the restarting router LSA are done atomically 
network-wide.
That is why the restarting router cannot do this without help from the 
neighbors.

Hope this is clear.

Les


From: Acee Lindem mailto:acee.i...@gmail.com>>
Sent: Friday, July 12, 2024 7:55 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Liyan Gong mailto:gongli...@chinamobile.com>>; 
Aijun Wang mailto:wangai...@tsinghua.org.cn>>; Peter 
Psenak (ppsenak) mailto:ppse...@cisco.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>; tony Przygienda 
mailto:tonysi...@gmail.com>>; shraddha 
mailto:shrad...@juniper.net>>
Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA





On Jul 12, 2024, at

[Lsr] Re: About Premature aging of LSA and Purge LSA

[Les Ginsberg (ginsberg)]

Acee –

When the restarting router goes down, the state of the LSDB in the network 
becomes:

Restart Router LSA: All neighbors advertised
Neighbor Routers: Neighbor to Restarting Router is removed

When the restarting router comes back up, two changes will occur:

1)Restarting Router updates its LSAs
2)Neighbors updates their LSAs to indicate it once again has a neighbor to the 
restarting router

You cannot guarantee the flooding order of network-wide.
Because the stale LSAs from the Restarting Router are present in all nodes, as 
soon as a neighbor readvertises the adjacency to the restarting router, it is 
now possible that on some nodes in the network you will temporarily have an 
LSDB which has:

Stale LSA from restarting router + Updated LSA from neighbor

Whether the restarting router sends an updated LSA with neighbors or without 
neighbors (as you suggest) you cannot prevent the above transient condition 
from occurring because doing so requires guaranteeing that the update to the 
Neighbor LSA and the update to the restarting router LSA are done atomically 
network-wide.
That is why the restarting router cannot do this without help from the 
neighbors.

Hope this is clear.

Les


From: Acee Lindem 
Sent: Friday, July 12, 2024 7:55 AM
To: Les Ginsberg (ginsberg) 
Cc: Liyan Gong ; Aijun Wang 
; Peter Psenak (ppsenak) ; 
Yingzhen Qu ; lsr ; lsr-chairs 
; tony Przygienda ; shraddha 

Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA




On Jul 12, 2024, at 10:49, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Acee –

The neighbors do not control when the flooding of the purge/update reaches all 
routers in the network.
The neighbors have direct control of the exchange between themselves and their 
immediate neighbors – nothing else.

The restarting router has no better idea. If you’re suggesting suppressing 
advertising adjacencies until all neighbors of the restarting router are 
adjacent (which is a bad idea), the restarting router can do this as well by 
suppressing its link advertisements. There is NOTHING additional that can be 
accomplished by adding LLS signaling.

Acee






   Les

From: Acee Lindem mailto:acee.i...@gmail.com>>
Sent: Friday, July 12, 2024 7:44 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Liyan Gong mailto:gongli...@chinamobile.com>>; 
Aijun Wang mailto:wangai...@tsinghua.org.cn>>; Peter 
Psenak (ppsenak) mailto:ppse...@cisco.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>; tony Przygienda 
mailto:tonysi...@gmail.com>>; shraddha 
mailto:shrad...@juniper.net>>
Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA





On Jul 12, 2024, at 10:40, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Acee –

Having the restarting router suppress advertisement of its adjacencies does not 
address the transient state where routers in the network have received the 
updated LSA from the neighbor with the reestablished adjacency to the 
restarting router but still have the stale LSA from the restarting router that 
has the pre-restart adjacency advertisements. (point #1 I made below).

The neighbors of the restarting router will not advertise the adjacency until 
the stale LSAs are purged or updated - this is the whole point of 
https://datatracker.ietf.org/doc/draft-hegde-lsr-ospf-better-idbx/


Thanks,
Acee







So this is not a robust solution.

   Les

From: Acee Lindem mailto:acee.i...@gmail.com>>
Sent: Friday, July 12, 2024 7:21 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Liyan Gong mailto:gongli...@chinamobile.com>>; 
Aijun Wang mailto:wangai...@tsinghua.org.cn>>; Peter 
Psenak (ppsenak) mailto:ppse...@cisco.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>; tony Przygienda 
mailto:tonysi...@gmail.com>>; shraddha 
mailto:shrad...@juniper.net>>
Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA

Hi Les,




On Jul 12, 2024, at 02:57, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

I am happy that work on this problem has begun.
I believe the most robust way forward is to implement the mechanisms defined in 
BOTH drafts.

I think the mechanism defined in draft-hegde-lsr-ospf-better-idbx is sound and 
not overly complex (sorry Liyan 😊) and should be done.
But it does not solve all aspects of the problem.
It does make LSDB synchronization more robust – which addresses the control 
plane aspects of the problem.
It also has the advantage that it does not require any support on the 
neighboring routers – and so the benefits can be realized simply by upgrading 
one router at a time.

However,  draft-hegde-lsr-ospf-better-idbx does not address forwarding plane 
aspects of the problem – which be

[Lsr] Re: About Premature aging of LSA and Purge LSA

[Les Ginsberg (ginsberg)]

Acee –

The neighbors do not control when the flooding of the purge/update reaches all 
routers in the network.
The neighbors have direct control of the exchange between themselves and their 
immediate neighbors – nothing else.

   Les

From: Acee Lindem 
Sent: Friday, July 12, 2024 7:44 AM
To: Les Ginsberg (ginsberg) 
Cc: Liyan Gong ; Aijun Wang 
; Peter Psenak (ppsenak) ; 
Yingzhen Qu ; lsr ; lsr-chairs 
; tony Przygienda ; shraddha 

Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA




On Jul 12, 2024, at 10:40, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Acee –

Having the restarting router suppress advertisement of its adjacencies does not 
address the transient state where routers in the network have received the 
updated LSA from the neighbor with the reestablished adjacency to the 
restarting router but still have the stale LSA from the restarting router that 
has the pre-restart adjacency advertisements. (point #1 I made below).

The neighbors of the restarting router will not advertise the adjacency until 
the stale LSAs are purged or updated - this is the whole point of 
https://datatracker.ietf.org/doc/draft-hegde-lsr-ospf-better-idbx/


Thanks,
Acee






So this is not a robust solution.

   Les

From: Acee Lindem mailto:acee.i...@gmail.com>>
Sent: Friday, July 12, 2024 7:21 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Liyan Gong mailto:gongli...@chinamobile.com>>; 
Aijun Wang mailto:wangai...@tsinghua.org.cn>>; Peter 
Psenak (ppsenak) mailto:ppse...@cisco.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>; tony Przygienda 
mailto:tonysi...@gmail.com>>; shraddha 
mailto:shrad...@juniper.net>>
Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA

Hi Les,



On Jul 12, 2024, at 02:57, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

I am happy that work on this problem has begun.
I believe the most robust way forward is to implement the mechanisms defined in 
BOTH drafts.

I think the mechanism defined in draft-hegde-lsr-ospf-better-idbx is sound and 
not overly complex (sorry Liyan 😊) and should be done.
But it does not solve all aspects of the problem.
It does make LSDB synchronization more robust – which addresses the control 
plane aspects of the problem.
It also has the advantage that it does not require any support on the 
neighboring routers – and so the benefits can be realized simply by upgrading 
one router at a time.

However,  draft-hegde-lsr-ospf-better-idbx does not address forwarding plane 
aspects of the problem – which become more significant at scale.
There are two aspects of this problem:

1)You do not have control over the order in which the updated LSAs are flooded 
to the rest of the network – so it is still possible for transient forwarding 
issues to occur multiple hops away from the restarting router.
2)The restarting router requires additional time – after full LSDB sync – to 
program the forwarding plane. It is well known that update of the forwarding 
plane takes much longer than protocol SPF calculation.
If only a few hundred routes are supported, this may not be of significant 
concern, but if thousands of routes are supported the time it takes to program 
the forwarding plane becomes a significant contributor.

I fail to see how suppressing neighbor adjacency advertisement solves any 
additional problems that are not solved by avoiding usage of the restarting 
router’s stale LSAs.

Note that the OSPF SPF has a check for bi-directional connectivity,  excerpted 
from section 16.1 of RFC2328:



(b) Otherwise, W is a transit vertex (router or transit

network).  Look up the vertex W's LSA (router-LSA or

network-LSA) in Area A's link state database.  If the

LSA does not exist, or its LS age is equal to MaxAge, or

it does not have a link back to vertex V, examine the

next link in V's LSA.[23]



Consequently, the restarting router can simply suppress its own link 
advertisement until such time that is required to solve the above problems. You 
should be familiar with this quote:


  “If you want a thing done well, do it yourself.”
  ― Napoleon Bonaparte


Thanks,
Acee








draft-cheng-lsr-ospf-adjacency-suppress  provides a way to address the above 
two aspects by providing a means for the neighbors of the restarting router to 
delay advertisement of the restored adjacency to the restarting router. (SA 
signaling)

It could be argued that using SA signaling eliminates the need to do anything 
else – but given that this mechanism depends upon support by all the neighbors 
of the restarting router I believe there is still good reason to implement both 
mechanisms.

NOTE: I would prefer that the two drafts be combined into a 

[Lsr] Re: About Premature aging of LSA and Purge LSA

[Les Ginsberg (ginsberg)]

Acee –

Having the restarting router suppress advertisement of its adjacencies does not 
address the transient state where routers in the network have received the 
updated LSA from the neighbor with the reestablished adjacency to the 
restarting router but still have the stale LSA from the restarting router that 
has the pre-restart adjacency advertisements. (point #1 I made below).

So this is not a robust solution.

   Les

From: Acee Lindem 
Sent: Friday, July 12, 2024 7:21 AM
To: Les Ginsberg (ginsberg) 
Cc: Liyan Gong ; Aijun Wang 
; Peter Psenak (ppsenak) ; 
Yingzhen Qu ; lsr ; lsr-chairs 
; tony Przygienda ; shraddha 

Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA

Hi Les,


On Jul 12, 2024, at 02:57, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

I am happy that work on this problem has begun.
I believe the most robust way forward is to implement the mechanisms defined in 
BOTH drafts.

I think the mechanism defined in draft-hegde-lsr-ospf-better-idbx is sound and 
not overly complex (sorry Liyan 😊) and should be done.
But it does not solve all aspects of the problem.
It does make LSDB synchronization more robust – which addresses the control 
plane aspects of the problem.
It also has the advantage that it does not require any support on the 
neighboring routers – and so the benefits can be realized simply by upgrading 
one router at a time.

However,  draft-hegde-lsr-ospf-better-idbx does not address forwarding plane 
aspects of the problem – which become more significant at scale.
There are two aspects of this problem:

1)You do not have control over the order in which the updated LSAs are flooded 
to the rest of the network – so it is still possible for transient forwarding 
issues to occur multiple hops away from the restarting router.
2)The restarting router requires additional time – after full LSDB sync – to 
program the forwarding plane. It is well known that update of the forwarding 
plane takes much longer than protocol SPF calculation.
If only a few hundred routes are supported, this may not be of significant 
concern, but if thousands of routes are supported the time it takes to program 
the forwarding plane becomes a significant contributor.

I fail to see how suppressing neighbor adjacency advertisement solves any 
additional problems that are not solved by avoiding usage of the restarting 
router’s stale LSAs.

Note that the OSPF SPF has a check for bi-directional connectivity,  excerpted 
from section 16.1 of RFC2328:



(b) Otherwise, W is a transit vertex (router or transit

network).  Look up the vertex W's LSA (router-LSA or

network-LSA) in Area A's link state database.  If the

LSA does not exist, or its LS age is equal to MaxAge, or

it does not have a link back to vertex V, examine the

next link in V's LSA.[23]



Consequently, the restarting router can simply suppress its own link 
advertisement until such time that is required to solve the above problems. You 
should be familiar with this quote:


  “If you want a thing done well, do it yourself.”
  ― Napoleon Bonaparte


Thanks,
Acee







draft-cheng-lsr-ospf-adjacency-suppress  provides a way to address the above 
two aspects by providing a means for the neighbors of the restarting router to 
delay advertisement of the restored adjacency to the restarting router. (SA 
signaling)

It could be argued that using SA signaling eliminates the need to do anything 
else – but given that this mechanism depends upon support by all the neighbors 
of the restarting router I believe there is still good reason to implement both 
mechanisms.

NOTE: I would prefer that the two drafts be combined into a single draft – but 
that is optional and up to the authors. But from the WG perspective I would 
like to see both solutions progress.

   Les



From: Liyan Gong mailto:gongli...@chinamobile.com>>
Sent: Thursday, July 11, 2024 8:22 PM
To: Acee Lindem mailto:acee.i...@gmail.com>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>; tony Przygienda 
mailto:tonysi...@gmail.com>>; shraddha 
mailto:shrad...@juniper.net>>
Subject: [Lsr] Re: About Premature aging of LSA and Purge LSA

Hi Acee and Aijun,

Thank you very much for your discussion. I would like to share my thoughts on 
the proposed solutions.
In my view, draft-hegde-lsr-ospf-better-idbx  may not be as straight forward as 
it initially appears.
Despite its local applicability, it entails a complex neighbor establishment 
process, which is fundamental to the OSPF protocol and typically not altered 
lightly by those familiar with its workings.
On the other hand, draft-cheng-lsr-ospf-adjacency-s

[Lsr] Re: About Premature aging of LSA and Purge LSA

[Les Ginsberg (ginsberg)]

I am happy that work on this problem has begun.
I believe the most robust way forward is to implement the mechanisms defined in 
BOTH drafts.

I think the mechanism defined in draft-hegde-lsr-ospf-better-idbx is sound and 
not overly complex (sorry Liyan 😊) and should be done.
But it does not solve all aspects of the problem.
It does make LSDB synchronization more robust – which addresses the control 
plane aspects of the problem.
It also has the advantage that it does not require any support on the 
neighboring routers – and so the benefits can be realized simply by upgrading 
one router at a time.

However,  draft-hegde-lsr-ospf-better-idbx does not address forwarding plane 
aspects of the problem – which become more significant at scale.
There are two aspects of this problem:

1)You do not have control over the order in which the updated LSAs are flooded 
to the rest of the network – so it is still possible for transient forwarding 
issues to occur multiple hops away from the restarting router.
2)The restarting router requires additional time – after full LSDB sync – to 
program the forwarding plane. It is well known that update of the forwarding 
plane takes much longer than protocol SPF calculation.
If only a few hundred routes are supported, this may not be of significant 
concern, but if thousands of routes are supported the time it takes to program 
the forwarding plane becomes a significant contributor.

draft-cheng-lsr-ospf-adjacency-suppress  provides a way to address the above 
two aspects by providing a means for the neighbors of the restarting router to 
delay advertisement of the restored adjacency to the restarting router. (SA 
signaling)

It could be argued that using SA signaling eliminates the need to do anything 
else – but given that this mechanism depends upon support by all the neighbors 
of the restarting router I believe there is still good reason to implement both 
mechanisms.

NOTE: I would prefer that the two drafts be combined into a single draft – but 
that is optional and up to the authors. But from the WG perspective I would 
like to see both solutions progress.

   Les



From: Liyan Gong 
Sent: Thursday, July 11, 2024 8:22 PM
To: Acee Lindem ; Aijun Wang 
Cc: Peter Psenak (ppsenak) ; Yingzhen Qu 
; lsr ; lsr-chairs 
; tony Przygienda ; shraddha 

Subject: [Lsr] Re: About Premature aging of LSA and Purge LSA


Hi Acee and Aijun,



Thank you very much for your discussion. I would like to share my thoughts on 
the proposed solutions.

In my view, draft-hegde-lsr-ospf-better-idbx  may not be as straight forward as 
it initially appears.

Despite its local applicability, it entails a complex neighbor establishment 
process, which is fundamental to the OSPF protocol and typically not altered 
lightly by those familiar with its workings.

On the other hand, draft-cheng-lsr-ospf-adjacency-suppress  presents a more 
focused approach tailored to address the specific issue without unintended 
consequences.

I still believe the key factor in evaluating any approach is whether it impacts 
the current systems negatively.



Regarding our extensive discussions on these drafts, please refer to our 
previous records for more details.

https://mailarchive.ietf.org/arch/search/?q=%22draft-cheng-lsr-ospf-adjacency-suppress%22



Thank you for your attention to this matter.



Best Regards,

Liyan


邮件原文
发件人：Acee Lindem  mailto:acee.i...@gmail.com>>
收件人：Aijun Wang  mailto:wangai...@tsinghua.org.cn>>
抄　送: Peter Psenak  mailto:ppse...@cisco.com>>,Yingzhen Qu  
mailto:yingzhen.i...@gmail.com>>,lsr  
mailto:lsr@ietf.org>>,lsr-chairs  
mailto:lsr-cha...@ietf.org>>,tony Przygienda  
mailto:tonysi...@gmail.com>>,shraddha  
mailto:shrad...@juniper.net>>
发送时间：2024-07-11 23:26:57
主题：[Lsr] Re: About Premature aging of LSA and Purge LSA

As WG member:

On Jul 11, 2024, at 05:29, Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:

And, there is also another draft aims to solve the similar problem 
https://datatracker.ietf.org/doc/html/draft-cheng-lsr-ospf-adjacency-suppress-02,
 which it declares similar with the solution in IS-IS.   Why not take this 
approach?

Because this one doesn’t require any signaling and can accomplished via local 
behavior without requiring support from any other OSPF router. Additionally, it 
is simpler.. Well, at least for someone who has a deep understanding of the 
protocol.

Thanks,
Acee



Best Regards

Aijun Wang
China Telecom

发件人: forwardingalgori...@ietf.org 
[mailto:forwardingalgori...@ietf.org] 代表 Aijun Wang
发送时间: 2024年7月11日 17:20
收件人: 'Acee Lindem' mailto:acee.i...@gmail.com>>
抄送: 'Peter Psenak' mailto:ppse...@cisco.com>>; 'Yingzhen Qu' 
mailto:yingzhen.i...@gmail.com>>; 'lsr' 
mailto:lsr@ietf.org>>; 'lsr-chairs' 
mailto:lsr-cha...@ietf.org>>; 'tony Przygienda' 
mailto:tonysi...@gmail.com>>; 'shraddha' 
mailto:shrad...@juniper.net>>
主题: [Lsr] 答复: Re: About Premature aging of LSA and Purge LSA

For the neighbors of the 

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Aijun –

Please see inline.

From: Aijun Wang 
Sent: Wednesday, July 3, 2024 7:55 PM
To: Les Ginsberg (ginsberg) ; 'Ketan Talaulikar' 
; 'Yingzhen Qu' 
Cc: 'lsr' ; 'lsr-chairs' 
Subject: 答复: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi, Les:


1) If the document doesn’t specify the key field part of each possible 
multi-part TLV and multi-part sub-TLV, how can you avoid the interoperability 
problem in the deployment? What’s the value then to let the vendors to comply 
with this specification?



[LES:] The value of the document is that it standardizes MP-TLV as the 
mechanism to be used in cases where more than 255 bytes of information about a 
given object needs to be advertised.

This applies to codepoints which are currently defined as well as any new 
codepoints defined in the future.

There is no longer any reason to consider alternative mechanisms and the use of 
other mechanisms would be in violation of this RFC-to-be.



2) Even for the “MP-TLV Capability Advertisement” in your document, as 
described within it:

The sub-TLV intentionally does not provide a syntax to specify MP-TLV support 
on a per-codepoint basis. It is presumed that if such support is provided that 
it applies to all relevant codepoints. It is understood that in reality, a 
given implementation might limit MP-TLV support to particular codepoints based 
on the needs of the deployment scenarios in which it is 
used.¶<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-01#section-7.2-7>
Are the above statements are contradict themselves: It declares that it applies 
to all, but in reality it is not.
What’s the usage of above false positive announcement then?

[LES:] Section 7.2 needs to be read in its entirety to appreciate the goals and 
limitations.
It is clearly stated that the new sub-TLV is only providing an informational 
indication to the operator.
Complete definition of what is supported by an implementation is not a function 
of the routing protocol itself.
Rather it is the role of conformance documents. Note that the means to provide 
a complete definition of what a given implementation supports has been started. 
See:

https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-srmpls-yang/
https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-yang/

We welcome input on these drafts – which are still in early stages.


3)   Even for your onerous descriptions in your IANA considerations, there is 
also error, for example, for the IPv6 SRLG(code point 139), which is specified 
not applied for the MP-TLV, but the associated RFC 6119, states clearly that 
“The IPv6 SRLG TLV MAY occur more than once within the IS-IS logical LSP“, even 
in the description of “introduction” part of your document.

[LES:] There is an error – but it is not what you have pointed out.
There are three SRLG related codepoints and three different RFCs that are 
relevant:

RFC 5307 which defines the IPv4 SRLG TLV(138). This specification does not 
state whether multiple TLVs for the same link are allowed.

RFC 6119 which defines the IPv6 SRLG TLV(139). This specification explicitly 
states in Section 4.4: “There MUST NOT be more than one IPv6 SRLG TLV for a 
given link.”

RFC 9479 which defines the ASLA SRLG TLV(238). This specification explicitly 
states in Section 4.3: “Multiple TLVs for the same link MAY be advertised.”

The error in this draft is not in the IANA section (as you suggested) but 
rather that we state in the Introduction that the IPv6 SRLG TLV (139) 
explicitly specifies the use of multiple TLVs when in fact RFC 6119 states the 
opposite.
Thanx for calling our attention to this issue – we will correct the statement 
in the Introduction.

As for resolving the inconsistency among the three RFCs mentioned above, that 
should be done – but it is outside the scope of this draft.

   Les


From the above all, we can see that this document is far from to solve the 
mentioned question, will only lead to more chaos within the network.
We should not forward this document at the current stage.

More works should be done to solve the issue.


Best Regards

Aijun Wang
China Telecom


发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> 
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年7月4日 2:53
收件人: Ketan Talaulikar mailto:ketant.i...@gmail.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
抄送: lsr mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
主题: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Ketan –

Thanx for the support.
Responses inline.

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Wednesday, July 3, 2024 9:56 AM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: [Lsr] Re: WG Last Call for draft-iet

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

Ketan –

Thanx for the support.
Responses inline.

From: Ketan Talaulikar 
Sent: Wednesday, July 3, 2024 9:56 AM
To: Yingzhen Qu 
Cc: lsr ; lsr-chairs 
Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 
7/15/2024)

Hi All,

I thank the authors for the work on this draft and support its publication. 
This work was very much needed for the enablement of new feature sets in ISIS 
networks and the specification will aid interoperability.

My only "grudge" is something that I have brought up previously on this draft 
[1] and perhaps there may still be some interest in the WG/authors to take care 
of them?

1) Mandate that the non-key part is identical in all the parts and if not 
recommend that the value in the first part is taken. Or, say something about 
handling this condition than saying "error and out of scope".

[LES:] The authors discussed this aspect.
What we decided was that the scope of this draft was to clearly define the 
generic aspects of multi-tlv – not to discuss the peculiarities of any specific 
codepoint.
With that in mind, Section 4 – and specifically the examples provided – is 
meant only to illustrate what a “key” is.
There is considerably more that could be said about each specific codepoint – 
but we believe that is out of scope for this document.


2) Since the early versions of the draft, a lot of effort has been put on 
cataloguing TLV/sub-TLVs and their applicability for MP. From there, it is only 
one more step to actually specify the "key" and "non-key" parts of TLVs (where 
this is not done already) in an appendix section. This is important for 
interoperability. The draft today covers two of the most prominent TLVs but 
does not cover the others.

[LES:] Again, the intent of this document is to clearly describe the generic 
Multi-TLV mechanism – not to discuss the specifics of each codepoint. To do so 
would expand the scope of the document beyond any reasonable boundaries.
For example, in the case of Neighbor TLVs (such as TLV 22), there are a wide 
variety of implementation strategies.
Some implementations send only LinkIDs all the time.
Some implementations send endpoint addresses (when available) and not Link IDs.
Some implementations send endpoint addresses and Link IDs.
All of these options are valid – but may impact interoperability depending on 
the “generosity” of the receivers.
And some commonality is required – independent of Multi-TLV – in order for 
two-way connectivity check to work correctly.

It is not in the scope of this document to include such a discussion – and the 
use of Multi-TLV does not introduce new issues in this regard.
This is why we restricted ourselves to only discussing “what a key is” in the 
examples.
The discussion – even for the two examples - is not exhaustive and is not meant 
to be.

If there is a significant interoperability issue with a particular codepoint, 
some other document will have to be written/updated to address that.

   Les

That said, I won't hold this document if I am in the rough on this.

Thanks,
Ketan

[1] https://mailarchive.ietf.org/arch/msg/lsr/qQkeAHnw2qjrGoySbES4EVafgY4/


On Tue, Jul 2, 2024 at 11:39 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:

Hi,



This email begins a 2 week WG Last Call for the following draft: 
draft-ietf-lsr-multi-tlv-01 - Multi-part TLVs in 
IS-IS



Please review the document and indicate your support or objections by July 
15th, 2024.

Authors,



Please indicate to the list, your knowledge of any IPR related to this work.



Thanks,

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

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Les Ginsberg (ginsberg)]

I am not aware of any IPR related to this work.

Supporting as co-author.

Les

From: Yingzhen Qu 
Sent: Monday, July 1, 2024 11:08 PM
To: lsr ; lsr-chairs 
Subject: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)


Hi,



This email begins a 2 week WG Last Call for the following draft: 
draft-ietf-lsr-multi-tlv-01 - Multi-part TLVs in 
IS-IS



Please review the document and indicate your support or objections by July 
15th, 2024.

Authors,



Please indicate to the list, your knowledge of any IPR related to this work.



Thanks,

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

[Lsr] Re: WG Last Call for draft-ietf-lsr-ospf-admin-tags

[Les Ginsberg (ginsberg)]

I support the advancement of this draft.
Use of admin tags is commonplace for multiple applications. Current limitations 
of the OSPF protocol in regards to tags do not meet the requirements of 
current/future deployments (as detailed in the draft).
This draft brings OSPF on a par with IS-IS in this regard.

   Les


> -Original Message-
> From: Christian Hopps 
> Sent: Monday, June 17, 2024 11:42 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org; lsr-...@ietf.org; draft-ietf-lsr-ospf-admin-
> t...@ietf.org
> Subject: [Lsr] WG Last Call for draft-ietf-lsr-ospf-admin-tags
> 
> 
> This begins a 2 week WG Last Call, ending Monday July 1st, 2024, for:
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags
> 
> Authors,
> 
> Please indicate to the list, your knowledge of any IPR related to this work.
> 
> Thanks,
> Chris.

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

[Lsr] WG Adoption Call for PICS Drafts

[Les Ginsberg (ginsberg)]

WG Chairs -

The authors of:

https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-srmpls-yang/
https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-yang/

request WG adoption for these two drafts.

Thanx for your prompt attention to this request.

  Les (on behalf of the draft authors)




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

[Lsr] Re: Opsdir last call review of draft-ietf-lsr-labv-registration-01

[Les Ginsberg (ginsberg)]

Sue/Tony -

Speaking as one of the designated experts for many IS-IS registries...

If one searches 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
you will see that IANA lists all of the RFCs relevant to a given registry. 
For example, for the registry being modified by this draft we currently have:


IS-IS Neighbor Link-Attribute Bit Values
...
Reference
[RFC5029][RFC-ietf-lsr-dynamic-flooding-18]


Once this document is published IANA will add RFC7370 to the relevant 
references in the registry.
I therefore feel there is no issue and no need to update the document as Tony 
has suggested.

   Les


> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Wednesday, June 26, 2024 8:06 AM
> To: Susan Hares 
> Cc: ops-...@ietf.org; draft-ietf-lsr-labv-registration@ietf.org; last-
> c...@ietf.org; lsr 
> Subject: [Lsr] Re: Opsdir last call review of 
> draft-ietf-lsr-labv-registration-01
> 
> 
> 
> > On Jun 26, 2024, at 4:51 AM, Susan Hares via Datatracker
>  wrote:
> >
> > Reviewer: Susan Hares
> > Review result: Has Nits
> >
> > Type of review: OPS-DIR
> > Editorial comments: none
> >
> > Process comments:  Normally, it is useful to give some advice to the
> designated
> > experts for the specific registry. RFC5029 gives sufficient advice, but the
> > document does not point backward tward RFC5029.
> >
> > The designated experts listed for the registry will know the right thing to 
> > do.
> > However, in the future this registry might have different designated 
> > experts.
> 
> 
> Hi Sue,
> 
> Thank you for your comment.  I would like to propose the following change:
> 
> OLD
> 
>General guidance
>for the designated experts is defined in [RFC7370].
> 
> NEW
> 
>General guidance
>for the designated experts is defined in [RFC7370] and more specific
>guidance can be found in [RFC5029].
> 
> 
> Would this address your concern?
> 
> Thanks,
> Tony
> 
> ___
> Lsr mailing list -- lsr@ietf.org
> To unsubscribe send an email to lsr-le...@ietf.org
___
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

[Lsr] Re: Comments on draft-ietf-lsr-distoptflood-04

[Les Ginsberg (ginsberg)]

Tony –

Thanx for the prompt response.

Please see inline.

From: Tony Przygienda 
Sent: Tuesday, June 25, 2024 6:44 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org; draft-ietf-lsr-distoptflood.auth...@ietf.org
Subject: Re: [Lsr] Comments on draft-ietf-lsr-distoptflood-04


Les, thanks for reading the draft. To start, I see no technical objections or 
suggestions from your side I could address.

[LES:] Please see my original point #1 below.

And what you ask for/claim/object to is WG chair/AD scope AFAIU so I just keep 
the answer short as WG participant from my side.



[LES:] I considered asking the WG chairs to “enforce” the original scope of the 
draft, but I was/am hoping that we can have a friendly conversation and reach 
consensus without asking for “the police”.



First, dynamic-flooding draft you mention is experimental work and I don’t know 
how it is structured or what it contains even plays in this discussion here 
except addressing somewhat similar problem. Both drafts are obviously 
independent experiments per the draft/rfc tracks and further, I did not see any 
kind of “scope restriction” on the adoption call on either and neither is the 
new version of distopflood doing something completely unrelated to the previous 
versions (footnote: as matter of gratuity we included considerations allowing 
to deploy it in presence of dynamic-flooding).



[LES:] As a WG member, I read the early versions of the draft. The content was 
limited to definition of the flooding algorithm. That is what I endorsed when I 
supported adoption of the draft. This is primarily what is Section 2 of both 
the older versions and latest version of the draft.

In V4 you introduced definition of a new control mechanism for the actual 
enablement of the algorithm in Section 1 (a section heavily rewritten from V3) 
and the introduction of new IANA requirements (though you neglect to mention in 
the IANA section the new code point you define in Section 1.4).

I never anticipated this as in scope for the draft when I voted for WG adoption 
– nor do I find it logical to do so (See my Point #1 below). So you now have at 
least one input as regards scope. Please do not ignore it.





Second, in case people on the list still wonder; this draft lives/is necessary 
because of extensive customer input and experience as to desired/undesirable 
operation properties of a solution for flood reduction



[LES:] I have never questioned the usefulness of the proposed algorithm.



1/ distoptflood does not precondition any centralised instance that can due to 
bugs/misconfiguration/network changes affect behavior of lots of nodes, i.e. 
has no blast radius beyond a single node (or more precisely, blast radius that 
an algorithm creates at most as explained in the draft)

2/ distoptflood does not need any configuration (at least for the 
default/example algorithm given)

3/ In distoptflood different algorithms can be introduced/changed/mixed node by 
node rather than generating flag days due to a centralised instance 
configuration

[LES:] Points 1,2,3 are talking about the merits of the new mechanism for 
controlling enablement. This is a discussion worth having – but not in the 
context of a draft whose sole purpose should be the definition of the algorithm 
(i.e., Section 2).

I am happy to comment on your new proposal when/if you properly present it to 
the WG in a separate draft.



4/ Introduced example/default algorithm does not only reduce but also balance 
and is based on a long deployed/understood MANET style work

[LES:] Now you are talking about the merits of the algorithm. On this I agree 
and this is why I have supported this work up to now.

As to “I want this draft and another draft and another split draft” I consider 
it your personal preference and nothing else for the moment. I judge the 
current draft giving a clear example of a example/default algorithm with a 
framework allowing to plug in new algorithms easily far more practical than 
multiple split RFCs that need to be cobbled together to have actually something 
that is operationally significant.

[LES:] Clearly, the control mechanism (whether that defined in dynamic-flooding 
or what you have defined in revised Section 1) is independent of the 
algorithm(s) which may be enabled using the control mechanism. That is 
compelling reason to separate discussion of the two.

   Les



thanks

--- tony

On Tue, Jun 25, 2024 at 9:40 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
In the past, I have supported the WG adoption and progression of this draft, 
which, prior to V4, has confined itself to defining a flooding algorithm 
designed to greatly reduce redundant flooding in highly meshed topologies.

V4 of the draft, in addition to defining the optimized flooding algorithm, has 
introduced a new infrastructure to control what optimized flooding algorithms 
are in use in a given network. This is an alternative to the control mechanism 
defi

[Lsr] Comments on draft-ietf-lsr-distoptflood-04

[Les Ginsberg (ginsberg)]

In the past, I have supported the WG adoption and progression of this draft, 
which, prior to V4, has confined itself to defining a flooding algorithm 
designed to greatly reduce redundant flooding in highly meshed topologies.

V4 of the draft, in addition to defining the optimized flooding algorithm, has 
introduced a new infrastructure to control what optimized flooding algorithms 
are in use in a given network. This is an alternative to the control mechanism 
defined in https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

While discussion of an alternative to the control mechanism defined by the 
dynamic-flooding draft is certainly a topic appropriate for the LSR WG to 
consider, coupling this with the definition of a specific algorithm is highly 
inappropriate for multiple reasons.

1)Any control mechanism, whether that defined in the dynamic flooding draft or 
an alternative proposal, is logically independent from the algorithms which 
might be deployed using the control mechanism.
Indeed, even disptflood-04 allows that the algorithm defined in the draft could 
be enabled using the control mechanism defined by the dynamic-flooding draft.
It therefore is inappropriate for the control mechanism and a specific 
algorithm to be coupled into a single draft.
(NOTE that the dynamic-flooding draft confined itself to only defining the 
control mechanism.)

2)Adoption of the distoptflood draft was approved by the WG based on the scope 
of the work being definition of an optimized flooding algorithm.
The WG never approved adoption of the definition an alternative optimized 
flooding control mechanism.
Introducing definition of a new control mechanism into the existing draft 
expands the scope of the draft well beyond that which was approved by the WG 
adoption.
As I stated above, discussion of an alternative control mechanism for enabling 
optimized flooding algorithms is an appropriate topic for the WG to consider, 
but the authors of distoptflood have usurped the WG process by introducing this 
major change in scope without providing the WG an opportunity to consider the 
additional work.

I call upon the authors of draft-ietf-lsr-distoptflood-04 to restore the 
original scope of the draft to defining the optimized flooding algorithm by 
removing discussion of the alternative control mechanism.

If the authors wish to propose an alternative control mechanism for deploying 
optimized flooding algorithms, I encourage them to do so by writing a new draft 
whose scope is confined to the definition of the new control mechanism.

Thanx.

   Les


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

[Lsr] Re: WGLC for draft-ietf-lsr-labv-registration

[Les Ginsberg (ginsberg)]

I support progressing the document.
The change of codepoint registration is necessary to allow all RFC document 
tracks to get codepoints when necessary.

This is a non-controversial change which should be done without delay.

Les


From: Yingzhen Qu 
Sent: Wednesday, May 22, 2024 8:59 AM
To: lsr ; lsr-chairs 
Subject: [Lsr] WGLC for draft-ietf-lsr-labv-registration


Hi,



This email begins a 2 week WG Last Call for the following draft: 
draft-ietf-lsr-labv-registration-00 - Revision to Registration Procedures for 
IS-IS Neighbor Link-Attribute Bit 
Values



Please review the document and indicate your support or objections by June 6th, 
2024. This is the last chance to send your comments before the draft is sent to 
the IESG for publication.



Thanks,

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

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

[Les Ginsberg (ginsberg)]

Acee -

As regards my comments, Shraddha is correct.
I explicitly stated this back on April 26:


Acee –

I left it up to Shraddha to introduce the I-bit or not – she has chosen not to 
do so.
I believe all of my comments have been addressed to my satisfaction – sorry if 
it appeared that I left this issue unresolved.

   Les


   Les

> -Original Message-
> From: Shraddha Hegde
> Sent: Thursday, May 16, 2024 1:55 AM
> To: Acee Lindem
> Cc: Shraddha Hegde ; Ketan Talaulikar ; lsr ; draft-ietf-lsr-flex-algo-bw-
> c...@ietf.org; Les Ginsberg (ginsberg)
> Subject: RE: [Lsr] Working Group Last Call for "Flexible Algorithms: 
> Bandwidth,
> Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07
> 
> Acee,
> 
> I believe Les and I have agreed to the text that I added and his comments are
> closed.
> Les, let me know if you don't agree.
> 
> I don't agree with Ketan's comment on removing code points from OSPF TE
> opaque LSAs.
> Early code points are already taken and implementations underway. If he can
> elaborate his concern
> With having generic metric in opaque LSA
> We can see what details need to be added in the draft.
> 
> I got some more comments from Peter. Will publish -12 soon.
> 
> 
> Rgds
> Shraddha
> 
> 
> 
> 
> Juniper Business Use Only
> -Original Message-
> From: Acee Lindem 
> Sent: Friday, May 10, 2024 12:29 AM
> To: Acee Lindem 
> Cc: Shraddha Hegde ; Ketan
> Talaulikar ; lsr ; 
> draft-ietf-lsr-flex-algo-
> bw-...@ietf.org; Les Ginsberg (ginsberg) 
> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: 
> Bandwidth,
> Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07
> 
> [External Email. Be cautious of content]
> 
> 
> Any update?
> 
> Thanks,
> Acee
> 
> > On Apr 26, 2024, at 11:53 AM, Acee Lindem 
> wrote:
> >
> > Hi Ketan, Shraddha and Les,
> >
> >
> > I’m trying to conclude this thread and send this document to the AD. I’ve
> read the Emails but I must admit I don’t understand all the arguments.
> >
> >
> > Ketan - if we have the generic-metric in IS-IS, why wouldn’t define it in 
> > OSPF
> as well? If you cannot provide a compelling argument, I ‘m going to request
> publication of the document send it to the actual LSR AD.
> >
> > Shraddha - I see that you included similar text in section 4.3.1 to address
> Les’s comment. I guess the example referring to Flex algo 128/129 is not
> needed.
> >
> > Les - I’m sure what the I-bit but I don’t see that adding it at this 
> > juncture is a
> good idea unless the described protocol enhancements don’t work without it.
> >
> > Thanks,
> > Acee
> >
> >
> >
> >> On Apr 15, 2024, at 02:46, Shraddha Hegde
>  wrote:
> >>
> >> Hi Ketan,
> >>  Thanks for reply.
> >> Pls see inline..
> >>
> >> Juniper Business Use Only
> >> From: Ketan Talaulikar 
> >> Sent: Monday, April 8, 2024 2:25 PM
> >> To: Shraddha Hegde 
> >> Cc: Acee Lindem ; lsr ;
> >> draft-ietf-lsr-flex-algo-bw-...@ietf.org
> >> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms:
> >> Bandwidth, Delay, Metrics and Constraints" -
> >> draft-ietf-lsr-flex-algo-bw-con-07
> >>  [External Email. Be cautious of content]  Hi Shraddha,  Thanks for
> >> your responses. Please check inline below for clarifications with KT.
> >>   On Thu, Apr 4, 2024 at 9:49 AM Shraddha Hegde
>  wrote:
> >> Hi Ketan,
> >>  Thanks for the review and comments.
> >> Pls see inline for replies.
> >>   Juniper Business Use Only
> >> From: Ketan Talaulikar 
> >> Sent: Thursday, March 21, 2024 10:07 PM
> >> To: Acee Lindem 
> >> Cc: lsr ; draft-ietf-lsr-flex-algo-bw-...@ietf.org
> >> Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms:
> >> Bandwidth, Delay, Metrics and Constraints" -
> >> draft-ietf-lsr-flex-algo-bw-con-07
> >>  [External Email. Be cautious of content]  Hi All,  I have reviewed
> >> this document and believe it needs some further work before publication.
> >>  I am sharing my comments below:
> >>  1) There is the following text in sec 2.1 and 2.2 for Generic Metric.
> >>  A metric value of 0xFF is considered as maximum link metric and a link
> having this metric value MUST NOT be used during Flex-algorithm calculations
> [RFC9350]. The link with maximum generic metric value is not available for the
> use of Flexible Algorithms but is 

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

[Les Ginsberg (ginsberg)]

John –

Bruno wrote the new text – so best if we wait for him to respond. Looks like he 
will be back next week.

But my understanding is that your interpretation is correct. If Bruno agrees, 
then we can spin a new version with better wording.

Thanx for your feedback and patience.

   Les


From: John Scudder 
Sent: Thursday, May 9, 2024 10:38 AM
To: Acee Lindem 
Cc: The IESG ; draft-ietf-lsr-isis-fast-flood...@ietf.org; 
lsr-chairs ; lsr ; Zaheduzzaman Sarker 

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

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 
mailto:acee.i...@gmail.com>> 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 
mailto:nore...@ietf.org>> 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] WG Adotpion call - draft-li-lsr-labv-registration (5/2/2024-5/16/2024)

[Les Ginsberg (ginsberg)]

I support WG adoption.
The change will allow all classes of IETF documents to obtain codepoints from 
IS-IS related registries and will make the registration mechanism consistent 
for all IS-IS related registries – both of which are desirable changes.

Les


From: Lsr  On Behalf Of Yingzhen Qu
Sent: Thursday, May 2, 2024 7:35 AM
To: lsr ; lsr-chairs 
Subject: [Lsr] WG Adotpion call - draft-li-lsr-labv-registration 
(5/2/2024-5/16/2024)


Hi,



This email begins a 2 week WG adoption poll for the following draft: 
https://datatracker.ietf.org/doc/draft-li-lsr-labv-registration/



Please review the document and indicate your support or objections by

May 16th, 2024.



Although there is no IPR expected related to this draft. For the process 
purpose, authors and contributors, please respond to the list indicating

whether you are aware of any IPR that applies to the draft.



Thanks,

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

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

[Les Ginsberg (ginsberg)]

Acee –

I left it up to Shraddha to introduce the I-bit or not – she has chosen not to 
do so.
I believe all of my comments have been addressed to my satisfaction – sorry if 
it appeared that I left this issue unresolved.

   Les

From: Acee Lindem 
Sent: Friday, April 26, 2024 8:53 AM
To: Shraddha Hegde 
Cc: Ketan Talaulikar ; lsr ; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org; Les Ginsberg (ginsberg) 

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

Hi Ketan, Shraddha and Les,


I’m trying to conclude this thread and send this document to the AD. I’ve read 
the Emails but I must admit I don’t understand all the arguments.


Ketan - if we have the generic-metric in IS-IS, why wouldn’t define it in OSPF 
as well? If you cannot provide a compelling argument, I ‘m going to request 
publication of the document send it to the actual LSR AD.

Shraddha - I see that you included similar text in section 4.3.1 to address 
Les’s comment. I guess the example referring to Flex algo 128/129 is not needed.

Les - I’m sure what the I-bit but I don’t see that adding it at this juncture 
is a good idea unless the described protocol enhancements don’t work without it.

Thanks,
Acee




On Apr 15, 2024, at 02:46, Shraddha Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>
 wrote:

Hi Ketan,

Thanks for reply.
Pls see inline..



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

[External Email. Be cautious of content]

Hi Shraddha,

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


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

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



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

[External Email. Be cautious of content]

Hi All,

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

I am sharing my comments below:

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

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

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

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

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

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


2) This comment is specific to OSPF given the encoding differences it has with 
ISIS. Section 2.2 allows for Generic Metric TLV to be used in too many places 
without clear specification of what it is

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-labv-registration-01.txt

[Les Ginsberg (ginsberg)]

LGTM

  Les (Probably slightly slower than Tony’s response 😊)

From: Lsr  On Behalf Of Tony Li
Sent: Tuesday, April 23, 2024 4:26 PM
To: lsr 
Subject: [Lsr] Fwd: New Version Notification for 
draft-li-lsr-labv-registration-01.txt


Per Les’ requeest.

Elapsed time: 3 mins.

T



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-li-lsr-labv-registration-01.txt
Date: April 23, 2024 at 4:24:44 PM PDT
To: "Tony Li" mailto:tony...@tony.li>>

A new version of Internet-Draft draft-li-lsr-labv-registration-01.txt has been
successfully submitted by Tony Li and posted to the
IETF repository.

Name: draft-li-lsr-labv-registration
Revision: 01
Title:Revision to Registration Procedures for IS-IS Neighbor Link-Attribute 
Bit Values
Date: 2024-04-23
Group:Individual Submission
Pages:2
URL:  https://www.ietf.org/archive/id/draft-li-lsr-labv-registration-01.txt
Status:   https://datatracker.ietf.org/doc/draft-li-lsr-labv-registration/
HTMLized: https://datatracker.ietf.org/doc/html/draft-li-lsr-labv-registration
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-li-lsr-labv-registration-01

Abstract:

  RFC 5029, "Definition of an IS-IS Link Attribute Sub-TLV", defines a
  registry for "IS-IS Neighbor Link-Attribute Bit Values".  This
  document changes the registration procedure for that registry from
  "Standards Action" to "Expert Review".



The IETF Secretariat


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

Re: [Lsr] New Version Notification for draft-li-lsr-labv-registration-00.txt

[Les Ginsberg (ginsberg)]

I support the proposed change as modified by Chris's comment that the target 
should be to use Expert Review.
In this way all IS-IS codepoint registries would be handled in a consistent 
manner and all would allow any class of RFC - including Experimental - to 
obtain a code point when appropriate.

In addition, I would like to put out a challenge to our wonderful team of WG 
chairs, AD, and even the IESG review process: Let's see if we can get this 
whole process done in three months:

1 month to adopt
1 month to last call
1 month to complete IESG review

This is a non-controversial administrative change - I see no reason why this 
process need take longer than that.

Tony - friendly suggestion to trigger momentum - update the draft based on 
Chris's suggestion and ask for WG adoption.

   Les



> -Original Message-
> From: Lsr  On Behalf Of Tony Li
> Sent: Saturday, April 20, 2024 8:54 AM
> To: Christian Hopps 
> Cc: lsr 
> Subject: Re: [Lsr] New Version Notification for 
> draft-li-lsr-labv-registration-
> 00.txt
> 
> 
> Fair point.  I can live with that.
> 
> T
> 
> 
> > On Apr 20, 2024, at 12:20 AM, Christian Hopps 
> wrote:
> >
> > [as wg-member]
> >
> > Any reason not to use Expert Review? FWIW, this is the only registry for 
> > IS-IS
> that doesn't.
> >
> > Thanks,
> > Chris.
> >
> > Tony Li  writes:
> >
> >> Hi folks,
> >>
> >> This is a proposal to change the registration procedure on the IS-IS
> >> Neighbor Link-Attribute Bit Values registry.
> >>
> >> It’s currently “Standards Action”.  I’m proposing that we change it
> >> to “IETF Review”.
> >>
> >> Thanks,
> >> T
> >>
> >>
> >>
> >>Begin forwarded message:
> >>
> >>From: internet-dra...@ietf.org
> >>Subject: New Version Notification for
> >>draft-li-lsr-labv-registration-00.txt
> >>Date: April 19, 2024 at 10:39:21 AM PDT
> >>To: "Tony Li" 
> >>
> >>A new version of Internet-Draft
> >>draft-li-lsr-labv-registration-00.txt has been
> >>successfully submitted by Tony Li and posted to the
> >>IETF repository.
> >>
> >>Name: draft-li-lsr-labv-registration
> >>Revision: 00
> >>Title:Revision to Registration Procedures for IS-IS Neighbor
> >>Link-Attribute Bit Values
> >>Date: 2024-04-18
> >>Group:Individual Submission
> >>Pages:2
> >>URL:  https://www.ietf.org/archive/id/
> >>draft-li-lsr-labv-registration-00.txt
> >>Status:   https://datatracker.ietf.org/doc/
> >>draft-li-lsr-labv-registration/
> >>HTMLized: https://datatracker.ietf.org/doc/html/
> >>draft-li-lsr-labv-registration
> >>
> >>
> >>Abstract:
> >>
> >>  RFC 5029, "Definition of an IS-IS Link Attribute Sub-TLV",
> >>defines a
> >>  registry for "IS-IS Neighbor Link-Attribute Bit Values".  This
> >>  document changes the registration procedure for that registry
> >>from
> >>  "Standards Action" to "IETF Review".
> >>
> >>
> >>
> >>The IETF Secretariat
> >>
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> Lsr mailing list
> >> Lsr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/lsr
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
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)

[Les Ginsberg (ginsberg)]

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 
Sent: Thursday, April 11, 2024 11:53 AM
To: Zaheduzzaman Sarker ; lsr-cha...@ietf.org; 
John Scudder - Juniper (j...@juniper.net) 
Cc: Zaheduzzaman Sarker ; 
draft-ietf-lsr-isis-fast-flood...@ietf.org; lsr@ietf.org; acee.i...@gmail.com; 
acee-i...@gmail.com; The IESG 
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 Sarker via Datatracker 
> mailto:nore...@ietf.org>>
> Sent: Thursday, April 4, 2024 12:17 PM
> To: The IESG mailto:i...@ietf.org>>
> Cc: 
> draft-ietf-lsr-isis-fast-flood...@ietf.org;
>  lsr-cha...@ietf.org; 
> lsr@ietf.org; 
> acee.i...@gmail.com; 
> acee-i...@gmail.com
> Subject: Zaheduzzaman Sarker's Discuss on 
> draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)
>
> --
> CAUTION : This email originated outside the company. Do not click on any 
> links or open attachments unless you are expecting them from the sender.
>
> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez 
> pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre 
> l'expéditeur.
> --
>
> 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://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-isis-fast-flooding/
>
>
>
> --
> 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 conge

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

[Les Ginsberg (ginsberg)]

Zahed –

Just a heads up – both Bruno and I will be away next week (for unrelated 
reasons 😊)  – so there will be some delay in responses and likely an updated 
version won’t be available until after we return.
Thanx for your patience.

Some responses inline. Look for LES2:

From: Zaheduzzaman Sarker 
Sent: Thursday, April 11, 2024 2:00 AM
To: Les Ginsberg (ginsberg) 
Cc: John Scudder ; 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)

Apologies for late response, I was on PTO.
See reflections below.
//Zahed

On Tue, Apr 9, 2024 at 6:05 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> 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 mailto:j...@juniper.net>>
> Sent: Tuesday, April 9, 2024 8:28 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>
> 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
> mailto:zahed.sarker.i...@gmail.com>> 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.
My point is if this is completely advisory and not comprehensively described, 
then lets not use normative text. Changing from MUST to SHOULD is already an 
improvement, and as none of you feels strongly about s/SHOULD/should then let 
do that.

[LES2:] Sure – we will make that change.

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

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

[Les Ginsberg (ginsberg)]

Shraddha -

Thanx for the response.
Please see inline.

> -Original Message-
> From: Shraddha Hegde
> Sent: Friday, April 12, 2024 8:02 AM
> To: Les Ginsberg (ginsberg) ; Acee Lindem ; lsr
> Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org
> Subject: RE: [Lsr] Working Group Last Call for "Flexible Algorithms: 
> Bandwidth,
> Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07
> 
> Hi Les,
> 
> Thanks for bringing-up this point.
> I agree some clarification is required for the case when G bit is set.
> 
> In case of automatic metric calculation, there may be some links that are
> outliers and an operator
> may want to statically configure the bandwidth metric for such links. This is
> the reason, if bandwidth metric
> is advertised that MUST be used.
> 
> I think providing an I bit at the FAD level would mean network wide and the
> flexibility of overriding
> On a per-link basis won't be possible.
> 
[LES:] True - but this option is at the control of the operator. They can 
choose to set the I-bit or not.

> "In case of Interface Group Mode, if all the parallel links have been 
> advertised
> with the Bandwidth Metric, The individual link Bandwidth Metric MUST be
> used. If only some links among the parallel links have the Bandwidth Metric
> advertisement, the Bandwidth Metric for such links MUST be ignored and
> automatic
> Metric calculation MUST be used to derive link metric"
>
[LES:] This sounds good to me - but I point out this is the equivalent of 
always having the I-bit set - the only exception being when all links have link 
bandwidth advertised.

 
> For the case you described where for different flex-algorithms are using some
> of the parallel links an operator can use below options.
> > Option 1:
> For flex-algo 128, which uses configured bandwidth metric, use user
> defined metric type 128 and flex-algo 128 to use metric-type 128.
>   For Flex-algo 129 use automatic bandwidth metric with G bit set.
>   > Option 2:
> For flex-algo 128 use configured  bandwidth metric
>   For flex-algo 129 use automatic bandwidth metric.
> 
[LES:] I do not like Option #1. I think user defined metric is intended to 
allow the user to set metric values based on their own heuristics - not to 
address this use case.
Option #2 seems consistent with the new text you proposed above - so this seems 
appropriate to me.

In summary, I think the only open issue is whether to introduce the I-bit or 
not. Doing so would provide some additional flexibility - but given the other 
changes you propose I won’t insist.

   Les

> Let me know what you think.
> 
> 
> Rgds
> Shraddha
> 
> Juniper Business Use Only
> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, April 9, 2024 1:08 AM
> To: Acee Lindem ; lsr 
> Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org
> Subject: RE: [Lsr] Working Group Last Call for "Flexible Algorithms: 
> Bandwidth,
> Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07
> 
> [External Email. Be cautious of content]
> 
> 
> Draft authors -
> 
> Regarding Section 5, which defines the rules for deriving Bandwidth metric,
> Rule #1 states:
> 
> "If the Generic Metric sub-TLV with Bandwidth metric type is advertised for 
> the
> link as described in Section 4, it MUST be used during the Flex-Algorithm
> calculation."
> 
> I think this constraint does not fit all possible use cases.
> 
> (Note: For brevity, I am inventing the acronym GMBM to represent "Generic
> Metric sub-TLV with Bandwidth metric type".)
> 
> Consider two nodes A, B that are connected by two parallel links - call them
> AB-1 and AB-2.
> 
> Suppose a customer deploys Flex-Algo 128, which specifies use of Bandwidth
> Metric, but also uses affinity to exclude link AB-2. Customer configures
> advertisement of GMBM for link AB-1 - all is working as expected.
> 
> Now customer deploys Flex-Algo 129, also specifying use of bandwidth
> metric, but wants both links (AB-1, AB-2) to be used and wants automatic
> bandwidth metric calculation to be used so metric automatically adapts to the
> number of links which are up between A-B. Since there is advertisement of
> GMBM for link AB-1, automatic bandwidth calculation cannot include Link AB-
> 1 - which means the customer does not have a way to get what is desired
> without:
> 
> o Removing the advertisement of GMBM for AB-1 o Adding automatic
> bandwidth to the FAD for Flex-Algo 128
> 
> This might be quite surprising to a customer - especially if Flex-Algo 128 has
> been deployed for some time and has been working well.
> 
> There are prob

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

[Les Ginsberg (ginsberg)]

John -

Work on the version update has started - please give us time to edit/review 
among the co-authors.

If Zahed can give us an indication on SHOULD/should that would be helpful - but 
otherwise we will use our best judgment.
FYI I am inclined to use "SHOULD" - but if Zahed feels strongly we can change 
that.

   Les

> -Original Message-
> From: John Scudder 
> Sent: Tuesday, April 9, 2024 10:31 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Zaheduzzaman Sarker ; 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 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

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

[Les Ginsberg (ginsberg)]

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.
The history of this document is that originally there were two competing 
drafts. Some folks thought that algorithm 1 was the best way forward and some 
that approach #2 was the best way forward.
We eventually decided to write a single draft describing both solutions and 
allow the user community to decide what they wanted to use.
My expectation is that we will see implementations of both - and whether one 
approach or the other dominates deployments will be based on deployment 
experience and vendor/operator preference.
But it is certainly incorrect to think of approach #2 as only applicable when 
algorithm #1 is not feasible - that is not the intent of the draft.

HTH clarify.

   Les


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

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

[Les Ginsberg (ginsberg)]

Draft authors -

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

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

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

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

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

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

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

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

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

There are probably multiple ways this limitation could be overcome.

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

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

Les

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

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

[Les Ginsberg (ginsberg)]

John –

Yes – there are some complementary editorial changes that would need to be 
made. But in the interest of brevity, I just provided the single section 
changes as that is the content on which we want to get Zahed’s feedback.

   Les


From: John Scudder 
Sent: Friday, April 5, 2024 2:44 PM
To: Les Ginsberg (ginsberg) 
Cc: Zaheduzzaman Sarker ; 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)

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 
mailto:j...@juniper.net>> 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) 
mailto:ginsb...@cisco.com>> 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 wou

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

[Les Ginsberg (ginsberg)]

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 
Sent: Friday, April 5, 2024 9:37 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; 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
<<< text/html; name="fast-flooding_approach.diff.html": Unrecognized >>>
___
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)

[Les Ginsberg (ginsberg)]

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$
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 conditio

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Les Ginsberg (ginsberg)]

Jie –

Just a short summary from my POV.

Multiple people have provided input to you as to why what you are trying to do 
won’t work.
I won’t repeat what has been said before.

I know you really want your solution to work – but it does not.
If you think otherwise, I think it is only because you have not yet 
implemented/tested it – or you have not tested the problematic scenarios – I 
provided you with one easy example.

This draft should not go forward – and I say that regardless as to whether you 
are headed towards Standards track or Informational. The solution you are 
advocating does not work.

Thanx for the good discussion.

   Les


From: Dongjie (Jimmy) 
Sent: Thursday, March 21, 2024 6:32 PM
To: Peter Psenak (ppsenak) ; Dongjie (Jimmy) 
; Les Ginsberg (ginsberg) 
; lsr@ietf.org; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: RE: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Peter,

Please see inline:

From: Peter Psenak mailto:ppse...@cisco.com>>
Sent: Thursday, March 21, 2024 7:39 PM
To: Dongjie (Jimmy) 
mailto:jie.dong=40huawei@dmarc.ietf.org>>;
 Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally calculated 
based on bandwidth. While Flex-Algo can support metric types such as TE metric 
and delay.

When Flex-Algo is used as the control plane of NRP, usually the metric types 
other than IGP metric would be used. We could add some notes about the 
selection of metric type to this document. In most cases per Flex-Algo metric 
type would not be needed.

Your proposal of making each member link an L3 link is an alternative solution, 
while that would bring back the problems we discussed during the L2 bundle 
standardization, and can impact the network stability and scalability.

Your second proposal (controller based path computation and construction) works 
for scenarios where strict TE-path SID-list is used to steer traffic into 
specific bundle member links on each hop, while traffic with Flex-Algo prefix 
SIDs will be mixed up and ECMP among the member links of the L3 interface.

So we do see there is a gap in using Flex-Algo to support NRP, and would like 
to hear feedbacks from the WG on possible solutions (including this one).

there is no gap in Flex-algo. Flex-algo is a routing concept and as such only 
works on L3 constructs. That will not change.

[Jie] Yes Flex-Algo is a routing concept and works on L3 topology, that is not 
changed. The gap is in using Flex-Algo for NRP in some scenarios.



The problem is that you are trying to mix the routing (flex-algo) with the 
PHB/QOS. These are two different things.

You can achieve PHP/QOS by marking the packet and give it a necessary treatment 
you need at each hop, e.g. reserve certain bandwidth to it, or even reserve a 
L2 bundle for it if that's what you want.

[Jie] The concept of NRP is different from QoS, and QoS can be used within an 
NRP.  With SR based NRPs, SR SIDs are used to steer traffic to a subset of 
resources allocated to an NRP, thus Flex-Algo specific SR SID also needs to be 
able to steer traffic to the subset of resources of the associated NRP.



Alternatively, you can classify the traffic at each hop using other mechanisms, 
but it becomes slow and problematic.

[Jie] Yes people probably do not want to do per-hop classification for NRPs.



What you propose is to overwrite the routing decision and instead of using the 
L3 outgoing interface computed based on L3 information, you install the 
specific L2 bundle member out of such L3 interface in forwatding. It works, 
because by using the L2 member of the L3 interface the traffic is forwarded to 
the same next-hop as has been calculated by the L3 routing. Nobody can stop you 
doing that locally if you wish doing so. But there is absolutely nothing you 
need from the IETF to do this. There is no need to advertise anything to do 
what you describe, as this is all a local behavior of the node. There is no 
need to add a new E-bit, and there is not even a need to advertise affinities 
for the L2 bundle members.

[Jie] To me there is not change to the routing decision in L3. The member link 
is still part of the L3 outgoing interface. And the advertisement of the bundle 
member link information is to allow the controller or the ingress node to do TE 
path computation take the individual member links into consideration, this 
aligns with the usage of the L2 bundle as defined in their RFCs.

Best regards,

Jie



I see no need for this draft.

thanks,
Peter





Best regards,
Jie

From: Les Ginsberg (ginsberg) <mai

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Les Ginsberg (ginsberg)]

Robert –

For the most part, I think it is most appropriate if the authors of the draft 
respond to questions – and I think Ketan has been doing his best to do so.

Since you have specifically targeted your questions to me, I will respond with 
a few points.

I fail to understand why you and others on this thread seem to require a 
definition for “anycast”. It is as if you don’t understand what the term means 
– which is quite surprising since you have many years in the networking field. 
This draft (nor other IGP drafts which have defined the equivalent 
functionality) is not inventing a new definition of “anycast”. The draft is 
just defining a way to mark a given prefix advertisement as being an anycast 
address.

Marking an address is an indication of the operator’s intent i.e., it is saying 
that it is possible that this address will be associated with multiple nodes.
It is true that such an intent can also be derived by examining the LSDB and 
seeing if multiple nodes are originating the same advertisement, but that logic 
does not detect the case where an address is intended to be anycast, but at a 
given moment only one node is originating the advertisement – possibly because 
the operator has not yet brought up other nodes yet – or some nodes are 
temporarily down – or configuration of the network is in progress.

As to use case, one example (which I think Ketan has already mentioned) is when 
calculating repair paths. You would not want to use an anycast address for a 
node on the repair path because forwarding of packets to that address could be 
sent towards multiple nodes.

   Les


From: Robert Raszuk 
Sent: Friday, March 22, 2024 7:33 AM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem ; lsr ; 
draft-chen-lsr-anycast-f...@ietf.org
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property 
advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Les,

> Knowledge of whether a given prefix is Anycast has proven useful in existing 
> deployments

Would you be so kind and enlighten us with a few practical examples in which 
you exhibit practical usefulness of this flag at the IGP level?

More basic question - is this set by CLI or is there a special protocol 
algorithm which set such flag ? If it is the latter, can you explain it ?

So if suddenly one src of such anycast goes down rest of the area still thinks 
it is anycast ?

From the BGP side of things indeed for basic IPv4/IPv6 concept of ghost 
loopbacks were used as next hops which indeed were advertised as anycast 
addresses. Is that one example in which you would hope that BGP prefers a path 
if the next hop is an anycast address as told by IGP ? And you push that 
"automation" to operators to prefer such paths by manual configuration ?

And to second Bruno's question - what is IGP's definition of an anycast address 
?

Many thx,
Robert


On Thu, Mar 21, 2024 at 7:47 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
I support adoption of this draft.
Knowledge of whether a given prefix is Anycast has proven useful in existing 
deployments - closing this gap for OSPFv2 is a good thing to do.

One editorial comment. The introduction (and abstract) states:

" Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast
   and as such the same value can be advertised by multiple routers."

But there is no further discussion of prefix-SID in the draft.
I think mention of the prefix-SID should be removed.

Les


> -Original Message-
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Acee Lindem
> Sent: Tuesday, March 19, 2024 11:43 AM
> To: lsr mailto:lsr@ietf.org>>
> Cc: 
> draft-chen-lsr-anycast-f...@ietf.org<mailto:draft-chen-lsr-anycast-f...@ietf.org>
> Subject: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property
> advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>
>
> This starts the Working Group adoption call for draft-chen-lsr-anycast-flag.
> This is a simple OSPFv2 maintenance draft adding an Anycast flag for IPv4
> prefixes to align with IS-IS and OSPFv3.
>
> Please send your support or objection to this list before April 6th, 2024.
>
> Thanks,
> Acee
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org<mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Les Ginsberg (ginsberg)]

I support adoption of this draft.
Knowledge of whether a given prefix is Anycast has proven useful in existing 
deployments - closing this gap for OSPFv2 is a good thing to do.

One editorial comment. The introduction (and abstract) states:

" Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast
   and as such the same value can be advertised by multiple routers."

But there is no further discussion of prefix-SID in the draft.
I think mention of the prefix-SID should be removed.

Les


> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Tuesday, March 19, 2024 11:43 AM
> To: lsr 
> Cc: draft-chen-lsr-anycast-f...@ietf.org
> Subject: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property
> advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
> 
> 
> This starts the Working Group adoption call for draft-chen-lsr-anycast-flag.
> This is a simple OSPFv2 maintenance draft adding an Anycast flag for IPv4
> prefixes to align with IS-IS and OSPFv3.
> 
> Please send your support or objection to this list before April 6th, 2024.
> 
> Thanks,
> Acee
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Les Ginsberg (ginsberg)]

Jie –

Inline.

From: Dongjie (Jimmy) 
Sent: Wednesday, March 20, 2024 6:35 PM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally calculated 
based on bandwidth. While Flex-Algo can support metric types such as TE metric 
and delay.

When Flex-Algo is used as the control plane of NRP, usually the metric types 
other than IGP metric would be used. We could add some notes about the 
selection of metric type to this document. In most cases per Flex-Algo metric 
type would not be needed.
[LES:] As I have stated, the number of metric-types is much less than the 
possible number of algorithms. Please do not define a solution which requires a 
different metric-type for each supported algorithm.

Your proposal of making each member link an L3 link is an alternative solution, 
while that would bring back the problems we discussed during the L2 bundle 
standardization, and can impact the network stability and scalability.
[LES:] Addressing scale by hiding the topology from the entity which is 
required to do the correct NRP mapping (which is what you are doing in this 
draft) is not a good solution.
You need a solution which both scales and is still correct – not a compromise 
between the two.

Your second proposal (controller based path computation and construction) works 
for scenarios where strict TE-path SID-list is used to steer traffic into 
specific bundle member links on each hop, while traffic with Flex-Algo prefix 
SIDs will be mixed up and ECMP among the member links of the L3 interface.

So we do see there is a gap in using Flex-Algo to support NRP, and would like 
to hear feedbacks from the WG on possible solutions (including this one).

[LES:] As I am sure you remember, we (including others) have discussed this 
offline and you know that I believe the routing protocols are NOT a good fit 
for what has historically been addressed using QOS mechanisms.
And TEAS drafts on which you are co-author make statements which discourage the 
use of routing protocols. For example see 
https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-04.html#name-scalability-design-principl

“The routing protocols (IGP or BGP) does not have to be involved in any of 
these points, but when they need to, it is important to isolate information of 
network slices and NRPs from existing routing information, so that there is no 
impact on scaling or stability. Furthermore, the complexity of SPF computation 
should not be impacted by the increasing number of network slices and NRPs.”

This suggests that if you were to use routing protocols at all, you do not 
recommend doing so at scale, which means your remark above concerning scale and 
not using L2 bundles seems misplaced. It seems even you are not expecting to 
use routing protocol in support of NRP at scale.

No doubt much more discussion required – both in TEAS and LSR – but I do feel 
strongly that this draft should not go forward.

   Les


Best regards,
Jie

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Thursday, March 21, 2024 10:36 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>
Subject: RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07


Jie -



Thanx for the quick response and confirming that my understanding of the intent 
of the draft is correct.



Making a routing decision when the full topology information is not provided as 
input to the Decision Process leads to incorrect or sub-optimal routing. Here 
is one simple example.

Consider the following simple topology (Layer 3 links):



B

  /   \

A   D

 \   /

C





All layer 3 links participate in Flex Algo 128.

On both B and C, the Layer 3 link to D is an L2 bundle and the total bandwidth 
of the bundle links are the same.

On link B-D, the L2 bundle member assigned to the NRP associated with flex algo 
128 has 100 Mb of bandwidth.

On link C-D, the L2 bundle member assigned to the NRP associated with flex algo 
128 has 1 GB of bandwidth.



The L3 SPF associated with algo 128 utilizes Layer 3 metric advertisements. 
Based on that, traffic from A to D will be equally balanced via B and C.

However, what you intend is that when algo 128 traffic is forwarded by B it 
will utilize a 100 Mb link – whereas when algo 128 traffic is forwarded by C it 
will utilize a 1 Gb link.

Clearly the ECMP traffic flow which is the output of the L3 SPF is sub-optimal.



How could this be fixed?



1)Do not use L2 bundles on B and C. Make each bundle member an L3 link and run 
IS-IS on the Layer 3 interfaces. In such a case different L3 metrics can be 
advertised for each L3 li

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Les Ginsberg (ginsberg)]

Jie -



Thanx for the quick response and confirming that my understanding of the intent 
of the draft is correct.



Making a routing decision when the full topology information is not provided as 
input to the Decision Process leads to incorrect or sub-optimal routing. Here 
is one simple example.

Consider the following simple topology (Layer 3 links):



B

  /   \

A   D

 \   /

C





All layer 3 links participate in Flex Algo 128.

On both B and C, the Layer 3 link to D is an L2 bundle and the total bandwidth 
of the bundle links are the same.

On link B-D, the L2 bundle member assigned to the NRP associated with flex algo 
128 has 100 Mb of bandwidth.

On link C-D, the L2 bundle member assigned to the NRP associated with flex algo 
128 has 1 GB of bandwidth.



The L3 SPF associated with algo 128 utilizes Layer 3 metric advertisements. 
Based on that, traffic from A to D will be equally balanced via B and C.

However, what you intend is that when algo 128 traffic is forwarded by B it 
will utilize a 100 Mb link – whereas when algo 128 traffic is forwarded by C it 
will utilize a 1 Gb link.

Clearly the ECMP traffic flow which is the output of the L3 SPF is sub-optimal.



How could this be fixed?



1)Do not use L2 bundles on B and C. Make each bundle member an L3 link and run 
IS-IS on the Layer 3 interfaces. In such a case different L3 metrics can be 
advertised for each L3 link and Flex Algo 128 can be associated only with the 
desired L3 link on C and D.

Standard flex-algo as defined in RFC 9350 works and requires no modifications.



2)Do not use L3 routing/flex algo. Define some other mechanism to mark packets 
in a way that the forwarding recognizes as mapping to the appropriate L2 link.

The L2 bundle advertisements provided by IS-IS as per RFC 8668 can be used by 
this (external to IS-IS) mechanism.

For example this mechanism could use the admin group advertised for each 
L2Bundle member to determine the mapping between an NRP and a link.

All of the functionality required is already defined in RFC 8668 – the only 
thing you need to define is this new mechanism – which is not part of IS-IS and 
therefore does not belong in an LSR draft.



NOTE: Please do not suggest that a different metric-type can be used for each 
Flex-Algo. Such an approach does not scale as it requires as many metric-types 
as Flex-Algos – which we do not have. 😊



What you MUST NOT do is use L3 routing to make a routing decision for a 
topology which is not part of the input to the routing decision process. But 
that is exactly what you are proposing in this draft.



Hope this example is clear.



As regards the clarity of Section 4, that section simply says (using the 
SR-MPLS text):



“A forwarding entry MUST be installed in the forwarding plane using the MPLS 
label that corresponds to the Prefix-SID associated with the Flex-algorithm 
corresponding to the NRP.”



But this entry must have next hops which include only the L2 links associated 
with the NRP mapped to Flex-algo 128. How this is done is not described – but 
as it requires using information advertised in the L2 Bundle Member Descriptors 
this clearly cannot be done by IS-IS w/o violating RFC 8668. IS-IS will simply 
attempt to install a forwarding entry based on the L3 topology – which will 
indicate to use the L3 link. How this forwarding entry is discarded/overwritten 
is not specified. But, this is a problem which should never need to be solved.



   Les







> -Original Message-

> From: Dongjie (Jimmy) 

> Sent: Wednesday, March 20, 2024 4:30 PM

> To: Les Ginsberg (ginsberg) ; lsr@ietf.org; draft-zhu-lsr-

> isis-sr-vtn-flexalgo.auth...@ietf.org

> Subject: RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

>

> Hi Les,

>

> Thanks for the review and comments.

>

> Please see some replies inline:

>

> > -Original Message-

> > From: Les Ginsberg (ginsberg) 
> > mailto:ginsb...@cisco.com>>

> > Sent: Thursday, March 21, 2024 7:32 AM

> > To: lsr@ietf.org<mailto:lsr@ietf.org>; 
> > draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>

> > Subject: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

> >

> > This draft discusses how to use flex-algo in support of Network Resource

> > Partitions (NRPs). In particular, it proposes to use a combination of L3 
> > links

> and

> > L2 Bundle member links as the topology associated with a given NRP. In

> those

> > cases where an L3 link is using an L2 bundle and individual bundle members

> > are "assigned" to different NRPs, it then proposes to associate the parent 
> > L3

> > link with multiple flex-algos. The intent seems to be to utilize the L3 algo

> > specific SIDs to assign the traffic to subsets of the L2 Bundle 

[Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Les Ginsberg (ginsberg)]

This draft discusses how to use flex-algo in support of Network Resource 
Partitions (NRPs). In particular, it proposes to use a combination of L3 links 
and
L2 Bundle member links as the topology associated with a given NRP. In those 
cases where an L3 link is using an L2 bundle and individual bundle members
are "assigned" to different NRPs, it then proposes to associate the parent L3 
link with multiple flex-algos. The intent seems to be to utilize the L3
algo specific SIDs to assign the traffic to subsets of the L2 Bundle members.

This is extremely problematic.

The output of the L3 algo-specific SPF will be to install nexthops pointing to 
the L3 interface for packets which arrive with
the L3 algo specific SID. But since the intent is to only forward traffic for a 
given algo specific SID via specific L2 Bundle members, the L3
forwarding entries will have to be overwritten - in a manner not specified by 
the draft.

The implementation complexities this introduces arise because the proposed 
solution attempts to use a Layer 3 technology (flex-algo) to control the
use of L2 links. This should not be done.

Indeed, even independent of flex-algo, trying to use a Layer 3 routing protocol 
to control traffic flow on an L2 sub-topology is broken.
It means that the L2 bundles have been improperly defined for use by the L3 
routing protocol.

RFC 8668 defines the advertisements of L2 Bundle member link attributes by 
IS-IS. The introduction of RFC 8668 states:

"...the new advertisements defined in this document are intended to be provided 
to external (to IS-IS) entities."

This means these advertisements are not to be used by the routing protocol
itself. The association of these advertisements with the Layer 3 SIDs
defined by Flex-Algo is a clear violation of the intended use as stated by RFC
8668.

This draft should be abandoned.

NOTE: None of the points above should be interpreted to mean that flex-algo
cannot be used in support of NRPs. (Whether that is a good idea or not
is out of scope for this discussion).

But the proper way to do that is when the NRP maps to an L3 topology. Such
a usage is fully supported by RFC 9350 and there is no need to write an
additional document to define how this is to be done.

In cases where an NRP maps to an L2 topology, some other mechanism needs
to be defined as to how forwarding entries for a given NRP are determined
and installed. Such a mechanism would qualify as "external to IS-IS" and
therefore could make use of RFC 8668 advertisements.

But attempts to utilize the Layer 3 Flex-Algo technology to control traffic
flow in an L2 topology are misguided and flawed.

   Les

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

Re: [Lsr] Intra-domain SAVNET method - draft-lin-savnet-lsr-intra-domain-method-03

[Les Ginsberg (ginsberg)]

+1

The problem can be solved - and in a much more robust way than what is proposed 
in the draft - without any protocol extensions.

There is no reason for this draft.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Monday, March 18, 2024 12:50 PM
> To: draft-lin-savnet-lsr-intra-domain-met...@ietf.org
> Cc: lsr 
> Subject: [Lsr] Intra-domain SAVNET method - draft-lin-savnet-lsr-intra-
> domain-method-03
> 
> Speaking as WG member:
> 
> Co-Authors,
> 
> I see you have a slot at the LSR meeting on Thursday to present the subject
> draft.
> 
> I believe this document is misguided. You shouldn't need to advertise
> protected prefixes. If you are doing Source Address Validation for intra-
> domain sources, why wouldn't you do it for all of them? What do you do for
> the intra-domain prefixes that aren't advertised (blindly forward them or
> summarily discard them)? If you were to only do SAV on certain prefixes, this
> should be a local decision as opposed to something that is advertised by the
> sources.
> 
> Also, you shouldn't need to advertise any reverse metric. At least within an
> area, you have all the reverse costs in link-sate.  Incoming interfaces for
> asymmetric paths can be readily calculated without any IGP advertisement.
> Algorithms to accomplish this are described in
> 
> https://patents.google.com/patent/US11882019B1/en?oq=11882019
> 
> The SAVNET WG shouldn't adopt any document requiring IGP advertisement
> without LSR approval.
> 
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] Secdir last call review of draft-ietf-lsr-isis-fast-flooding-07

[Les Ginsberg (ginsberg)]

Bruno -

Inline.

> -Original Message-
> From: bruno.decra...@orange.com 
> Sent: Friday, March 15, 2024 11:17 AM
> To: Les Ginsberg (ginsberg) ; Barry Leiba
> 
> Cc: draft-ietf-lsr-isis-fast-flooding@ietf.org; last-c...@ietf.org; 
> lsr@ietf.org;
> sec...@ietf.org
> Subject: RE: Secdir last call review of draft-ietf-lsr-isis-fast-flooding-07
> 
> Les, Barry,
> 
> > From: Les Ginsberg (ginsberg) 
> > Sent: Friday, March 15, 2024 4:29 PM
> >
> > Bruno/Barry -
> >
> > In regards to:
> >
> > > > — Section 4.4 —
> > > >
> > >> Length: Indicates the length in octets (1-8) of the Value field.  The
> > >> length SHOULD be the minimum required to send all bits that are set.
> > > >
> > > > The SHOULD seems very odd: what would be a good reason to make it
> > > longer than necessary?  Is there a real reason not to
> > > straightforwardly say, “The length is the minimum required…”?
> > >
> > > [Bruno] To be honest, that's just verbatim copy from
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc8919%23name-application-
> identifier-
> > >
> &data=05%7C02%7Cbruno.decraene%40orange.com%7Ced0ce7f4ef6f4adb
> a5ee08dc
> > >
> 4504b6dc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63846
> 11337566830
> > >
> 44%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI
> > >
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Mxn56QB9LdNA%2
> FBh2bAANCIsky
> > > Xx1zTir%2FIpTtpRsQbM%3D&reserved=0
> > > bit-
> > > At the time, I had assumed that copying an already agreed upon
> > > sentence from an RFC was simplifier and safer. Looks like I was only 50%
> right 😉.
> > > You have a good point. I can't find a legitimate reason.
> > > I used your proposed wording (although my natural inclination would
> > > have used a "MUST")
> > >
> > [LES:] The reason RFC 8919 uses SHOULD - and why this draft should do the
> same - is that sending additional bits unnecessarily is not incorrect - it is 
> simply
> inefficient.
> 
> [Bruno] Agreed that this is only about efficiency. IMO the question is whether
> the sender must be efficient or if there a good reason to allow for 
> inefficiency.
> 
> > If you use "MUST" you are stating that receivers are obligated to reject a
> correct advertisement simply because it is unnecessarily long.
> > This is unwise and counterproductive.
> 
> [Bruno] In theory, there should be a way to Be conservative in what you send
> and liberal in what you receive.
> That would require more text. e.g.
> OLD:  The length SHOULD be the minimum required to send all bits that are
> set.
> NEW: When sent, the length MUST be set to the minimum required to send all
> bits that are set. When received any length below or equal 8 octets MUST be
> accepted.
> 
> Would this work?
[LES:] We have already explicitly stated what the sender SHOULD do - and by 
using "SHOULD" we indicate that the receiver needs to be "liberal" and accept 
the advertisement even if it is longer than necessary.
I do not see what is being accomplished here.

An implementation that is optimal is already following the recommended behavior.
Do you think that by saying "MUST" you will get more implementations to be 
optimal?
I doubt it.

And you now have to use two "MUST" statements:

1)For the transmitter - to be optimal
2)For the receiver - to be liberal

A single SHOULD accomplishes the same thing.

I think this is "much ado about nothing" - or at best "much ado about very 
little".

   Les

> 
> Regards,
> --Bruno
> 
> 
> > As a WG member and co-author I object to this change.
> >
> > HTH
> >
>> Les
> >
> >
> ___
> _
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Secdir last call review of draft-ietf-lsr-isis-fast-flooding-07

[Les Ginsberg (ginsberg)]

Bruno/Barry -

In regards to:

> > — Section 4.4 —
> >
>> Length: Indicates the length in octets (1-8) of the Value field.  The
>> length SHOULD be the minimum required to send all bits that are set.
> >
> > The SHOULD seems very odd: what would be a good reason to make it
> longer than necessary?  Is there a real reason not to straightforwardly say,
> “The length is the minimum required…”?
> 
> [Bruno] To be honest, that's just verbatim copy from
> https://datatracker.ietf.org/doc/html/rfc8919#name-application-identifier-
> bit-
> At the time, I had assumed that copying an already agreed upon sentence
> from an RFC was simplifier and safer. Looks like I was only 50% right 😉.
> You have a good point. I can't find a legitimate reason.
> I used your proposed wording (although my natural inclination would have
> used a "MUST")
> 
[LES:] The reason RFC 8919 uses SHOULD - and why this draft should do the same 
- is that sending additional bits unnecessarily is not incorrect - it is simply 
inefficient.
If you use "MUST" you are stating that receivers are obligated to reject a 
correct advertisement simply because it is unnecessarily long.
This is unwise and counterproductive.
As a WG member and co-author I object to this change.

HTH

   Les

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

Re: [Lsr] WGAdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Les Ginsberg (ginsberg)]

I hesitate to prolong a discussion which is less important than many other 
things before the WG – but I do think there are better choices than sticking 
with a name which is not apt – names are of some importance.

Inline…

From: Liyan Gong 
Sent: Thursday, March 14, 2024 7:14 PM
To: tom petch ; Yingzhen Qu ; 
Christian Hopps 
Cc: Les Ginsberg (ginsberg) ; jie.d...@huawei.com; 
AceeLindem ; Gyan Mishra ; lsr 
; lsr-chairs ; ketan Talaulikar 

Subject: Re:Re: [Lsr] 
WGAdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)


Hi All,



Sincerely appreciate all your remainder and suggestion.

About whether to change the draft name, here are the feedbacks we have received.

1) Do not change

LES: For those who have concerns about confusion caused by a document  name 
change, I have to say I think this is a misplaced concern and pedantic. 
(Apologies Tom…)

If one looks at the content of Datatracker for any draft/RFC, you will see 
there is a very clear history of all versions of the draft under all of the 
names that may have been used along the way – and the Datatracker page is 
easily found by searching under any of the draft names.

2) Change to: ietf-lsr-ospf-max-link-metric-00

3) Change to: ietf-lsr-ospf-ls-link-infinity-00

[LES:] I would be happy with either alternate choice. But the current 
“unreachable” is completely inaccurate in terms of the functionality being 
defined. (Apologies to Acee…)

I personally think that option 1) might be better, not changing, as it helps 
for better tracking of the document's history.

In comparison to the name, the title abbreviation may be more helpful and 
permanent for understanding the document.

Therefore, I would like to update the abbreviation in subsequent versions. 
e.g.,from “Advertising Unreachable Links in OSPF”to “Advertising Infinity Links 
in OSPF”.

[LES:] I suppose something is better than nothing, but I really don’t see the 
justification for halfway measures.

That’s it for me on this topic.

   Les



Please feel free to let us know your thoughts. Any ideas are welcome. Thanks 
again.



Best Regards,

Liyan





邮件原文

发件人：tom petch  mailto:ie...@btconnect.com>>
收件人：Yingzhen Qu  
mailto:yingzhen.i...@gmail.com>>,Christian Hopps  
mailto:cho...@chopps.org>>
抄　送: Liyan Gong  
mailto:gongli...@chinamobile.com>>,"Les Ginsberg 
(ginsbe" 
mailto:ginsb...@cisco.com>>,"jie.d...@huawei.com<mailto:jie.d...@huawei.com>"
 mailto:jie.d...@huawei.com>>,AceeLindem  
mailto:acee.i...@gmail.com>>,Gyan Mishra  
mailto:hayabusa...@gmail.com>>,lsr 
mailto:lsr@ietf.org>>,lsr-chairs  
mailto:lsr-cha...@ietf.org>>,ketan Talaulikar 
mailto:ketant.i...@gmail.com>>
发送时间：2024-03-13 19:38:30
主题：Re: [Lsr] WGAdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 
03/08/24)

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
Sent: 13 March 2024 05:36
Les, thanks for the reminder.

Liyan, you can post the WG version with a file name as Les suggested. Like 
Chris mentioned, X can replace Y. If you run into issues, please let us know.


They will not run into issues.  The rest of the world may at some future date 
when trying to understand what changes were introduced when and why.

I have seen ADs fail to understand that a name change has happened to an I-D 
and so fail to understand how and why a document ended up as it is.

The file name is temporary.  It vanishes when the I-D is published..  Changing 
it just introduces the scope for mistakes.

Don't do it. Ever.

Tom Petch

p.s. I wonder if anyone has ever appealed to the IESG against a decision to 
change th name of an I-D:-)

Thanks,
Yingzhen

On Tue, Mar 12, 2024 at 9:38PM Christian Hopps 
mailto:cho...@chopps.org<mailto:cho...@chopps.org%3cmailto:cho...@chopps.org>>>
 wrote:
I am not aware of any "inherited" requirement. We link documents (X replaces Y) 
in the datatracker by choosing whatever document we want as "replaces". You can 
post the document with whatever name changes you want and the chairs can either 
accept it and it gets posted or not.

Thanks,
Chris.

> On Mar 12, 2024, at 23:26, Liyan Gong 
> mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>>
>  wrote:
>
> Hi Yingzhen,Les and WG,
>
> Thank you. The first version will be updated soon with the name 
> draft-ietf-lsr-ospf-unreachable-link since the first version name needs to be 
> inherited.
> The proposed name will be reflected in later versions. Thank you Les for your 
> good suggestion. It is more apt.
> Any comments are always welcome.
>
> Best Regards,
> Liyan
>
> 邮件原文
> 发件人："Les Ginsberg (ginsberg)" 
> mailto:ginsb...@cisco.com<mailto:ginsb...@cisco.com%3cmailto:ginsb...@cis

Re: [Lsr] WG Adoption Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Les Ginsberg (ginsberg)]

Or – if the authors want to consider my comments – replace “unreachable” in the 
name with something more apt – perhaps:

“lsr-ospf-max-link-metric”

😊

   Les


From: Lsr  On Behalf Of Yingzhen Qu
Sent: Tuesday, March 12, 2024 1:11 PM
To: Liyan Gong 
Cc: jie.d...@huawei.com; Acee Lindem ; Gyan Mishra 
; lsr ; lsr-chairs ; 
ketan Talaulikar 
Subject: Re: [Lsr] WG Adoption 
Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

Hi all,

The adoption call has ended.

There is strong consensus, and all the authors and contributors have replied to 
the IPR call thread, so this draft is now adopted.

Authors, please upload a WG version with name 
draft-ietf-lsr-ospf-unreachable-link when the datatracker is open.

Please continue the discussion to further refine the draft.

Thanks,
Yingzhen

On Mon, Mar 11, 2024 at 7:34 PM Liyan Gong 
mailto:gongli...@chinamobile.com>> wrote:

Hi Jie,



Thank you for your replies. Please see inline with [Liyan].



Best Regards,

Liyan




邮件原文
发件人："Dongjie \\(Jimmy\\)" 
mailto:40huawei@dmarc.ietf.org>>
收件人：Acee Lindem  mailto:acee.i...@gmail.com>>,Liyan Gong  
mailto:gongli...@chinamobile.com>>
抄　送: Gyan Mishra  
mailto:hayabusa...@gmail.com>>,Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>,lsr  
mailto:lsr@ietf.org>>,lsr-chairs 
mailto:lsr-cha...@ietf.org>>,ketan Talaulikar  
mailto:ketant.i...@gmail.com>>
发送时间：2024-03-11 23:11:49
主题：Re: [Lsr] WG Adoption Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 
03/08/24)


Hi Acee and Liyan,

Please see some replies inline with [Jie] :

From: Acee Lindem [mailto:acee.i...@gmail.com]
Sent: Sunday, March 10, 2024 5:37 AM
To: Liyan Gong mailto:gongli...@chinamobile.com>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>;  Dongjie 
(Jimmy) mailto:jie.d...@huawei.com>>;  Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>;  lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>;  ketan Talaulikar 
mailto:ketant.i...@gmail.com>>
Subject: Re: [Lsr] WG Adoption Call 
-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

All,

With respect to the naming of the OSPF constants, I think we should go with:

 LSLinkInfinity- 0x
 MaxReachableLinkMetric - 0xfffe

LSLinkInfinity is analogous to LSInfinity.

[Jie]  This is OK to me.



See inline.



On Mar 2, 2024, at 06:16, Liyan Gong 
mailto:gongli...@chinamobile.com>> wrote:


Hi Gyan and Jie,

I am not entirely sure if the suggestions from Ketan in previous email can 
address these two concerns. If not fully addressed, please feel free to let us 
know.

Overall, this feature is applicable to all FAs, including FA0. The next version 
will further elaborate on the relationships between new features and FAs, as 
well as optimize the use-case descriptions and corresponding name to reflect 
"Unreachable"  in a way that is easier to understand.

Appreciate everyone's discussion. It is very helpful.


[Jie] Thanks, this aligns with my understanding: it applies to all SPF  
computations (including Flexible Algorithms) which make use of IGP metric. And 
it would be good to replace unreachable with some more accurate description.



[Liyan]Thanks.I am also considering this matter and hope to get your advice. 
Would it be better to use "Infinity Link" instead of " Unreachable Link" for 
both the content and the title of the draft?



Best Regards,

Liyan




邮件原文
发件人：Gyan Mishra  mailto:hayabusa...@gmail.com>>
收件人："Dongjie (Jimmy)" 
mailto:jie.dong=40huawei@dmarc.ietf.org>>
抄　送: Yingzhen Qu  mailto:yingzhen.i...@gmail.com>>,lsr 
 mailto:lsr@ietf.org>>,lsr-chairs  
mailto:lsr-cha...@ietf.org>>
发送时间：2024-03-01 11:27:32
主题：Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link(02/23/24 - 
03/08/24)
Hi Jie

Some answers in-line

On Thu, Feb 29, 2024 at 2:31 AM Dongjie (Jimmy) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi Yingzhen,

I’ve read the latest version of this document and support its adoption.  It is 
a useful  feature in general to exclude some of the links from SPF  computation.

I also have some comments for the authors to consider, they can be solved after 
the adoption.


1.   I’m not sure the purpose is to advertise an unreachable link in OSPF, 
from the use cases in the draft, the link is still reachable and  can be used 
for some services,  just it needs be excluded from normal SPF calculation. If 
this is correct, it is better the title of the draft and the name of the new 
capability Flag need to be updated to reflect this.

LSLinkInfinity would always indicate the link is unreachable. However, there is 
no real need to advertise it for other services since in these cases the 
advertisement is optional.

[Jie] IMO once LSLinkInfinity is advertised for a link, it would impact all 
services which  rely on SPF computation based on IGP metric.  Regarding “for 
other services the advertisement is optional”, do you mean other services would 
rely on metric-types other than IGP metric? This is true for s

Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

[Les Ginsberg (ginsberg)]

Acee -

Sorry, for some reason I thought you had copied the RFC5130 text verbatim - but 
I see that is not the case.

Apologies for the noise.

   Les

> -Original Message-
> From: Acee Lindem 
> Sent: Monday, March 4, 2024 12:56 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Tony Przygienda ; lsr 
> Subject: Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-
> ietf-lsr-ospf-admin-tags
> 
> Hi Les,
> 
> > On Mar 4, 2024, at 15:48, Les Ginsberg (ginsberg) 
> wrote:
> >
> > Acee -
> >
> > Consider two ABRs propagating a prefix they received with three tags. One
> ABR supports only one tag and one ABR supports two tags.
> > How do we insure that at least one tag is in common when the prefix is
> propagated?
> >
> > Given that the only MUST here is that all implementations MUST support the
> first tag, it seems prudent to insure that the first tag is always propagated 
> and
> it is always the first.
> > Otherwise, routers will receive two advertisements for the same prefix and
> the first tag may differ.
> >
> > I am not talking here about constraining local policies - it is already a 
> > given
> that if a customer wants to make use of multiple tags there is no assurance
> that all routers will support that.
> > But we have specified that the first tag always remain the first. Mandating
> that on propagation insures that any policy associated with the first tag will
> work network-wide.
> >
> > If you are not convinced, so be it - we have lived with the lax language in 
> > RFC
> 5130 for years. But some things may not be working because of that.
> 
> The draft already says this:
> 
>When propagating
>multiple tags between areas as previously described, the order of the
>the tags SHOULD be preserved so that implementations supporting fewer
>tags will have a consistent view across areas.
> 
> Thanks,
> Acee
> 
> 
> >
> >   Les
> >
> >
> >> -Original Message-
> >> From: Acee Lindem 
> >> Sent: Monday, March 4, 2024 12:12 PM
> >> To: Les Ginsberg (ginsberg) 
> >> Cc: Tony Przygienda ; lsr 
> >> Subject: Re: [Lsr] bunch comments on
> https://datatracker.ietf.org/doc/draft-
> >> ietf-lsr-ospf-admin-tags
> >>
> >> Hi Les,
> >>
> >>> On Mar 3, 2024, at 11:41 PM, Les Ginsberg (ginsberg)
> >>  wrote:
> >>>
> >>> Not overly complicate things...
> >>>
> >>> The requirement to ensure that the first tag remains the first tag when
> tags
> >> are propagated suggests that the following language from RFC 5130 is a bit
> >> lax:
> >>>
> >>> "When propagating TLVs between levels, a compliant IS-IS
> >>>  implementation MAY be able to rewrite or remove one or more tags
> >>>  associated with a prefix..."
> >>>
> >>> I think it is required that the first tag never be rewritten/removed when
> >> propagating.
> >>>
> >>> Acee - maybe you want to tighten up the language in the OSPF draft on
> this
> >> point?
> >>
> >> Why would we want to specify this constraint on local policy? Local IGP
> >> filtering policies are not standardized today and, as you know, many non-
> >> standard IGP policy implementations exist.
> >> Thanks,
> >> Acee
> >>
> >>
> >>
> >>>
> >>>  Les
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Acee Lindem 
> >>>> Sent: Friday, March 1, 2024 10:27 AM
> >>>> To: Tony Przygienda 
> >>>> Cc: Les Ginsberg (ginsberg) ; lsr 
> >>>> Subject: Re: [Lsr] bunch comments on
> >> https://datatracker.ietf.org/doc/draft-
> >>>> ietf-lsr-ospf-admin-tags
> >>>>
> >>>> At the risk of complication, I've added text to clarify the ordering
> >>>> independence (from RFC 5130) and the usage when multiple LSAs
> >> contribute
> >>>> to a path in -14.
> >>>>
> >>>> I also specified the behavior for an invalid length - while I agree with 
> >>>> Les
> this
> >> is
> >>>> a generic problem, it isn't necessary handled generically across IGPs, 
> >>>> TLVs,
> >> and
> >>>> sub-TLVs. I'm used to addressing this class of comment,  Alvaroisms.😎
> >>>>
> >>>> Thanks and have a Great Weekend,
> >>&g

Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

[Les Ginsberg (ginsberg)]

Acee -

Consider two ABRs propagating a prefix they received with three tags. One ABR 
supports only one tag and one ABR supports two tags.
How do we insure that at least one tag is in common when the prefix is 
propagated?

Given that the only MUST here is that all implementations MUST support the 
first tag, it seems prudent to insure that the first tag is always propagated 
and it is always the first.
Otherwise, routers will receive two advertisements for the same prefix and the 
first tag may differ.

I am not talking here about constraining local policies - it is already a given 
that if a customer wants to make use of multiple tags there is no assurance 
that all routers will support that.
But we have specified that the first tag always remain the first. Mandating 
that on propagation insures that any policy associated with the first tag will 
work network-wide.

If you are not convinced, so be it - we have lived with the lax language in RFC 
5130 for years. But some things may not be working because of that.

   Les


> -Original Message-
> From: Acee Lindem 
> Sent: Monday, March 4, 2024 12:12 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Tony Przygienda ; lsr 
> Subject: Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-
> ietf-lsr-ospf-admin-tags
> 
> Hi Les,
> 
> > On Mar 3, 2024, at 11:41 PM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > Not overly complicate things...
> >
> > The requirement to ensure that the first tag remains the first tag when tags
> are propagated suggests that the following language from RFC 5130 is a bit
> lax:
> >
> > "When propagating TLVs between levels, a compliant IS-IS
> >   implementation MAY be able to rewrite or remove one or more tags
> >   associated with a prefix..."
> >
> > I think it is required that the first tag never be rewritten/removed when
> propagating.
> >
> > Acee - maybe you want to tighten up the language in the OSPF draft on this
> point?
> 
> Why would we want to specify this constraint on local policy? Local IGP
> filtering policies are not standardized today and, as you know, many non-
> standard IGP policy implementations exist.
> Thanks,
> Acee
> 
> 
> 
> >
> >   Les
> >
> >
> >> -Original Message-
> >> From: Acee Lindem 
> >> Sent: Friday, March 1, 2024 10:27 AM
> >> To: Tony Przygienda 
> >> Cc: Les Ginsberg (ginsberg) ; lsr 
> >> Subject: Re: [Lsr] bunch comments on
> https://datatracker.ietf.org/doc/draft-
> >> ietf-lsr-ospf-admin-tags
> >>
> >> At the risk of complication, I've added text to clarify the ordering
> >> independence (from RFC 5130) and the usage when multiple LSAs
> contribute
> >> to a path in -14.
> >>
> >> I also specified the behavior for an invalid length - while I agree with 
> >> Les this
> is
> >> a generic problem, it isn't necessary handled generically across IGPs, 
> >> TLVs,
> and
> >> sub-TLVs. I'm used to addressing this class of comment,  Alvaroisms.😎
> >>
> >> Thanks and have a Great Weekend,
> >> Acee
> >>
> >>> On Feb 29, 2024, at 2:05 PM, Tony Przygienda 
> >> wrote:
> >>>
> >>> sure, on the tags given how some people start to abuse4 those in
> interesting
> >> ways now ;-) I'm piping in here since I'm obviously talking through some
> real
> >> OSPF designs where the issue of which ones will make it may matter given
> for
> >> practical reasons we have to limit how many we carry ... ;-)
> >>>
> >>> on the second point, don't write "this sub-TLV should carry at least one
> tag"
> >> if you don't specify what it means it doesn't carry one. No biggie, I just
> edged
> >> onto this when reading it ...
> >>>
> >>> if authors are not interested in making the spec tighter, closing possible
> holes
> >> then I just pipe out of course ...
> >>>
> >>> -- tony
> >>>
> >>> On Thu, Feb 29, 2024 at 8:01 PM Les Ginsberg (ginsberg)
> >>  wrote:
> >>> Tony –
> >>> In the spirit of a friendly discussion…
> >>>  From: Lsr  On Behalf Of Tony Przygienda
> >>> Sent: Thursday, February 29, 2024 10:33 AM
> >>> To: Acee Lindem 
> >>> Cc: lsr 
> >>> Subject: Re: [Lsr] bunch comments on
> >> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags
> >>>  1. you can easily rectify by saying, if you have  tags for same prefix 
> >>> from

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

[Les Ginsberg (ginsberg)]

I also support publication of this document.
The functionality defined herein adds valuable flexibility to the way Flex 
Topologies can be defined.

Although I have not reviewed Acee’s comments exhaustively, I agree with the 
points he is making and would like to see an updated version of the draft prior 
to making a final determination.

   Les


From: Lsr  On Behalf Of Acee Lindem
Sent: Thursday, February 29, 2024 2:46 PM
To: Acee Lindem 
Cc: lsr ; draft-ietf-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

Authors,

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

1. "Backward Compatibility" section is missing. This should be 
straightforward given that an FAD computation only includes
nodes supporting that FAD.
 2. “Security Considerations” is “TBD”.
 3. There is no “Operational Considerations” section. Someone may ask for 
one.
 4. The document alludes to the problem with elephant flows. Yet for 
“Interface Group Mode”, the aggregate bandwidth for multiple L3 links is used. 
How would this work when a flow is typically bound to a single L3 interface?
 5. #3 in section 5 is very hard to parse. Possibly split into multiple 
coherent sentences.

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

  1. Use “sub-TLV” and “Sub-TLV” consistent with the usage in RFC  9350. I 
tried to fix these on the fly but it probably still needs work. Basically, it 
is capitalized when used as part of a proper noun identifying a specific 
sub-TLV. Also, in section titles and captions.
  2. Reference RFC9350 rather than the Flex-Algo draft throughout.
  3. I didn’t make the change but I’d use “Layer-2” and “Layer-3” 
hyphenated.

See attached editorial suggestions  in the RFC diff.

Thanks,
Acee



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

Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

[Les Ginsberg (ginsberg)]

Not overly complicate things...

The requirement to ensure that the first tag remains the first tag when tags 
are propagated suggests that the following language from RFC 5130 is a bit lax:

"When propagating TLVs between levels, a compliant IS-IS
   implementation MAY be able to rewrite or remove one or more tags
   associated with a prefix..."

I think it is required that the first tag never be rewritten/removed when 
propagating.

Acee - maybe you want to tighten up the language in the OSPF draft on this 
point?

   Les


> -Original Message-
> From: Acee Lindem 
> Sent: Friday, March 1, 2024 10:27 AM
> To: Tony Przygienda 
> Cc: Les Ginsberg (ginsberg) ; lsr 
> Subject: Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-
> ietf-lsr-ospf-admin-tags
> 
> At the risk of complication, I've added text to clarify the ordering
> independence (from RFC 5130) and the usage when multiple LSAs contribute
> to a path in -14.
> 
> I also specified the behavior for an invalid length - while I agree with Les 
> this is
> a generic problem, it isn't necessary handled generically across IGPs, TLVs, 
> and
> sub-TLVs. I'm used to addressing this class of comment,  Alvaroisms.😎
> 
> Thanks and have a Great Weekend,
> Acee
> 
> > On Feb 29, 2024, at 2:05 PM, Tony Przygienda 
> wrote:
> >
> > sure, on the tags given how some people start to abuse4 those in interesting
> ways now ;-) I'm piping in here since I'm obviously talking through some real
> OSPF designs where the issue of which ones will make it may matter given for
> practical reasons we have to limit how many we carry ... ;-)
> >
> > on the second point, don't write "this sub-TLV should carry at least one 
> > tag"
> if you don't specify what it means it doesn't carry one. No biggie, I just 
> edged
> onto this when reading it ...
> >
> > if authors are not interested in making the spec tighter, closing possible 
> > holes
> then I just pipe out of course ...
> >
> > -- tony
> >
> > On Thu, Feb 29, 2024 at 8:01 PM Les Ginsberg (ginsberg)
>  wrote:
> > Tony –
> >  In the spirit of a friendly discussion…
> >   From: Lsr  On Behalf Of Tony Przygienda
> > Sent: Thursday, February 29, 2024 10:33 AM
> > To: Acee Lindem 
> > Cc: lsr 
> > Subject: Re: [Lsr] bunch comments on
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags
> >   1. you can easily rectify by saying, if you have  tags for same prefix 
> > from
> multiple nodes you prefere lowest router ID or maybe "sort on router id and
> then interleave" or something. depending how much of fully fledged
> specification you want here
> >  [LES:] As Acee has pointed out, the IS-IS RFC (written many years ago)
> explicitly stayed away from this sort of thing.
> > Are you saying that your experience with IS-IS has been unsatisfactory? If 
> > so,
> why aren’t you lobbying for changes to IS-IS? (Not that I am encouraging you
> to do so… 😊 )
> >   2. we miss each other. I just say this sub-TLV being empty is NOT 
> > specified
> (i.e. behavior is undefined) if anyone sends such a thing
> > [LES:] From the POV of parsing, if you send a TLV with 0 length, it does no
> harm. Your parsing logic will just move on to the next TLV. I don’t see the 
> need
> to specify any behavior.
> > Of course, it is useless to send this TLV with no content – so if your
> implementation wants to report that as an encoding error that seems
> reasonable to me.
> > If you send a length of 0 but actually have content, that is a serious 
> > encoding
> error – but that is a generic issue that seems outside the scope of this 
> draft.
> > Les
> > -- tony
> >   On Wed, Feb 28, 2024 at 7:13 PM Acee Lindem 
> wrote:
> > Hi Tony,
> >
> > > On Feb 28, 2024, at 2:01 AM, Tony Przygienda 
> wrote:
> > >
> > > hey Acee, inline
> > >
> > >
> > > On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem 
> wrote:
> > > Hi Tony,
> > >
> > > Thanks for the review.
> > >
> > >> On Feb 27, 2024, at 04:51, Tony Przygienda 
> wrote:
> > >>
> > >> Reading the draft quickly, here's bunch of observations
> > >>
> > >> "
> > >>
> > >> An OSPF router supporting this specification MUST be able to
> > >> advertise and interpret at least one 32-bit tag for all type of
> > >> prefixes. An OSPF router supporting this specification MAY be able
> > >> to advertise and propagate multiple 32-bit tags

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Les Ginsberg (ginsberg)]

I support WG adoption of this draft.
Being able to advertise a link that is not used in the base SPF is a useful 
functionality to have.

I do think that the language currently used in the draft could be improved.
Currently the draft says:

“there are requirements to advertise unreachable
   links in OSPF for purposes other than building the normal Shortest
   Path Tree.”

The term “unreachable link” is a misnomer. If the link were truly unreachable 
it couldn’t be used for any purpose.
I would suggest the language be changed to more closely mimic RFC 5305:

“If a link is advertised with the maximum link metric (2^24 - 1), this
   link MUST NOT be considered during the normal SPF computation.  This
   will allow advertisement of a link for purposes other than building
   the normal Shortest Path Tree.”

“MUST NOT be considered” is a much more accurate description than “unreachable”.

I leave it to the authors to decide how best to revise the draft language.

   Les


From: Lsr  On Behalf Of Yingzhen Qu
Sent: Thursday, February 22, 2024 9:28 PM
To: lsr ; lsr-chairs 
Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link 
(02/23/24 - 03/08/24)


Hi,



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

https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/



Please review the document and indicate your support or objections by March 
8th, 2024.

Authors and contributors, please respond to the list indicating whether you are 
aware of any IPR that applies to the draft.

Thanks,

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

Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

[Les Ginsberg (ginsberg)]

Tony –

In the spirit of a friendly discussion…

From: Lsr  On Behalf Of Tony Przygienda
Sent: Thursday, February 29, 2024 10:33 AM
To: Acee Lindem 
Cc: lsr 
Subject: Re: [Lsr] bunch comments on 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

1. you can easily rectify by saying, if you have  tags for same prefix from 
multiple nodes you prefere lowest router ID or maybe "sort on router id and 
then interleave" or something. depending how much of fully fledged 
specification you want here

[LES:] As Acee has pointed out, the IS-IS RFC (written many years ago) 
explicitly stayed away from this sort of thing.
Are you saying that your experience with IS-IS has been unsatisfactory? If so, 
why aren’t you lobbying for changes to IS-IS? (Not that I am encouraging you to 
do so… 😊 )

2. we miss each other. I just say this sub-TLV being empty is NOT specified 
(i.e. behavior is undefined) if anyone sends such a thing
[LES:] From the POV of parsing, if you send a TLV with 0 length, it does no 
harm. Your parsing logic will just move on to the next TLV. I don’t see the 
need to specify any behavior.
Of course, it is useless to send this TLV with no content – so if your 
implementation wants to report that as an encoding error that seems reasonable 
to me.
If you send a length of 0 but actually have content, that is a serious encoding 
error – but that is a generic issue that seems outside the scope of this draft.

   Les


-- tony

On Wed, Feb 28, 2024 at 7:13 PM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Hi Tony,

> On Feb 28, 2024, at 2:01 AM, Tony Przygienda 
> mailto:tonysi...@gmail.com>> wrote:
>
> hey Acee, inline
>
>
> On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem 
> mailto:acee.i...@gmail.com>> wrote:
> Hi Tony,
>
> Thanks for the review.
>
>> On Feb 27, 2024, at 04:51, Tony Przygienda 
>> mailto:tonysi...@gmail.com>> wrote:
>>
>> Reading the draft quickly, here's bunch of observations
>>
>> "
>>
>> An OSPF router supporting this specification MUST be able to
>> advertise and interpret at least one 32-bit tag for all type of
>> prefixes. An OSPF router supporting this specification MAY be able
>> to advertise and propagate multiple 32-bit tags. The maximum tags
>> that an implementation supports is a local matter depending upon
>> supported applications using prefix tags.
>> "
>>
>>
>> Since different implementations may support different amount of tags I see 
>> that the draft says
>>
>> "
>> When propagating multiple tags, the order
>> of the the tags SHOULD be preserved.
>>
>> "
>>
>>
>> this is IMO not good enough in case where two nodes advertise same prefix 
>> with multiple tags, possibly differing or in different order. Some kind of 
>> ordering is necessary then as well AFAIS.
>>
>
> I guess I don’t see the problem. A policy would look for a specific tag and 
> take a specific action.
>
> Note that for IS-IS tags so require ordering, see section 4 of  
> https://datatracker.ietf.org/doc/rfc5130/.
> I could possibly appropriate some of this text as it applies to OSPF.
>
>
> my point is that if you have multiple nodes advertising some prefix with 
> different 3 tag combinations and you choose to only support 3 tags the result 
> is undefined by this draft as to which tags propagate at the end, so the 
> "order should be preserved" doesn't help

I agree this could be a problem if you have this situation but I don’t see how 
advertising the tags in any particular order rectifies it. Also, since an OSPF 
domain is under a single administrative domain, I also don’t understand why 
anyone would configure such a situation. You could also have a problem if you 
have different nodes supporting different policies for the same prefix. Unless 
you can convince me, I’m going to stick with the IS-IS semantics for multiple 
tags. From RFC  5130.


  The semantics of the tag order are implementation-dependent. That
   is, there is no implied meaning to the ordering of the tags that
   indicates a certain operation or set of operations need be performed
   based on the order of the tags. Each tag SHOULD be treated as an
   autonomous identifier that MAY be used in policy to perform a policy
   action. Whether or not tag A precedes or succeeds tag B SHOULD not
   change the meaning of the tag set. However, when propagating TLVs
   that contain multiple tags between levels, an implementation SHOULD
   preserve the ordering such that the first tag remains the first tag,
   so that implementations that only recognize a single tag will have a
   consistent view across levels.



>
>
>
>
>>
>>
>> "
>> This sub-TLV will carry one or more 32-bit unsigned integer values
>> that will be used as administrative tags.
>> "
>>
>>
>> IMO behavior when none are carried nees to be specified if this is mandated. 
>> is that a MUST in fact?
>>
>
>  The sub-TLV is optional so if it isn’t specified than there are no tags to 
> match. What am I missing here?
>
> it says "one

Re: [Lsr] [Tsv-art] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06

[Les Ginsberg (ginsberg)]

Mirja -

Please see inline.
LES2:

> -Original Message-
> From: Mirja Kuehlewind (IETF) 
> Sent: Thursday, February 8, 2024 5:11 AM
> To: Les Ginsberg (ginsberg) 
> Cc: tsv-...@ietf.org; draft-ietf-lsr-isis-fast-flooding@ietf.org; 
> lsr@ietf.org
> Subject: Re: [Tsv-art] Tsvart early review of 
> draft-ietf-lsr-isis-fast-flooding-06
> 
> Hi Les!
> 
> Please see below.
> 
> > On 5. Feb 2024, at 23:28, Les Ginsberg (ginsberg)
>  wrote:
> >
> > Mirja -
> >
> > In regards to Section 6.3...
> >
> >
> >>
> >> Sec 6.3
> >> This section is entirely not clear to me. There is no algorithm described 
> >> and I
> >> would not know how to implement this.
> >
> > [LES:] This is intentional.
> > As this approach is NOT dependent on any signaling from the receiver, the
> transmitter is free to implement in whatever manner it finds effective - there
> are no interoperability issues.
> > As we state:
> >
> > "Such an algorithm is a local matter and there is no requirement or intent 
> > to
> standardize an algorithm."
> 
> Yes, this does not be standardised but if you talk about it you need to 
> explain it
> in enough detail that people can impelemt something use. Other I don’t see a
> point about having this section at all.
> 

[LES2:] We explain the behavior.
The actual implementation is - at least for now - proprietary.
So yes - exactly "how" the requirements are met is not discussed.
But folks who are "skilled in the art" should be able to use this as a guide to 
developing their own implementation.

> >
> >> Also because you interchangeably
> >> use the
> >> terms congestion control and flow control.
> >
> > [LES:]  Good point.
> > I believe we should use the term "congestion control" throughout this
> section.
> > Will work with Bruno to make that change.
> >
> >> Further you say that no input
> >> signal
> >> from the receiver is needed, however, if you want to send with the rate of
> >> acknowledgement received that is an input from the receiver.
> >
> > [LES:] The use of the neighbor partialSNPInterval sub-TLV (Section 4.5) is
> optional.
> > It may be useful, but as our intention is to have the algorithm work with
> legacy neighbors who do not support the additional advertisements defined in
> this document, it is necessary that the algorithm work well even in the 
> absence
> of that signaling.
> > If by "rate of acknowledgement ...is an input from the receiver" you think 
> > we
> are contradicting ourselves, I will gently pushback.
> > We have not changed the operation of the Update Process in any way. So
> the acks we receive and the rate at which they were received is information
> which is available today from current operation of the Update Process. To date
> it just hasn’t been used to influence transmission rate of other LSPs - it has
> only been used to cancel retransmissions on the LSPs already sent.
> >
> > [ >However, the
> >> window based TCP-like algorithms does actually implicitly exactly that: it
> only
> >> send new data if an acknowledgement is received. It further also takes the
> >> number of PDUs that are acknowledged into account because that can be
> >> configured. If you don’t do that, you sending rate will get lower and 
> >> lower.
> >>
> > [LES:] Paragraphs 4, 5, 6 discuss both slowing down the transmission rate
> and speeding up the transmission rate. The algorithm needs to do both - and
> does so based on the actual performance i.e., how quickly ACKs have been
> received.
> > Paragraph 6 highlights that we cannot assume that performance is static. If
> you think that once we slow down we will never speed up then please reread
> Paragraph 5.
> >
> > At the risk of repeating myself, I emphasize that lack of dependence on
> signaling by the receiver is a key element of this approach which enables it 
> to
> work with both legacy and upgraded nodes.
> 
> I think we have a terminology problem here. I say the ack rate is a signal 
> from
> the receiver; you say there is no additional saviour change needed in order to
> get this single. I agree that is an important point but to me that not what 
> the
> text says (because rate IS a signal). In summary I think what need is to
> improve the wording to make this clear (to all of us).
> 
[LES2:] There is no signal of ack rate being sent. Normal operation of the 
IS-IS Update process requires receivers to send ACKs (in PSNPs) to the 
transmitter.
"ack rate" can be tracked by the transmitter simply by keeping a history of the 
number of LSP acknowledgements it has received over a multi-second period.
I think it would be misleading to characterize the sending of PSNPs as a 
"signal of ack rate". 

Hope this makes sense.

  Les

> Mirja
> 
> 
> 
> 
> >
> >   Les
> > ___
> > Tsv-art mailing list
> > tsv-...@ietf.org
> > https://www.ietf.org/mailman/listinfo/tsv-art

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

Re: [Lsr] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06

[Les Ginsberg (ginsberg)]

In regards to "operation on a LAN interface",



>

> > Section 6.2.1.2:

> > “f no PSNPs have been generated on the LAN for a suitable period of time,

> then an LSP transmitter can safely set the number of un-acknowledged LSPs to

> zero.

> > Since this suitable period of time is much higher than the fast

> acknowledgment of LSPs defined in Section 5.1, the sustainable transmission

> rate of LSPs will be much slower on a LAN interface than on a point-to-point

> interface.”

> >

> > What a suitable period of time? Can you be more concrete?

>

> [Bruno] Good question. But difficult question.

> Les, would you have some suggestion?

> Otherwise, rather than adding more text for the LAN case, I'd rather remove

> some text with the following change

>

> OLD:

> However, an LSP transmitter on a LAN can infer whether any LSP receiver on

> the LAN has requested retransmission of LSPs from the DIS by monitoring

> PSNPs generated on the LAN. If no PSNPs have been generated on the LAN for

> a suitable period of time, then an LSP transmitter can safely set the number 
> of

> un-acknowledged LSPs to zero. Since this suitable period of time is much

> higher than the fast acknowledgment of LSPs defined in Section 5.1, the

> sustainable transmission rate of LSPs will be much slower on a LAN interface

> than on a point-to-point interface.

>

> NEW: /nothing/

>

> As already stated, probably one could do better in the LAN case. E.g.,

> advertising the delay between periodic CSNP (which would answer your

> question), sending in (LSP-ID) order, having the receiver send PSNP on a range

> of LSP-ID after a specific delay/LPP. But again, LAN is not seen as the 
> priority in

> this document.

>

[LES:] As has been noted, we already say in Section 4.7 (which does discuss the 
LAN issues)



"A full discussion of how best to do faster flooding on a LAN interface is 
therefore out of scope for this document."



The problem (as Bruno has indicated) as regards operational practices is that 
whatever we say will be incomplete and to some extent unsatisfactory as we have 
not studied this problem.

There are no doubt many things that could be said - but no collection results 
in a sound operational description of how to do fast flooding on a LAN.

I think we would be better off (and more honest 😊) if in Section 6.2.1.2 we 
simply said:



"As operation of fast flooding on a LAN interface is out of scope for this 
document, this section is intentionally empty."



??



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

Re: [Lsr] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06

[Les Ginsberg (ginsberg)]

Mirja -

In regards to Section 6.3...


> 
> Sec 6.3
> This section is entirely not clear to me. There is no algorithm described and 
> I
> would not know how to implement this.

[LES:] This is intentional.
As this approach is NOT dependent on any signaling from the receiver, the 
transmitter is free to implement in whatever manner it finds effective - there 
are no interoperability issues.
As we state:

"Such an algorithm is a local matter and there is no requirement or intent to 
standardize an algorithm."

> Also because you interchangeably
> use the
> terms congestion control and flow control. 

[LES:]  Good point.
I believe we should use the term "congestion control" throughout this section.
Will work with Bruno to make that change.

> Further you say that no input
> signal
> from the receiver is needed, however, if you want to send with the rate of
> acknowledgement received that is an input from the receiver. 

[LES:] The use of the neighbor partialSNPInterval sub-TLV (Section 4.5) is 
optional.
It may be useful, but as our intention is to have the algorithm work with 
legacy neighbors who do not support the additional advertisements defined in 
this document, it is necessary that the algorithm work well even in the absence 
of that signaling.
If by "rate of acknowledgement ...is an input from the receiver" you think we 
are contradicting ourselves, I will gently pushback.
We have not changed the operation of the Update Process in any way. So the acks 
we receive and the rate at which they were received is information which is 
available today from current operation of the Update Process. To date it just 
hasn’t been used to influence transmission rate of other LSPs - it has only 
been used to cancel retransmissions on the LSPs already sent.

[ >However, the
> window based TCP-like algorithms does actually implicitly exactly that: it 
> only
> send new data if an acknowledgement is received. It further also takes the
> number of PDUs that are acknowledged into account because that can be
> configured. If you don’t do that, you sending rate will get lower and lower.
> 
[LES:] Paragraphs 4, 5, 6 discuss both slowing down the transmission rate and 
speeding up the transmission rate. The algorithm needs to do both - and does so 
based on the actual performance i.e., how quickly ACKs have been received.
Paragraph 6 highlights that we cannot assume that performance is static. If you 
think that once we slow down we will never speed up then please reread 
Paragraph 5.

At the risk of repeating myself, I emphasize that lack of dependence on 
signaling by the receiver is a key element of this approach which enables it to 
work with both legacy and upgraded nodes.

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

[Les Ginsberg (ginsberg)]

Acee -

So in 6.2.1.1 you propose to change:

" By sending the Receive Window sub-TLV..."

To

" By sending the Burst Size sub-TLV..."

I agree with that change. 
Bruno - what do you think?

In 6.2.2.2 you propose to change:

" In order for the LSP Receive Window to be a useful parameter, an LSP
   transmitter needs to be able to keep track of the number of un-
   acknowledged LSPs it has sent to a given LSP receiver."

To 

" In order for the LSP Burst Size to be a useful parameter, an LSP
   transmitter needs to be able to keep track of the number of un-
   acknowledged LSPs it has sent to a given LSP receiver."

I don’t agree with this.

6.2.1.1 has text specific for receiving LSPs " without an intervening delay".
6.2.2.2 does not have that text - though maybe it should.

I think to fully address your concern, we need to make 6.2.1.1 and 6.2.2.2 more 
analogous - which will require some additional changes.
I am open to this - Bruno - what do you think?

I also agree with changing "Receive Window sub-TLV" to " LSP Receive Window 
sub-TLV". Definitely improves consistency in naming.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Thursday, February 1, 2024 9:42 AM
> To: Les Ginsberg (ginsberg) 
> Cc: DECRAENE Bruno INNOV/NET ; John
> Scudder ; lsr ; Tony Li ;
> gsoli...@protonmail.com; Antoni Przygienda ; Gunter van
> de Velde (Nokia) ; Marek Karasek
> (mkarasek) 
> Subject: Re: [Lsr] AD review of draft-ietf-lsr-isis-fast-flooding-05
> 
> 
> 
> > On Feb 1, 2024, at 12:33 PM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > Acee -
> >
> >>> ---
> >>> //Acee
> >>>
> >>> A bigger issue from that historical artifact is that some text refers to 
> >>> "LSP
> >> Burst Window" when they should refer to the "new" (from -01) "Receive
> >> Window sub-TLV". That's a bigger issue as "in letter" this may be seen as
> >> technical change (even if "in spirit" the Flow Control Receive Window
> logically
> >> refers to the Receive Window sub-TLV)
> >>> This requires the following changes in the 6.2.1 "Flow control" section:
> >>
> >> I see that the changes are already in place in -06. Note that I think you
> should
> >> rename “Receive Window” to “LSP Burst Window” for consistency.  In
> reading
> >> the guidance in section 6.2.1, It seems to me that this should have been
> “LSP
> >> Receive Window” all along. We are not changing the semantics of "LSP
> Burst
> >> Window" or "LSP Receive Window”.
> >>
> >> I’d be interested in what the other co-authors think (especially Les 😎).
> >
> > [LES:] It seems to me you are confusing "Burst" and "Receive".
> >
> > When we discuss fast-flooding we tend to focus on the "major incidents"
> e.g., a node with 1000 neighbors goes down - we are likely to need to flood
> 1000 LSPs.
> > "Burst" isn't very useful here because the Burst Size (was Burst Window) is
> small compared to the total number of LSPs that need to be flooded as quickly
> as possible.
> >
> > But far more common are the "minor incidents" where a single link goes
> down - where a small number (typically 2) LSPs need to be flooded - or a 
> single
> node with a modest number of neighbors goes down where the number of
> LSPs which will be flooded is still modest (5 or 10 or 20). In these cases, 
> being
> able to flood a "burst" is worthwhile because it means we can flood all the
> LSPs associated with a topology change more quickly - meaning fewer SPFs
> need to be executed. This notion was first highlighted 20 years ago when
> "fast-convergence" work was done.
> >
> > But the "Burst Size" is certainly expected to be significantly smaller than 
> > the
> "Receive Window" - and the latter logically includes the LSPs received as 
> part of
> a Burst.
> >
> > So I don’t see that what you are suggesting makes sense.
> 
> I’m talking about -06 changes to section 6.2.1.1 and 6.2.1.2 to reference
> “Receive Window” rather than “LSP Burst”. Please look at these.
> 
> 
> Thanks,
> Acee
> 
> 
> 
> >
> > Let me know if I have misunderstood your point.
> >
> >   Les
> >
> >>
> >> Thanks,
> >> Acee
> >>
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Acee -

> > ---
> > //Acee
> >
> > A bigger issue from that historical artifact is that some text refers to 
> > "LSP
> Burst Window" when they should refer to the "new" (from -01) "Receive
> Window sub-TLV". That's a bigger issue as "in letter" this may be seen as
> technical change (even if "in spirit" the Flow Control Receive Window 
> logically
> refers to the Receive Window sub-TLV)
> > This requires the following changes in the 6.2.1 "Flow control" section:
> 
> I see that the changes are already in place in -06. Note that I think you 
> should
> rename “Receive Window” to “LSP Burst Window” for consistency.  In reading
> the guidance in section 6.2.1, It seems to me that this should have been “LSP
> Receive Window” all along. We are not changing the semantics of "LSP Burst
> Window" or "LSP Receive Window”.
> 
> I’d be interested in what the other co-authors think (especially Les 😎).

[LES:] It seems to me you are confusing "Burst" and "Receive".

When we discuss fast-flooding we tend to focus on the "major incidents" e.g., a 
node with 1000 neighbors goes down - we are likely to need to flood 1000 LSPs.
"Burst" isn't very useful here because the Burst Size (was Burst Window) is 
small compared to the total number of LSPs that need to be flooded as quickly 
as possible.

But far more common are the "minor incidents" where a single link goes down - 
where a small number (typically 2) LSPs need to be flooded - or a single node 
with a modest number of neighbors goes down where the number of LSPs which will 
be flooded is still modest (5 or 10 or 20). In these cases, being able to flood 
a "burst" is worthwhile because it means we can flood all the LSPs associated 
with a topology change more quickly - meaning fewer SPFs need to be executed. 
This notion was first highlighted 20 years ago when "fast-convergence" work was 
done.

But the "Burst Size" is certainly expected to be significantly smaller than the 
"Receive Window" - and the latter logically includes the LSPs received as part 
of a Burst.

So I don’t see that what you are suggesting makes sense.

Let me know if I have misunderstood your point.

   Les

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

Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Les Ginsberg (ginsberg)]

One more attempt…

The question being asked in this thread is “Should 
draft-ietf-lsr-isis-sr-vtn-mt proceed to WG Last Call?”.

It has been noted that the relevance – indeed even the need for the draft - 
depends upon several documents which are in various stages of discussion 
including:

https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-08
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-for-enhanced-vpn-06
https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-17
https://datatracker.ietf.org/doc/html/draft-ietf-teas-nrp-scalability-03
https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-10

The eventual progression of these documents is not only necessary in order to 
satisfy the dependencies in this draft, it may also determine whether the draft 
is even relevant to the defined NRP solutions.

Regardless of whether you approve of the content of 
draft-ietf-lsr-isis-sr-vtn-mt and/or think the document is “mature”, it is 
simply premature to proceed to WG last call.


(As an aside, the wisdom of defining multiple solutions to NRP – some of which 
might only be suitable at “low scale” – needs to be discussed.
The cost – both in development and deployment – of multiple solutions for the 
same problem space is considerable. This should not be accepted casually.

Jie – you and I clearly don’t agree on how this should be approached – and in 
particular on the meaning of this discussion in the nrp-scalability draft.
Fair enough. But this is an issue of significance and needs to be openly 
discussed – though not in the context of this thread.)

   Les



From: Les Ginsberg (ginsberg) 
Sent: Friday, January 19, 2024 11:37 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem 

Cc: Chongfeng Xie ; TEAS WG ; lsr 

Subject: RE: [Teas] [Lsr] Fwd: Working Group Last Call for "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06


(Update - Avee - I now see the shepherds email that you sent a short while ago. 
It got stored in a different folder in my mailer due to the addition of other 
WGs on the TO list. ☹)

But it doesn’t change my response.)



   Les





> -Original Message-

> From: Teas mailto:teas-boun...@ietf.org>> On Behalf Of 
> Les Ginsberg (ginsberg)

> Sent: Friday, January 19, 2024 11:30 AM

> To: Acee Lindem mailto:acee.i...@gmail.com>>

> Cc: Chongfeng Xie 
> mailto:chongfeng@foxmail.com>>; TEAS WG 
> mailto:t...@ietf.org>>;

> lsr mailto:lsr@ietf.org>>

> Subject: Re: [Teas] [Lsr] Fwd: Working Group Last Call for "Applicability of 
> IS-IS

> Multi-Topology (MT) for Segment Routing based Network Resource Partition

> (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

>

> Acee -

>

> I am not sure what your full intent is.

> There are a number of statements in the NRP scaling document regarding the

> use of routing protocols - you selected only one to comment on - not sure

> why.

>

> The gist of the multiple comments serves to discourage the use of routing

> protocols as a means of supporting NRP. I support this because I think this is

> an inappropriate use of routing protocols.

> Sure, at small scale modest impact might be the result - but I don’t see the

> point in developing protocol extensions (note that the use of existing MT

> technology is not the end of the protocol requirements - just the beginning)

> that only work or are acceptable at small scale.

>

> You may disagree - but if so I would appreciate a discussion of the larger

> questions - not just the one sentence.

>

> No - I have not seen your shepherd writeup - it does not seem to be visible on

> the document status page.

>

>Les

>

>

> > -Original Message-

> > From: Acee Lindem mailto:acee.i...@gmail.com>>

> > Sent: Friday, January 19, 2024 11:05 AM

> > To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>

> > Cc: Chongfeng Xie 
> > mailto:chongfeng@foxmail.com>>; Les Ginsberg 
> > (ginsberg)

> > mailto:ginsb...@cisco.com>>; jmh 
> > mailto:j...@joelhalpern.com>>; TEAS WG

> > mailto:t...@ietf.org>>; lsr 
> > mailto:lsr@ietf.org>>

> > Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability 
> > of IS-

> IS

> > Multi-Topology (MT) for Segment Routing based Network Resource Partition

> > (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

> >

> > Speaking as WG member:

> >

> > Hi Les,

> >

> > You probably saw my shepherd review of this document.

> >

> > > On Jan 11, 2024, at 2:33 AM, Les Ginsberg (ginsberg)

> mailto:ginsb...@cisco.com>>

> > wrote:

&

Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Les Ginsberg (ginsberg)]

(Update - Avee - I now see the shepherds email that you sent a short while ago. 
It got stored in a different folder in my mailer due to the addition of other 
WGs on the TO list. ☹)

But it doesn’t change my response.)



   Les





> -Original Message-

> From: Teas  On Behalf Of Les Ginsberg (ginsberg)

> Sent: Friday, January 19, 2024 11:30 AM

> To: Acee Lindem 

> Cc: Chongfeng Xie ; TEAS WG ;

> lsr 

> Subject: Re: [Teas] [Lsr] Fwd: Working Group Last Call for "Applicability of 
> IS-IS

> Multi-Topology (MT) for Segment Routing based Network Resource Partition

> (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

>

> Acee -

>

> I am not sure what your full intent is.

> There are a number of statements in the NRP scaling document regarding the

> use of routing protocols - you selected only one to comment on - not sure

> why.

>

> The gist of the multiple comments serves to discourage the use of routing

> protocols as a means of supporting NRP. I support this because I think this is

> an inappropriate use of routing protocols.

> Sure, at small scale modest impact might be the result - but I don’t see the

> point in developing protocol extensions (note that the use of existing MT

> technology is not the end of the protocol requirements - just the beginning)

> that only work or are acceptable at small scale.

>

> You may disagree - but if so I would appreciate a discussion of the larger

> questions - not just the one sentence.

>

> No - I have not seen your shepherd writeup - it does not seem to be visible on

> the document status page.

>

>Les

>

>

> > -Original Message-----

> > From: Acee Lindem mailto:acee.i...@gmail.com>>

> > Sent: Friday, January 19, 2024 11:05 AM

> > To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>

> > Cc: Chongfeng Xie 
> > mailto:chongfeng@foxmail.com>>; Les Ginsberg 
> > (ginsberg)

> > mailto:ginsb...@cisco.com>>; jmh 
> > mailto:j...@joelhalpern.com>>; TEAS WG

> > mailto:t...@ietf.org>>; lsr 
> > mailto:lsr@ietf.org>>

> > Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability 
> > of IS-

> IS

> > Multi-Topology (MT) for Segment Routing based Network Resource Partition

> > (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

> >

> > Speaking as WG member:

> >

> > Hi Les,

> >

> > You probably saw my shepherd review of this document.

> >

> > > On Jan 11, 2024, at 2:33 AM, Les Ginsberg (ginsberg)

> mailto:ginsb...@cisco.com>>

> > wrote:

> > >

> > > Chongfeng –

> > >  We are at the stage of last call.

> > > The document has been presented and discussed previously – it is time for

> > WG members to render their opinions.

> > >  For folks who have actively followed/participated in the discussion, it 
> > > is

> very

> > unlikely that we will alter opinions by further discussion. Which means if 
> > you

> > and I have different points of view it is very unlikely that I will alter 
> > your

> > opinion and very unlikely that you will alter mine.

> > > In that context, I typically do not reply when someone posts their opinion

> > and it is different than mine. The point of last call is to get the 
> > opinions of WG

> > members.

> > >  In this case, however, I will respond with some clarifications – not in 
> > > the

> > hopes of changing your mind – but only to provide additional clarity as to

> why

> > I have the opinion that I do.

> > >  The use of MT in support of NRP – at whatever scale – clearly requires

> > additional SPF calculations – which is something which is expressly 
> > identified

> > as undesirable in draft-ietf-teas-nrp-scalability.

> > > draft-ietf-teas-nrp-scalability also states (as you have pointed out) that

> > “control plane extensions” are seen as undesirable.

> >

> > I think this needs to removed or at least softened in the NRP scaling

> > document. The drawbacks of SPF calculations are greatly exaggerated

> > (especially if implemented efficiently on today’s CPUs). Furthermore, it

> would

> > be hypocritical to say that SPF calculations are to avoided and to then

> > standardize features such as TI-LFA.

> >

> > Thanks,

> > Acee

> >

> >

> >

> >

> > >  Having implemented the use of MT for purposes other than supporting

> the

> > reserved AFI/SAFI specific topologies specified in RFC 5120, I can tell you

> that

> > there is a signi

Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Les Ginsberg (ginsberg)]

Acee -

I am not sure what your full intent is. 
There are a number of statements in the NRP scaling document regarding the use 
of routing protocols - you selected only one to comment on - not sure why.

The gist of the multiple comments serves to discourage the use of routing 
protocols as a means of supporting NRP. I support this because I think this is 
an inappropriate use of routing protocols.
Sure, at small scale modest impact might be the result - but I don’t see the 
point in developing protocol extensions (note that the use of existing MT 
technology is not the end of the protocol requirements - just the beginning) 
that only work or are acceptable at small scale.

You may disagree - but if so I would appreciate a discussion of the larger 
questions - not just the one sentence.

No - I have not seen your shepherd writeup - it does not seem to be visible on 
the document status page.

   Les


> -Original Message-
> From: Acee Lindem 
> Sent: Friday, January 19, 2024 11:05 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Chongfeng Xie ; Les Ginsberg (ginsberg)
> ; jmh ; TEAS WG
> ; lsr 
> Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of 
> IS-IS
> Multi-Topology (MT) for Segment Routing based Network Resource Partition
> (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
> 
> Speaking as WG member:
> 
> Hi Les,
> 
> You probably saw my shepherd review of this document.
> 
> > On Jan 11, 2024, at 2:33 AM, Les Ginsberg (ginsberg) 
> wrote:
> >
> > Chongfeng –
> >  We are at the stage of last call.
> > The document has been presented and discussed previously – it is time for
> WG members to render their opinions.
> >  For folks who have actively followed/participated in the discussion, it is 
> > very
> unlikely that we will alter opinions by further discussion. Which means if you
> and I have different points of view it is very unlikely that I will alter your
> opinion and very unlikely that you will alter mine.
> > In that context, I typically do not reply when someone posts their opinion
> and it is different than mine. The point of last call is to get the opinions 
> of WG
> members.
> >  In this case, however, I will respond with some clarifications – not in the
> hopes of changing your mind – but only to provide additional clarity as to why
> I have the opinion that I do.
> >  The use of MT in support of NRP – at whatever scale – clearly requires
> additional SPF calculations – which is something which is expressly identified
> as undesirable in draft-ietf-teas-nrp-scalability.
> > draft-ietf-teas-nrp-scalability also states (as you have pointed out) that
> “control plane extensions” are seen as undesirable.
> 
> I think this needs to removed or at least softened in the NRP scaling
> document. The drawbacks of SPF calculations are greatly exaggerated
> (especially if implemented efficiently on today’s CPUs). Furthermore, it would
> be hypocritical to say that SPF calculations are to avoided and to then
> standardize features such as TI-LFA.
> 
> Thanks,
> Acee
> 
> 
> 
> 
> >  Having implemented the use of MT for purposes other than supporting the
> reserved AFI/SAFI specific topologies specified in RFC 5120, I can tell you 
> that
> there is a significant amount of “control plane work” associated with adding
> such support. The fact that no new protocol extensions are required is not the
> same as saying no new control plane work is required. I can assure you that
> there would be a significant amount of control plane work required.
> >  So I do see that draft-ietf-lsr-isis-sr-vtn-mt is at odds with 
> > draft-ietf-teas-
> nrp-scalability.
> >  Thanx for listening.
> >  Les
> >   From: Lsr  On Behalf Of Chongfeng Xie
> > Sent: Wednesday, January 10, 2024 7:41 PM
> > To: Les Ginsberg (ginsberg) ; jmh
> ; Acee Lindem ; TEAS WG
> ; lsr 
> > Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability 
> > of IS-
> IS Multi-Topology (MT) for Segment Routing based Network Resource
> Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
> >   Hi Les,
> >  Thanks for your comments.
> >  This is an informational document which describes the applicability of
> existing IS-IS MT mechanisms for building SR based NRPs. All the normative
> references are either RFCs or stable WG documents. It is true that some
> informative references are individual documents, while they just provide
> additional information related to this topic, thus would not impact the 
> stability
> and maturity of the proposed mechanism.
> >  The text you quoted from draft-ietf-teas-nrp-scalability are about the
> considerations when the number 

Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Les Ginsberg (ginsberg)]

Aijun –

Frankly, I have a limited tolerance for these exchanges because your responses 
to specific points are evasive.
You are like a boxer whose main goal is to avoid any punch thrown by your 
opponent from landing directly. This is a pretty useful skill in a boxing ring, 
but pretty tiresome when trying to have a frank exchange of views on the 
technical points of a draft.
I am unlikely to respond further after this – but please find some responses 
inline. See [LES2:].

From: Aijun Wang 
Sent: Thursday, January 18, 2024 1:29 AM
To: Les Ginsberg (ginsberg) 
Cc: 'Christian Hopps' ; 'Huzhibo' ; 
'Acee Lindem' ; 'Yingzhen Qu' ; 
lsr@ietf.org
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

Hi, Les:

发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> 
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月18日 0:16
收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
抄送: Christian Hopps mailto:cho...@chopps.org>>; Huzhibo 
mailto:huzh...@huawei.com>>; Acee Lindem 
mailto:acee.i...@gmail.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

Aijun -

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Tuesday, January 16, 2024 10:56 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; Huzhibo 
mailto:huzh...@huawei.com>>; Acee Lindem 
mailto:acee.i...@gmail.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

Hi, Les:

Let’s keep the discussions simple.

Please answer the following two questions that you haven’t responsed directly 
in previous mail:
1)How the existing point-to-point based solution(RFC9346/RFC5392) solve 
the broadcast(LAN, A.1 Figure2) inter-AS topology recovery scenario---There are 
multiple neighbors on one interfaces, which are located in different AS. How to 
encode the information within one inter-AS reachability TLV?

[LES:] In the absence of the existence of an advertisement of the LAN itself 
(the “pseudonode” in IS-IS), a LAN is represented as a set of P2P links between 
each of the nodes connected to the LAN.
Less scaleable but just as functional.

You, however, think you can get away with “If R1 advertises connectivity to the 
LAN subnet and R2 and R3 also advertise connectivity to the same subnet that we 
can assume that they are all connected” – which is an assumption that works 
some of the time – but is not guaranteed.
It is easy to imagine this case if there is a switch and one of the ports on 
the switch is faulty. (Other failure scenarios exist)

[WAJ] If one of the ports on the switch is faulty, then the router that 
connected is disconnected from the subnet. The topology recovery will not 
include this router.

[LES2:] You have missed the point. LAN partitioning can occur. So R1 and R2 may 
be able to talk to each and R3 and R4 may be able to talk to each – but the two 
partitions have no connectivity. Yet all nodes will advertise the LAN subnet – 
which in your world means that you think you have full connectivity when you do 
not.

2)How the inter-AS based solutions solve the non inter-AS scenario 
requirements(A.2)?

[LES:] An interesting question given that you haven’t addressed this yourself.
What does it mean to advertise reachability to an anycast address (as you 
propose to do)?
Does that tell you if you are connected to one of anycast servers? Some of the 
anycast servers? All of the anycast servers?
[WAJ] All of the anycast servers

You don’t know – you are just assuming.
But since your goal is “topology discovery” it is important to actually know 
whether you have a link to a particular anycast server or not.
You don’t know – you just assume.
[WAJ] For A.2, the aim is not topology discovery, the aim is to select the 
optimal path(or exits) that to the anycast server, based not only the internal 
link information, but also the stub link information that connects to the 
server.

[LES2:]  Your draft says: “It will be help for the router R0, to know the 
attributes of the stub links and select the optimal Anycast server to serve the 
customer's application.”.
Given that you don’t actually know which of the anycast servers each of the 
border routers can reach (you just “assume” it is all of them) the ability of 
R0 to make a correct decision is compromised.

   Les

One point that I want to remind for your misunderstanding: the proposed 
Stub-link TLV can contain other attributes sub-TLVs of the link.
And, if the interfaces share the same prefixes, they are in the same IP subnet. 
Is there any ambiguously

Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Les Ginsberg (ginsberg)]

Aijun -

From: Aijun Wang 
Sent: Tuesday, January 16, 2024 10:56 PM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; Huzhibo ; Acee 
Lindem ; Yingzhen Qu ; 
lsr@ietf.org
Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

Hi, Les:

Let’s keep the discussions simple.

Please answer the following two questions that you haven’t responsed directly 
in previous mail:
1)How the existing point-to-point based solution(RFC9346/RFC5392) solve 
the broadcast(LAN, A.1 Figure2) inter-AS topology recovery scenario---There are 
multiple neighbors on one interfaces, which are located in different AS. How to 
encode the information within one inter-AS reachability TLV?

[LES:] In the absence of the existence of an advertisement of the LAN itself 
(the “pseudonode” in IS-IS), a LAN is represented as a set of P2P links between 
each of the nodes connected to the LAN.
Less scaleable but just as functional.

You, however, think you can get away with “If R1 advertises connectivity to the 
LAN subnet and R2 and R3 also advertise connectivity to the same subnet that we 
can assume that they are all connected” – which is an assumption that works 
some of the time – but is not guaranteed.
It is easy to imagine this case if there is a switch and one of the ports on 
the switch is faulty. (Other failure scenarios exist)


2)How the inter-AS based solutions solve the non inter-AS scenario 
requirements(A.2)?

[LES:] An interesting question given that you haven’t addressed this yourself.
What does it mean to advertise reachability to an anycast address (as you 
propose to do)?
Does that tell you if you are connected to one of anycast servers? Some of the 
anycast servers? All of the anycast servers?
You don’t know – you are just assuming.
But since your goal is “topology discovery” it is important to actually know 
whether you have a link to a particular anycast server or not.
You don’t know – you just assume.

One point that I want to remind for your misunderstanding: the proposed 
Stub-link TLV can contain other attributes sub-TLVs of the link.
And, if the interfaces share the same prefixes, they are in the same IP subnet. 
Is there any ambiguously for the IP topology recovery?

What I want to emphasize is that the existing solutions are suitable for 
inter-AS point-to-point TE, the proposed solutions are suitable(more 
efficient)for inter-AS topology recovery(p2p, p2mp and broadcast etc.) and also 
other non inter-as traffic optimization scenarios.  They are not contrary.

[LES:] AFAICT, your sole aim is efficiency – and you have given no thought to 
validating the actual topology.

Les


Aijun Wang
China Telecom


On Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

Aijun –

Please see inline.

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
'Christian Hopps' mailto:cho...@chopps.org>>; 'Huzhibo' 
mailto:huzh...@huawei.com>>
Cc: 'Acee Lindem' mailto:acee.i...@gmail.com>>; 'Yingzhen 
Qu' mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)


Hi, Les:



-邮件原件-
发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> 
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月16日 0:16
收件人: Christian Hopps mailto:cho...@chopps.org>>; Huzhibo 
mailto:huzhibo=40huawei@dmarc.ietf.org>>
抄送: Acee Lindem mailto:acee.i...@gmail.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)



I respect that individuals may have different opinions - but it is important to 
distinguish what is factual from what is not.

Opinions based upon false information are clearly compromised.



Please do heed Chris's (as WG chair) admonition to review the first WG adoption 
thread. That will reveal to you what the substantive objections were.



https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/

https://www.mail-archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0





Please also do examine the delta between the previous version which was put up 
for WG adoption (V3) and the current version (V8) so you can see what has 
changed.

https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--html



Some facts:



The substantive objections raised during the first adoption call had nothing to 
do with use cases - they had to do with:



a)The use of a prefix to identify a link between two nodes is a flawed 

Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Les Ginsberg (ginsberg)]

Aijun –

Please see inline.

From: Aijun Wang 
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps' 
; 'Huzhibo' 
Cc: 'Acee Lindem' ; 'Yingzhen Qu' 
; lsr@ietf.org
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)


Hi, Les:



-邮件原件-
发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> 
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月16日 0:16
收件人: Christian Hopps mailto:cho...@chopps.org>>; Huzhibo 
mailto:huzhibo=40huawei@dmarc.ietf.org>>
抄送: Acee Lindem mailto:acee.i...@gmail.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)



I respect that individuals may have different opinions - but it is important to 
distinguish what is factual from what is not.

Opinions based upon false information are clearly compromised.



Please do heed Chris's (as WG chair) admonition to review the first WG adoption 
thread. That will reveal to you what the substantive objections were.



https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/

https://www.mail-archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0





Please also do examine the delta between the previous version which was put up 
for WG adoption (V3) and the current version (V8) so you can see what has 
changed.

https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--html



Some facts:



The substantive objections raised during the first adoption call had nothing to 
do with use cases - they had to do with:



a)The use of a prefix to identify a link between two nodes is a flawed concept. 
It is not robust enough to be used in cases of unnumbered or Pt-2-MP.

[WAJ] Current encoding has covered the unnumbered scenario. For Pt-2-MP 
scenario, they share also the same subnet, please see our previous discussion 
at https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/



[LES:] I have no idea why you think the email you point to resolved the issue. 
It was an early email in a very long thread, the lack of support for unnumbered 
etc. continued to be discussed in subsequent emails by multiple participants 
and has been raised again by multiple participants in this second adoption call 
thread.

The minor changes you made to the encoding of Stub Link advertisement does 
nothing to resolve the issue.

The fundamental issue is that the same prefix can be associated with multiple 
links, so what you have defined is ambiguous in some cases.

Either you don’t understand this or don’t think this is important – I am not 
sure which – but many of us do believe this is important.



b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the 
potential use cases and do so more robustly than the Stub-link proposal.

[WAJ] If you make such claims, then please give the encoding example for A.1 
Figures 2(LAN scenario). How to configure/encode the several neighbors that 
located in different AS in one inter-AS reachability TLV?



[LES:] RFC 9346/RFC 5362 provide a robust way to uniquely identify inter-AS 
links, verify two-way connectivity, and optionally advertise additional link 
attributes if desired. (Apply this portion of the response to your other 
comments below.)

You apparently think this is too onerous and you propose a different mechanism 
that isn’t robust, does not allow two-way connectivity verification, and 
doesn’t support link attribute advertisement.

But because you see it as “simpler” you think you have sufficient justification 
to overlook its flaws.

I don’t agree.



The long-lived success of the IGPs has happened because we have worked 
diligently to provide robust solutions – not settle for solutions that only 
work some of the time.



   Les



The latest version of the draft makes no substantive changes to the stub link 
concept or its advertisement.

The only substantive change in the latest version is a reorganization of the 
presentation of use cases.

But lack of clarity in the use cases was not the basis on which first WG 
adoption call was rejected.



In this thread (the second WG adoption call),  the authors have asserted that 
they have addressed the concerns raised in the previous adoption call.

They have not. The concept and mechanism to identify a stub link has not 
changed.



In this thread the authors continue to assert that RFC 9346/RFC 5392 cannot 
address the use cases.

This is FALSE.

As has been pointed out repeatedly, the existing mechanisms provide a robust 
means to uniquely identify inter-AS links using endpoint identifiers - be they 
IPv4/IPv6 addresses or Link IDs.

[WAJ] And, please give the solution for 

Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Les Ginsberg (ginsberg)]

I respect that individuals may have different opinions - but it is important to 
distinguish what is factual from what is not.
Opinions based upon false information are clearly compromised.

Please do heed Chris's (as WG chair) admonition to review the first WG adoption 
thread. That will reveal to you what the substantive objections were.

https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/
https://www.mail-archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0


Please also do examine the delta between the previous version which was put up 
for WG adoption (V3) and the current version (V8) so you can see what has 
changed.
https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--html

Some facts:

The substantive objections raised during the first adoption call had nothing to 
do with use cases - they had to do with:

a)The use of a prefix to identify a link between two nodes is a flawed concept. 
It is not robust enough to be used in cases of unnumbered or Pt-2-MP.

b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the 
potential use cases and do so more robustly than the Stub-link proposal.

The latest version of the draft makes no substantive changes to the stub link 
concept or its advertisement.
The only substantive change in the latest version is a reorganization of the 
presentation of use cases.
But lack of clarity in the use cases was not the basis on which first WG 
adoption call was rejected.

In this thread (the second WG adoption call),  the authors have asserted that 
they have addressed the concerns raised in the previous adoption call.
They have not. The concept and mechanism to identify a stub link has not 
changed.

In this thread the authors continue to assert that RFC 9346/RFC 5392 cannot 
address the use cases.
This is FALSE.
As has been pointed out repeatedly, the existing mechanisms provide a robust 
means to uniquely identify inter-AS links using endpoint identifiers - be they 
IPv4/IPv6 addresses or Link IDs.
This addresses all cases - numbered and unnumbered.
There is therefore no need for a new mechanism.

No fact-based argument has been made to justify reconsideration of WG adoption.

I hope when people post their opinions, that they consider the facts.

  Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, January 10, 2024 2:17 AM
> To: Huzhibo 
> Cc: Acee Lindem ; Yingzhen Qu
> ; lsr@ietf.org
> Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
> (01/05/2024 - 01/19/2024)
> 
> [As WG Co-Chair]
> 
>   Hi Folks,
> 
>   Before posting support reasons please read and considerl
>   *all* the email in the archive covering the first failed
>   adoption call.
> 
> https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/
> https://www.mail-
> archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0
> 
>   This adoption call should be considering if the changes
>   made to the document since it failed to be adopted the
>   first time, are sufficient to reverse the WGs previous
>   decision.
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Les Ginsberg (ginsberg)]

Chongfeng –

We are at the stage of last call.
The document has been presented and discussed previously – it is time for WG 
members to render their opinions.

For folks who have actively followed/participated in the discussion, it is very 
unlikely that we will alter opinions by further discussion. Which means if you 
and I have different points of view it is very unlikely that I will alter your 
opinion and very unlikely that you will alter mine.
In that context, I typically do not reply when someone posts their opinion and 
it is different than mine. The point of last call is to get the opinions of WG 
members.

In this case, however, I will respond with some clarifications – not in the 
hopes of changing your mind – but only to provide additional clarity as to why 
I have the opinion that I do.

The use of MT in support of NRP – at whatever scale – clearly requires 
additional SPF calculations – which is something which is expressly identified 
as undesirable in draft-ietf-teas-nrp-scalability.
draft-ietf-teas-nrp-scalability also states (as you have pointed out) that 
“control plane extensions” are seen as undesirable.

Having implemented the use of MT for purposes other than supporting the 
reserved AFI/SAFI specific topologies specified in RFC 5120, I can tell you 
that there is a significant amount of “control plane work” associated with 
adding such support. The fact that no new protocol extensions are required is 
not the same as saying no new control plane work is required. I can assure you 
that there would be a significant amount of control plane work required.

So I do see that draft-ietf-lsr-isis-sr-vtn-mt is at odds with 
draft-ietf-teas-nrp-scalability.

Thanx for listening.

Les


From: Lsr  On Behalf Of Chongfeng Xie
Sent: Wednesday, January 10, 2024 7:41 PM
To: Les Ginsberg (ginsberg) ; jmh 
; Acee Lindem ; TEAS WG 
; lsr 
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06


Hi Les,

Thanks for your comments.

This is an informational document which describes the applicability of existing 
IS-IS MT mechanisms for building SR based NRPs. All the normative references 
are either RFCs or stable WG documents. It is true that some informative 
references are individual documents, while they just provide additional 
information related to this topic, thus would not impact the stability and 
maturity of the proposed mechanism.

The text you quoted from draft-ietf-teas-nrp-scalability are about the 
considerations when the number of NRP increases, how to minimize the impact to 
the routing protocols (e.g. IGP). While as described in the scalability 
considerations section of this document, the benefit and limitation of using 
this mechanism for NRP are analyzed, and it also sets the target scenarios of 
this mechanism:

 “The mechanism described in this document is considered useful for network 
scenarios in which the required number of NRP is small”

Thus it is clear that this solution is not recommended for network scenarios 
where the number of required NRP is large.

Please note section 3 of draft-ietf-teas-nrp-scalability also mentioned that:

  “The result of this is that different operators can choose to deploy 
things at different scales.”

And

  “In particular, we should be open to the use of approaches that do not 
require control plane extensions and that can be applied to deployments with 
limited scope.”

 According to the above text, we believe the mechanism described in this 
document complies to the design principles discussed in 
draft-ietf-teas-nrp-scalability and provides a valid solution for building NRPs 
in a limited scope.

 Hope this solves your concerns about the maturity and scalability of this 
mechanism.

 Best regards,

Chongfeng


From: Les Ginsberg \(ginsberg\)<mailto:ginsberg=40cisco@dmarc.ietf.org>
Date: 2024-01-11 08:21
To: Joel Halpern<mailto:j...@joelhalpern.com>; Acee 
Lindem<mailto:acee.i...@gmail.com>; t...@ietf.org<mailto:t...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
(NOTE: I am replying to Joel’s post rather than the original last call email 
because I share some of Joel’s concerns – though my opinion on the merits of 
the draft is very different.
Also, I want to be sure the TEAS WG gets to see this email.)

I oppose Last Call for draft-ietf-lsr-isis-sr-vtn-mt.

It is certainly true, as Joel points out, that this draft references many 
drafts which are not yet RFCs – and in some cases are not even WG documents. 
Therefore, it is definitely premature to last call this draft.

I also want to point out that the direction TEAS WG has moved

Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Les Ginsberg (ginsberg)]

(NOTE: I am replying to Joel’s post rather than the original last call email 
because I share some of Joel’s concerns – though my opinion on the merits of 
the draft is very different.
Also, I want to be sure the TEAS WG gets to see this email.)

I oppose Last Call for draft-ietf-lsr-isis-sr-vtn-mt.

It is certainly true, as Joel points out, that this draft references many 
drafts which are not yet RFCs – and in some cases are not even WG documents. 
Therefore, it is definitely premature to last call this draft.

I also want to point out that the direction TEAS WG has moved to recommends 
that routing protocols NOT be used as a means of supporting NRP.

https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl
 states:

“…it is desirable for NRPs to have no more than small impact (zero being 
preferred) on the IGP information that is propagated today, and to not required 
additional SPF computations beyond those that are already required.”

https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl
 states:

“The routing protocols (IGP or BGP) do not need to be involved in any of these 
points, and it is important to isolate them from these aspects in order that 
there is no impact on scaling or stability.”

Another draft which is referenced is 
https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ - which is not 
a WG document and – based on the recommendations in 
draft-ietf-teas-nrp-scalability – I would argue that the IGPs should NOT be 
extended as proposed in this draft. So if a WG adoption call were to initiated 
for draft-dong-lsr-sr-enhanced-vpn, I would oppose it.

This then puts draft-ietf-lsr-isis-sr-vtn-mt in the position of publishing 
information about a solution which the IETF is discouraging. I do not know why 
the IETF would want to do this.

If, despite all of the above, at some point it is judged not premature to 
publish this draft, I think the draft should at least include statements 
indicating that this approach is not a recommended deployment solution.

   Les


From: Lsr  On Behalf Of Joel Halpern
Sent: Wednesday, January 10, 2024 3:22 PM
To: Acee Lindem ; t...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06


Given that the documents that provide the basic definitions needed for this are 
still active Internet Drafts, it seems premature to last call this document.

As a lesser matter, it seems odd that draft-ietf-teas-ietf-network-slices, 
which defines the terms needed to understand this draft, is an Informative 
reference.

Yours,

Joel

PS: I considered not writing this email, as it seems quite reasonable to use MT 
to support what I expect NRPs to be.  So in principle I think the document is a 
good idea.
On 1/10/2024 6:12 PM, Acee Lindem wrote:
Note that we are last calling this informational document relating to IS-IS 
deployment of NRPs using multi-topology. If you have comments, please send them 
to the LSR list.

Thanks,
Acee


Begin forwarded message:

From: Acee Lindem 
Subject: Working Group Last Call for "Applicability of IS-IS Multi-Topology 
(MT) for Segment Routing based Network Resource Partition (NRP)" - 
draft-ietf-lsr-isis-sr-vtn-mt-06
Date: January 8, 2024 at 5:50:21 PM EST
To: Lsr 

This begins a two week LSR Working Group last call for the “Applicability of 
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition 
(NRP)”. Please express your support or objection prior to Tuesday, January 
23rd, 2024.

Thanks,
Acee




___

Teas mailing list

t...@ietf.org

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

Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Les Ginsberg (ginsberg)]

I oppose WG adoption.

The reasons that I opposed adoption the first time remain valid:

1)The use of a prefix to represent a link is a flawed concept

2) RFC 9346 (previously RFC 5316) and RFC 5392 (as well as BGP-LS) are 
available to address the use cases.

The updated draft does nothing to address these points.

I would be less than candid if I did not also say that the second adoption call 
is a waste of WG time.
I respect the fact that the draft authors may disagree with the conclusions of 
the WG – but that does not mean they have a right to ignore WG consensus.

Let’s please move on.

   Les


From: Lsr  On Behalf Of Yingzhen Qu
Sent: Friday, January 5, 2024 4:23 PM
To: lsr ; lsr-chairs 
Subject: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

Hi,


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



https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/



Please indicate your support or objections by January 19th, 2024.



Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.
*** Please note that this is the second WG adoption poll of the draft. The 
first one was tried two years ago and you can see the discussions in the 
archive:
[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 
(ietf.org)


Thanks,

Yingzhen


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

Re: [Lsr] RFC8665

[Les Ginsberg (ginsberg)]

Tom -

At some point the WG chairs might want to respond, but the simple answer to 
this "mystery" has to do with when a document became an RFC.

LSR WG was formed in early 2018. It took over the work that was previously done 
by the OSPF WG (https://datatracker.ietf.org/wg/ospf/documents/ ) and the IS-IS 
WG (https://datatracker.ietf.org/wg/isis/documents/ ).

If a document became an RFC after the LSR WG took over, then it is listed on 
LSR page - if the document became an RFC before then it is listed either on the 
OSPF page or the IS-IS page.
If you look at those pages you will see that each WG produced a large number of 
documents - not sure if it would make sense to move/copy all of that to the LSR 
page.
I will let the WG chairs comment on that.

For myself, if I want to find an RFC, I simply put "RFC" into my favorite 
search tool and it is quickly found.

   Les


> -Original Message-
> From: tom petch 
> Sent: Wednesday, December 13, 2023 9:34 AM
> To: Les Ginsberg (ginsberg) ; lsr-cha...@ietf.org
> Cc: lsr@ietf.org
> Subject: Re: RFC8665
> 
> From: Les Ginsberg (ginsberg) 
> Sent: 11 December 2023 16:42
> 
> https://datatracker.ietf.org/doc/rfc8665/
> 
> And there is a link to it here: 
> https://datatracker.ietf.org/wg/ospf/documents/
> 
> Not sure why you are having issues.
> 
> 
> 
> Because the link is missing, missing from where it would be most useful, in 
> the
> page for the LSR WG, the part that lists the  RFC, the part that, inter alia, 
> lists
> RFC8666 and RFC8667.
> I have come to rely on the page for the WG to link to most of the documents I
> need to reference to review eg ospf-sr-yang.
> 
> And it is not there.
> 
> Yes there are other links to it on other pages which just consumes more of my
> time to find.
> 
> I am thinking that the metadata may be wrong and there will be other
> problems  but as yet have no evidence thereof.
> 
> Tom Petch
> 
> 
> 
>Les
> 
> > -Original Message-
> > From: Lsr  On Behalf Of tom petch
> > Sent: Monday, December 11, 2023 4:02 AM
> > To: lsr-cha...@ietf.org
> > Cc: lsr@ietf.org
> > Subject: [Lsr] RFC8665
> >
> > I look in vain in the datatracker for RFC8665.
> >
> > Document search finds it, the data tracker does not list it.
> >
> > I realise that it is not a product of the lsr WG but then neither are 
> > RFC9129 or
> > RFC8920 AFAICTand they are listed.
> >
> > Odd; well, irritating to be precise.
> >
> > Tom Petch
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] RFC8665

[Les Ginsberg (ginsberg)]

Tom -

https://datatracker.ietf.org/doc/rfc8665/

And there is a link to it here: https://datatracker.ietf.org/wg/ospf/documents/

Not sure why you are having issues.

   Les

> -Original Message-
> From: Lsr  On Behalf Of tom petch
> Sent: Monday, December 11, 2023 4:02 AM
> To: lsr-cha...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] RFC8665
> 
> I look in vain in the datatracker for RFC8665.
> 
> Document search finds it, the data tracker does not list it.
> 
> I realise that it is not a product of the lsr WG but then neither are RFC9129 
> or
> RFC8920 AFAICTand they are listed.
> 
> Odd; well, irritating to be precise.
> 
> Tom Petch
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

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

[Les Ginsberg (ginsberg)]

Huaimo -

We are not making progress here - and I doubt that any additional posts from me 
will help - so I am not going to respond further.

I only want to point out that there is no difference between Parag and myself 
as regards the meaning of  "backwards compatibility".
The fact that you think there is a difference is a clear indication that you 
have not correctly understood what we have said. If I thought that I could help 
by presenting things in a different way I would give it a try - but I have 
already tried multiple times.

You will either take the above input as a reason to reread the thread and try 
to figure out why you have incorrectly concluded that Parag and I are not in 
agreement - or you won't. That is totally your decision.

   Les

From: Huaimo Chen 
Sent: Saturday, December 9, 2023 6:06 AM
To: Parag Kaneriya ; Les Ginsberg (ginsberg) 
; li_zhenqi...@hotmail.com; Tony Li ; 
Linda Dunbar 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

>Legacy node gets half information result in the inconsistent view of network 
>(for example TED
>[traffic engineering database] inconsistency lead to many network related 
>issue.)
>hence legacy node getting half information is not backward consistent.

>From your statement, your definition of backwards compatibility/consistency 
>means that protocol extensions can be advertised, and legacy node gets all the 
>information (i.e., legacy node understands the new advertisements).

This seems uncommon. No protocol extension (with a new advertisement) is 
backwards compatible according to your definition. Your definition seems not 
consistent with Les'.

Best Regards,
Huaimo

From: Parag Kaneriya mailto:pkane...@juniper.net>>
Sent: Friday, December 8, 2023 11:29 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Legacy node gets half information result in the inconsistent view of network 
(for example TED [traffic engineering database] inconsistency lead to many 
network related issue.) hence  legacy node getting half information is not 
backward consistent.




Juniper Business Use Only
From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Friday, December 8, 2023 7:23 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

[External Email. Be cautious of content]

Hi Les,

Your definition of backwards compatibility means that protocol extensions 
can be advertised and safely used in the presence of legacy nodes (which do not 
understand the new advertisements).

Protocol extensions for Big-TLV include a new TLV (called container TLV) and a 
new Sub-TLV (called Big-TLV Capability Sub-TLV).  Big-TLV is also short for 
Protocol extensions for Big-TLV.
When adding a piece of new information into an existing TLV makes the TLV > 
255, this new information can be put into a container TLV. The container TLV 
can be advertised in a network. The old/legacy nodes (i.e., the nodes not 
supporting Big-TLV) ignore the container TLV, which contains the new 
information. The new nodes (i.e., the nodes supporting Big-TLV) obtain the new 
information.
Each of the new nodes advertises a Big-TLV Capability Sub-TLV, indicating the 
capability of Big-TLV. The old/legacy nodes ignore it. The new nodes get it.
If it is not required that all the nodes must have the same new information for 
using the new information, the new nodes can use the new information, the 
old/legacy nodes ignore the new information.
If all the nodes need to have the same new information for using the new 
information, every node needs to check if all the nodes support the Big-TLV. If 
all the nodes support it, every node uses the new information.

>From the above, we can see that "the protocol extensions (: container TLV and 
>Big-TLV capability Sub-TLV, which is protocol extensions for Big-TLV) can be 
>advertised and safely used in the presence of legacy no

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

[Les Ginsberg (ginsberg)]

Huaimo -

You don't provide an operational definition of how to determine whether "all 
nodes need to have the same new information", but it is easy to come up with 
cases where this is needed.
Parag described one below and I have previously described one related to Flex 
Algo.

I have yet to see you (or anyone else) present an example where "only the new 
nodes" need to use the additional information. But even if such examples exist, 
the logic required to determine this would be expensive and difficult to define 
in a robust way. And the state could change dynamically as sub-TLVs are 
added/removed.
Deploying something that at best works some of the time is certain to lead to 
big problems.
Our responsibility is to define robust solutions.

   Les

From: Parag Kaneriya 
Sent: Friday, December 8, 2023 8:29 AM
To: Huaimo Chen ; Les Ginsberg (ginsberg) 
; li_zhenqi...@hotmail.com; Tony Li ; 
Linda Dunbar 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Legacy node gets half information result in the inconsistent view of network 
(for example TED [traffic engineering database] inconsistency lead to many 
network related issue.) hence  legacy node getting half information is not 
backward consistent.




Juniper Business Use Only
From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Friday, December 8, 2023 7:23 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

[External Email. Be cautious of content]

Hi Les,

Your definition of backwards compatibility means that protocol extensions 
can be advertised and safely used in the presence of legacy nodes (which do not 
understand the new advertisements).

Protocol extensions for Big-TLV include a new TLV (called container TLV) and a 
new Sub-TLV (called Big-TLV Capability Sub-TLV).  Big-TLV is also short for 
Protocol extensions for Big-TLV.
When adding a piece of new information into an existing TLV makes the TLV > 
255, this new information can be put into a container TLV. The container TLV 
can be advertised in a network. The old/legacy nodes (i.e., the nodes not 
supporting Big-TLV) ignore the container TLV, which contains the new 
information. The new nodes (i.e., the nodes supporting Big-TLV) obtain the new 
information.
Each of the new nodes advertises a Big-TLV Capability Sub-TLV, indicating the 
capability of Big-TLV. The old/legacy nodes ignore it. The new nodes get it.
If it is not required that all the nodes must have the same new information for 
using the new information, the new nodes can use the new information, the 
old/legacy nodes ignore the new information.
If all the nodes need to have the same new information for using the new 
information, every node needs to check if all the nodes support the Big-TLV. If 
all the nodes support it, every node uses the new information.

>From the above, we can see that "the protocol extensions (: container TLV and 
>Big-TLV capability Sub-TLV, which is protocol extensions for Big-TLV) can be 
>advertised and safely used in the presence of legacy nodes (which do not 
>understand the new advertisements)". The quoted is your definition of 
>backwards compatibility. So, the Big-TLV is backwards compatible.

Best Regards,
Huaimo
From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Thursday, December 7, 2023 1:07 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Huaimo -

There are some things on which people can legitimately have different opinions 
- the meaning of backwards compatibility is not one of them.

Your position seems to be that so long as I introduce a capability 
advertisement that controls whether a new advertisement is used when received 
that I can declare it "backwards compatible". By that definition everything is 
"backwards compatible".
This makes the term "backwards compatibility" meaningless.

This POV is neither useful nor sensible.

   Les


From: Huaimo C

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

[Les Ginsberg (ginsberg)]

Huaimo –

THis discussion seems to be getting less and less meaningful – but I will 
respond.

Regarding IID-TLV, thanx for pointing out that this is another case where the 
use of MP has been explicitly stated. 😊

Regarding RFC 5311 and TLV 22/23, the reason that TLV 23 was defined is because 
there are restrictions on the use of TLV 22 in the “Extended LSPs” introduced 
in RFC 5311.
This has nothing whatsoever to do with MP or Big-TLV – it really isn’t relevant 
at all. Your introduction of it into this discussion isn’t helpful.

Perhaps you don’t fully understand RFC 5311 – for which I would not blame you.
The RFC is a somewhat arcane attempt to extend the 256 LSP limit in the 
protocol. IT never became popular – somewhat understandably – and I doubt that 
most people are familiar with it.
Trying to use it to clarify/justify anything in the MP/Big-TLV discussion is 
not appropriate.

   Les

From: Huaimo Chen 
Sent: Friday, December 8, 2023 5:46 AM
To: Tony Przygienda 
Cc: Les Ginsberg (ginsberg) ; 
li_zhenqi...@hotmail.com; Tony Li ; Linda Dunbar 
; Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)

Hi Tony,

Thank you for your reply.
My responses are inline below with [HC2].

Best Regards,
Huaimo

Huaimo, first, I fail to see how 8202 has anything to do with this discussion.
[HC2]: RFC 8202 defines Instance Identifier TLV (IID-TLV for short), which has 
TLV type 7. When IID-TLV > 255 (i.e., its value > 255), RFC 8202 specifies a 
way or approach to encode/decode it (IID-TLV > 255). So, it is related to this 
discussion.

Did you try to implement and deploy 5311 in real networks and seen the 
operational impact ? and are you suggesting that we need to have that deployed 
as precondition for big-tlv idea ?
[HC2]: No. RFC 5311 is not a precondition for Big-TLV.


'nuff said ...

-- tony

On Thu, Dec 7, 2023 at 3:12 PM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:
Hi Tony,

My responses are inline below with [HC].

Best Regards,
Huaimo

practically speaking "backwards compatibility" here is restricted by the fact 
that

1) we have in most largest networks de facto mp-tlv deployed and relied on for 
operations implemented by all major vendors.
2) we cannot encode mp-tlv deployed in parallel with "something new that we 
flip over once e'one has it" since the encoding space is limited and there are 
deployments that consume on some node so many fragments re-encoding twice until 
cut over would immediately break those networks

[HC]: We have encoded TLVs > 255 in two different ways (or say, deployed in 
parallel) already.
RFC 8202 specifies one way for IID-TLV (TLV 7) > 255 on page 4-6 (quoted some 
text below for your convenience).
  “A single IID-TLV will support advertisement of up to 126 ITIDs.  If
   multiple IID-TLVs are present in an IIH PDU, the supported set of
   ITIDs is the union of all ITIDs present in all IID-TLVs.”
RFC5311 defines another way for extended IS reachability TLV 22 and MT-ISN TLV 
222 > 255, in which two new TLVs: IS Neighbor Attribute TLV 23 and MT IS 
Neighbor Attribute TLV 223, are defined. Some texts from RFC 5311 are quoted 
below for your convenience.

  “If the attribute information does not conflict, it MUST be

   considered additive.”

  “In cases where information about the same neighbor/link/attribute

   appears in both TLV 22 and TLV 23 (or TLV 222 and TLV 223 for the

   same MTID) then the information in TLV 22 (or TLV 222) MUST be used

   and the information in TLV 23 (or TLV 223) MUST be ignored.”

  “Utilization of the new TLVs for neighbor attribute information would

   provide additional benefits that include:

   Easier support for a set of TE information associated with a single

   link that exceeds the 255-byte TLV limit by allowing the

   interpretation of multiple TLVs to be considered additive rather

   than mutually exclusive.”

These two different ways do not affect each other. There is no flip over.

A new way for TLVs > 255 will not affect any existing way. There will not be 
any flip over.


Corollary I: a flag day on such networks is NOT possible unless it's seamlessly 
flipping to something new while disabling old

[HC]: Corollary 1 seems not valid since the Theorem on which Corollary 1 based 
is not valid. The Theorem is 1) and 2) above. The Theorem is not valid (or 
true) since 2) is false.

Collorary II: no matter how many times something that does not meet those 2 
criteria is suggested is repeated ad nauseam it will not make it practically 
relevant or feasible.

[HC]: Corollary 2 seems not valid since the Theorem on which Corollary 2 based 
is not valid.

what we need is documentation to the extent possible of existing mp-tlv and 
framework for new tlv/sub-tlv/sub.. to describe intended behavior in case of 
mp-tlv of those. All in distributed fashion without ga

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

[Les Ginsberg (ginsberg)]

 Gyan>
   If we made the sending of MP TLV a MUST it would provide the similar type of 
backwards compatibility as BIG TLV with the capability TLV.  

Advantage of doing it inside the protocol is that we eliminate configuration of 
enable/disable state default variations and are able to ensue backwards 
compatibility.  So it’s similar but not the same.  I guess MP TLV could 
introduce a similar capability TLV for backwards compatibility and then the 
backwards compatibility would  be identical.
   
[LES:] You are very confused - and your post is doing nothing but obfuscating 
the thread.
If you wish to understand why please take it offline with me.

   Les


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

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

[Les Ginsberg (ginsberg)]

John -

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

Seems reasonable to me.
 
> 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.
>

Thanx for the prompt attention.

Les

> -Original Message-
> From: John Scudder 
> Sent: Thursday, December 7, 2023 1:13 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Acee Lindem ; Hannes Gredler
> ; stefano.prev...@gmail.com; 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; lsr 
> Subject: Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
> 
> 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

[Les Ginsberg (ginsberg)]

Folks -



Let's be careful here.

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



Thanx.



   Les





> -Original Message-

> From: Acee Lindem 

> Sent: Thursday, December 7, 2023 12:44 PM

> To: John Scudder 

> Cc: Hannes Gredler ;

> 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; lsr 

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

>

> Hi John,

>

> > On Dec 7, 2023, at 12:22, John Scudder 
> > mailto:jgs=40juniper@dmarc.ietf.org>>

> wrote:

> >

> > Hi Hannes,

> >

> >> On Dec 7, 2023, at 4:38 AM, Hannes Gredler

> mailto:hannes=40gredler...@dmarc.ietf.org>>
>  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.

>

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

>

> Thanks,

> Acee

>

>

> >

> > 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-<http://hitchhikerguidetothegalaxy.blogspot.com/2006/04/beware-of-leopard-douglas-adams-quote.html>

> of-leopard-douglas-adams-quote.html<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<mailto:Lsr@ietf.org>

> > https://www.ietf.org/mailman/listinfo/lsr


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

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

[Les Ginsberg (ginsberg)]

Huaimo –

There are some things on which people can legitimately have different opinions 
– the meaning of backwards compatibility is not one of them.

Your position seems to be that so long as I introduce a capability 
advertisement that controls whether a new advertisement is used when received 
that I can declare it “backwards compatible”. By that definition everything is 
“backwards compatible”.
This makes the term “backwards compatibility” meaningless.

This POV is neither useful nor sensible.

   Les


From: Huaimo Chen 
Sent: Thursday, December 7, 2023 6:07 AM
To: Les Ginsberg (ginsberg) ; li_zhenqi...@hotmail.com; 
Tony Li ; Linda Dunbar 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Hi Les,

My responses are inline below with [HC].

Best Regards,
Huaimo

Folks –

The term “backwards compatibility” is getting abused here.

What does “backwards compatibility” mean in the context of a routing protocol 
like IS-IS?

It means that protocol extensions can be advertised and safely used in the 
presence of legacy nodes (which do not understand the new advertisements).

Neither MP nor Big-TLV are backwards compatible.
[HC]: Big-TLV is backwards compatible according to your definition of 
“backwards compatibility”.

The authors of MP draft do not claim it is backwards compatible.

The authors of Big-TLV claim it is “backwards compatible” – but this is a false 
statement. Any attempt to use Big-TLV advertisements in the presence of legacy 
nodes will result in inconsistent and potentially dangerous behavior.
[HC]: Using Big-TLV advertisements in the presence of legacy nodes will not 
result in any inconsistent or potentially dangerous behavior. I have explained 
this in detail in the LSR mailing list.

Big-TLV authors like to say “you can send Big-TLV but not use it until all 
nodes support it” – but this does meet the criteria for backwards 
compatibility. If Big-TLV were “backwards compatible” there would be no need 
for a capability advertisement to determine when it is safe to use the 
advertisements.
[HC]: Big-TLV capability advertisement is a part of the Big-TLV 
solution/extension.
Capability advertisements seem used for backwards compatibility by other 
protocols.  Is there any restriction in IS-IS that does not allow any IS-IS 
extension to use a capability advertisement for backwards compatibility?
Using a capability for Big-TLV backwards compatibility is suggested by Chris in 
the LSR mailing list.
https://mailarchive.ietf.org/arch/msg/lsr/cXyGnSJSdEQR9BVxykXhiuUWtgE/

   Les



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, December 5, 2023 2:11 AM
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Huaimo Chen 
mailto:huaimo.c...@futurewei.com>>; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Folks –

The term “backwards compatibility” is getting abused here.

What does “backwards compatibility” mean in the context of a routing protocol 
like IS-IS?

It means that protocol extensions can be advertised and safely used in the 
presence of legacy nodes (which do not understand the new advertisements).

Neither MP nor Big-TLV are backwards compatible.

The authors of MP draft do not claim it is backwards compatible.

The authors of Big-TLV claim it is “backwards compatible” – but this is a false 
statement. Any attempt to use Big-TLV advertisements in the presence of legacy 
nodes will result in inconsistent and potentially dangerous behavior.
Big-TLV authors like to say “you can send Big-TLV but not use it until all 
nodes support it” – but this does meet the criteria for backwards 
compatibility. If Big-TLV were “backwards compatible” there would be no need 
for a capability advertisement to determine when it is safe to use the 
advertisements.

   Les

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
mailto:li_zhenqi...@hotmail.com>>
Sent: Monday, December 4, 2023 10:35 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: Re: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Hello All,

It seems Big-TLV is backward compatible. Backward compatible is an important 
point that should be co

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

[Les Ginsberg (ginsberg)]

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

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

[Les Ginsberg (ginsberg)]

Folks –

The term “backwards compatibility” is getting abused here.

What does “backwards compatibility” mean in the context of a routing protocol 
like IS-IS?

It means that protocol extensions can be advertised and safely used in the 
presence of legacy nodes (which do not understand the new advertisements).

Neither MP nor Big-TLV are backwards compatible.

The authors of MP draft do not claim it is backwards compatible.

The authors of Big-TLV claim it is “backwards compatible” – but this is a false 
statement. Any attempt to use Big-TLV advertisements in the presence of legacy 
nodes will result in inconsistent and potentially dangerous behavior.
Big-TLV authors like to say “you can send Big-TLV but not use it until all 
nodes support it” – but this does meet the criteria for backwards 
compatibility. If Big-TLV were “backwards compatible” there would be no need 
for a capability advertisement to determine when it is safe to use the 
advertisements.

   Les

From: li_zhenqi...@hotmail.com 
Sent: Monday, December 4, 2023 10:35 PM
To: Huaimo Chen ; Les Ginsberg (ginsberg) 
; Tony Li ; Linda Dunbar 

Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: Re: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Hello All,

It seems Big-TLV is backward compatible. Backward compatible is an important 
point that should be considered when we introduce new features in a protocol, 
especially the widely used protocols like ISIS, BGP etc.


Best Regards,
Zhenqiang Li
China Mobile
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Huaimo Chen<mailto:huaimo.c...@futurewei.com>
Date: 2023-12-04 21:57
To: Les Ginsberg (ginsberg)<mailto:ginsberg=40cisco@dmarc.ietf.org>; Tony 
Li<mailto:tony...@tony.li>; Linda Dunbar<mailto:linda.dun...@futurewei.com>
CC: Yingzhen Qu<mailto:yingzhen.i...@gmail.com>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr<mailto:lsr@ietf.org>
Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)
Hi Les,

My responses are inline below with [HC].

Best Regards,
Huaimo

Linda –

When we have polarized positions (for whatever reasons), coming to consensus is 
often difficult. Each side tends to dismiss the arguments of the other – 
sometimes regardless of merit.
So, maybe the following won’t help – but I am going to give it a try.

Point #1: There are existing TLVs for which MP behavior was explicitly stated 
in existing RFCs and there are already many deployments that conform to those 
RFCs (see Introduction of MP draft for a list).
If we choose to use a different encoding to support > 255 bytes for other 
codepoints, this both complicates implementations and confuses the definition 
of new protocol extensions. When defining a new codepoint should I choose MP or 
should I choose a different encoding? And what criteria can be used to make 
this choice a sensible one?
And since MP is already REQUIRED for those TLVs where it was explicitly 
defined, we will always have to support that – at least for some codepoints.
[HC]: When Big-TLV is used for a TLV > 255, it does not affect the existing 
MP-TLV that has been used for another TLV > 255.  When defining a new codepoint 
for a new TLV, it seems better to choose Big-TLV if backward compatibility is 
needed for the new TLV since Big-TLV is backward compatible.
I have explained it (i.e. ,“Big-TLV is backward compatible”) in detail. In 
addition, some other people indicate it in the LSR mailing list.


Point #2: MP for IS-Neighbor/Prefix Reachability TLVs has already been 
implemented by multiple vendors, tested in both partial deployment and full 
deployment scenarios. We know that it works and we know what the problems are 
in partial deployment.
This cannot be said for new alternatives.
With due respect to Huaimo, he tends to characterize the implementation 
problems to be solved for Big-TLV as “easy to resolve” but given the absence of 
implementation I think this is an overly optimistic and somewhat naïve POV. (No 
offense intended)
[HC]: It seems that the implementation of an idea/solution in a draft is not 
required by LSR WG for the draft to be adopted, or even for the draft to become 
RFC.

Point #3: As documented in the IANA section of the MP draft, the problem 
extends to sub-TLVs of top level TLVs as well. It is then not as simple as 
reserving one encap TLV to handle the top-level TLV case. We also have to have 
a solution when a sub-TLV requires more than 255 bytes. MP solves this without 
additional changes. Big-TLV has yet to discuss this.
[HC]: It seems that MP-TLV has to discuss this.
Assume: a TLV (e.g., TLV 1) > 255 and its sub-TLV > 255, there are MP-TLVs 
(e.g., MP-TLV 1 and MP-TLV 2) for the TLV and MP-TLVs (e.g., MP-TLV 3 and 
MP-TLV 4) for the sub-TLV. All these MP-TLVs are TLVs. If 

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

[Les Ginsberg (ginsberg)]

Linda –

When we have polarized positions (for whatever reasons), coming to consensus is 
often difficult. Each side tends to dismiss the arguments of the other – 
sometimes regardless of merit.
So, maybe the following won’t help – but I am going to give it a try.

Point #1: There are existing TLVs for which MP behavior was explicitly stated 
in existing RFCs and there are already many deployments that conform to those 
RFCs (see Introduction of MP draft for a list).
If we choose to use a different encoding to support > 255 bytes for other 
codepoints, this both complicates implementations and confuses the definition 
of new protocol extensions. When defining a new codepoint should I choose MP or 
should I choose a different encoding? And what criteria can be used to make 
this choice a sensible one?
And since MP is already REQUIRED for those TLVs where it was explicitly 
defined, we will always have to support that – at least for some codepoints.

Point #2: MP for IS-Neighbor/Prefix Reachability TLVs has already been 
implemented by multiple vendors, tested in both partial deployment and full 
deployment scenarios. We know that it works and we know what the problems are 
in partial deployment.
This cannot be said for new alternatives.
With due respect to Huaimo, he tends to characterize the implementation 
problems to be solved for Big-TLV as “easy to resolve” but given the absence of 
implementation I think this is an overly optimistic and somewhat naïve POV. (No 
offense intended)

Point #3: As documented in the IANA section of the MP draft, the problem 
extends to sub-TLVs of top level TLVs as well. It is then not as simple as 
reserving one encap TLV to handle the top-level TLV case. We also have to have 
a solution when a sub-TLV requires more than 255 bytes. MP solves this without 
additional changes. Big-TLV has yet to discuss this.

If Big-TLV actually solved the partial deployment case, we would have a 
motivation to look at it more seriously. But it does not. It has the same issue 
with partial deployment that MP does. So for me, there is no value add to 
Big-TLV – and it does require additional implementation work – not all of which 
has even been defined yet.
It isn’t better – it is just different – and comes with additional 
implementation costs.

   Les


From: Tony Li  On Behalf Of Tony Li
Sent: Friday, December 1, 2023 2:44 PM
To: Linda Dunbar 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)


Hi Linda,




  *   Suppose the information to be carried by the  Extended IS Reachability 
(type 22) (in Example 4.1) is larger than 255. Does it mean the recipient will 
receive 2 TLVs (both with the Type 22) in one LSA? For legacy routers, the 
second TLV (Type =22) might overwrite  the first TLV.


Yes, a legacy implementation may well have bugs. The proposal is to fix that: 
expect MP-TLVs.

[Linda] Are you saying only the legacy implementation with bugs will be 
confused with two TLVs with the same Type  in in one LSA?


No. All implementations have bugs. This is reality.

Implementations that do not understand MP-TLV may be confused. Correct 
implementations of MP-TLV support will not be confused.



  *   Isn’t it more straightforward to have a new TYPE value for carrying the 
extra information beyond the 255 bytes? So, the legacy routers can ignore the 
TLVs with the unrecognized types.


You could do that, but code points are not free.  We certainly cannot afford 
another code point for each existing code point.  Using just one code point is 
less than helpful: it forces us to aggregate information that has no business 
being aggregated. Ignoring information is a non-starter because it makes 
partial deployments fatal: some of the domain operates with some information 
and some of the domain operates with different information.
[Linda] Why not consider having just one additional TYPE code with sub-types to 
indicate which original TLVs the value should be appended to?


We have considered it.  See all of Les’ emails for why it’s a bad idea.

If it helps simplify this debate: we know that you work for Futurewei/Huawei 
and that the discussion has polarized into your Big-TLV faction vs. everyone 
else. Repetition of previously made points add zero value to the discussion.

Tony

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

Re: [Lsr] IETF 118 LSR Minutes

[Les Ginsberg (ginsberg)]

Dhruv –

Thanx for finding this and updating the IETF case – I had looked and indeed saw 
the issue in the minutes of other WGs.
Also thanx to Yingzhen for uploading the chat history – you can now see a more 
readable format in the LSR Minutes.

   Les

From: Dhruv Dhody 
Sent: Monday, November 27, 2023 11:24 PM
To: Acee Lindem 
Cc: Les Ginsberg (ginsberg) ; Yingzhen Qu 
; lsr ; lsr-chairs 
Subject: Re: [Lsr] IETF 118 LSR Minutes

Hi Acee/Les,

Seems to be a known issue, See 
https://github.com/ietf-tools/datatracker/issues/5952

Perhaps we can comment there asking the tools team to prioritize its resolution!

Thanks!
Dhruv

On Mon, Nov 27, 2023 at 5:18 AM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Les -
The LSR WG list is no place to vent on this topic. Open a ticket via 
supp...@ietf.org<mailto:supp...@ietf.org>. Also, this would be a good issue to 
raise in your IETF 118 survey response.
Acee


On Nov 26, 2023, at 18:29, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

FWIW –

The new format for the chatlog is much less readable than previous.

Here is the format from IETF 116:



Ketan Talaulikar
00:39:39
There is a WG draft for per-algo adj-sid :
https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/

If we have large number of links, we are advertising many other
attributes per link - so I am also missing the point of
"compressing" only the adj-sid advertisement.
* Weiqiang Cheng
00:41:58
The similar solution for SRv6 is on the link:
https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/
…


Here is the format from IETF 118:


", "time": "2023-11-06T09:06:17Z"}, {"author": "Christian Hopps", "text": "
isn't this useful for OSPF too?
", "time": "2023-11-06T09:06:37Z"}, {"author": "Les Ginsberg", "text": "
Could be - in which case you would have \"OSPF-Support\" module.
", "time": "2023-11-06T09:07:03Z"}, {"author": "Les Ginsberg", "text": "
Different modules.
…


(BTW, there seems to be no chat history in the minutes for IETF 117)

If this is because of some meetecho change, please let them know the old format 
was better.
If this is just a format change introduced by the way cut and paste was done  
to the minutes, it would be nice to update it.

Thanx.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Yingzhen Qu
Sent: Monday, November 20, 2023 6:18 AM
To: lsr mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
Subject: [Lsr] IETF 118 LSR Minutes

Hi,

The meeting minutes of IETF 118 LSR session is available: IETF-118 : 
lsr<https://datatracker.ietf.org/meeting/118/session/lsr>

Please review and let us know if any corrections are needed.

Thanks,
Yingzhen

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