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

[Tony Li]

Hi Jimmy,

I do think that implementors will implement multi-TLV when they have need of 
it, which generally means that they have some feature that’s going to generate 
that much data or when some customer asks for it. I think that the document is 
quite clear about how to implement it. Determining the key is quite obvious and 
needs no further elucidation. 

Anyone can claim to comply with any document at any time. Claims are cheap and 
not necessarily meaningful.

You can never be sure of interoperability, just as you can never be sure that 
you’ve caught the last bug.  The only way is to test.  Operators and vendors 
know this.

Tony


> On Sep 12, 2024, at 8:43 PM, Dongjie (Jimmy) - jie.dong at huawei.com 
>  wrote:
> 
> Hi Tony,
>  
> Thanks for the quick response.
>  
> I got the point that this document aims to provide the principle for applying 
> the MP-TLV approach to many existing TLVs (listed in the IANA section). In 
> reality vendors will not implement the proposed changes to all those TLVs, 
> especially that for some TLVs, the behavior is not fully specified by this 
> document. Can they still claim to comply to this document? And can operators 
> be sure that these implementations are interoperable? 
>  
> Best regards,
> Jie
>  
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of Tony Li
> Sent: Thursday, September 12, 2024 10:19 PM
> To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
> Cc: Bruno Decraene  <mailto:bruno.decra...@orange.com>>; Les Ginsberg  <mailto:ginsb...@cisco.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)
>  
> Hi Jimmy,
>  
> Thank you for your comments.
>  
> The whole point of this document is to broadly define the MP-TLV rules for 
> all appropriate TLVs.
>  
> Regards,
> Tony
>  
> 
> 
> On Sep 12, 2024, at 1:00 AM, Dongjie (Jimmy) 
>  <mailto:jie.dong=40huawei@dmarc.ietf.org>> wrote:
>  
> Hi Bruno, Tony, Les and all,
>  
> I fully understand the concern about interoperability, and would support 
> approaches which can help to improve interoperability.
>  
> In addition to making the text more strict by using “MUST”, I’d like to 
> mention other points which can help to mitigate the risk for operators.
>  
> In my view the main purpose of this document is to specify the usage of the 
> Multi-part TLV approach to a few existing TLVs which are likely to exceed the 
> limitation of 255 octets, such as TLV 22 and TLV 135. Although these two TLVs 
> are just described as examples in the draft, the specifications about their 
> key fields and the sending/receiving procedure are clear. With the new router 
> capability information and operator’s control, their interoperability could 
> be achieved. 
>  
> While for other TLVs as listed in the IANA with “Y” in the MP column, their 
> key fields and the procedure are not explicitly specified in this document. 
> IMO this leaves uncertainty on whether, when and how they will be 
> implemented, and this would increase the possibility of interoperability 
> issues for implementations which claim to support this document. And this 
> cannot be reflected by the new router capability information. Due to such 
> uncertainty, operators may choose not to use Multi-part TLV even for TLV 22 
> and 135.
>  
> Thus if the purpose of the document is to promote the usage of Multi-part 
> approach for TLVs which already show the needs, maybe it is better to narrow 
> down the scope of this document and focus on the specification for a smaller 
> group of TLVs. 
>  
> Best regards,
> Jie
>  
> From: bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> 
> [mailto:bruno.decra...@orange.com]
> Sent: Tuesday, September 10, 2024 10:41 PM
> To: Tony Li mailto:tony...@tony.li>>
> Cc: Les Ginsberg mailto:ginsb...@cisco.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 Tony,
>  
> From: Tony Li mailto:tony1ath...@gmail.com>> On 
> Behalf Of Tony Li
> Sent: Tuesday, September 10, 2024 4:15 PM
> To: DECRAENE Bruno INNOV/NET  <mailto:bruno.decra...@orange.com>>
> Cc: Les Ginsberg mailto:ginsb...@cisco.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

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

[Tony Li]

Hi Jimmy,

Thank you for your comments.

The whole point of this document is to broadly define the MP-TLV rules for all 
appropriate TLVs.

Regards,
Tony


> On Sep 12, 2024, at 1:00 AM, Dongjie (Jimmy) 
>  wrote:
> 
> Hi Bruno, Tony, Les and all,
>  
> I fully understand the concern about interoperability, and would support 
> approaches which can help to improve interoperability.
>  
> In addition to making the text more strict by using “MUST”, I’d like to 
> mention other points which can help to mitigate the risk for operators.
>  
> In my view the main purpose of this document is to specify the usage of the 
> Multi-part TLV approach to a few existing TLVs which are likely to exceed the 
> limitation of 255 octets, such as TLV 22 and TLV 135. Although these two TLVs 
> are just described as examples in the draft, the specifications about their 
> key fields and the sending/receiving procedure are clear. With the new router 
> capability information and operator’s control, their interoperability could 
> be achieved. 
>  
> While for other TLVs as listed in the IANA with “Y” in the MP column, their 
> key fields and the procedure are not explicitly specified in this document. 
> IMO this leaves uncertainty on whether, when and how they will be 
> implemented, and this would increase the possibility of interoperability 
> issues for implementations which claim to support this document. And this 
> cannot be reflected by the new router capability information. Due to such 
> uncertainty, operators may choose not to use Multi-part TLV even for TLV 22 
> and 135.
>  
> Thus if the purpose of the document is to promote the usage of Multi-part 
> approach for TLVs which already show the needs, maybe it is better to narrow 
> down the scope of this document and focus on the specification for a smaller 
> group of TLVs. 
>  
> Best regards,
> Jie
>  
> From: bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> 
> [mailto:bruno.decra...@orange.com]
> Sent: Tuesday, September 10, 2024 10:41 PM
> To: Tony Li mailto:tony...@tony.li>>
> Cc: Les Ginsberg mailto:ginsb...@cisco.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 Tony,
>  
> From: Tony Li mailto:tony1ath...@gmail.com>> On 
> Behalf Of Tony Li
> Sent: Tuesday, September 10, 2024 4:15 PM
> To: DECRAENE Bruno INNOV/NET  <mailto:bruno.decra...@orange.com>>
> Cc: Les Ginsberg mailto:ginsb...@cisco.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)
>  
> Hi Bruno,
>  
> [Bruno2] I agree that everyone should already want to interoperable. But the 
> unfortunate reality is that not everyone does. I believe that RC3107 is a 
> relatively well-known example: some implementors have deliberately not 
> implemented all (implicit) MUST at the cost of interop issues for network 
> operators. Some details 
> inhttps://datatracker.ietf.org/doc/html/rfc8277#section-1 I have other more 
> recent examples but I’d rather avoid pointing to specific implementations.
>  
>  
> So you’re admitting that ‘MUST’ doesn’t guarantee interoperability. So why 
> fight about it?
>  
> MUST does not guarantee interoperability for implementations which are not 
> compliant with the RFC. (i.e., implementation which does not respect the 
> MUST. By design or bugs)
> Implementations which are compliant with RFC are interoperable.
>  
> --Bruno
>  
> T
>  
>  
> 
> 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
> 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)

[Tony Li]

Hi Bruno,

> [Bruno2] I agree that everyone should already want to interoperable. But the 
> unfortunate reality is that not everyone does. I believe that RC3107 is a 
> relatively well-known example: some implementors have deliberately not 
> implemented all (implicit) MUST at the cost of interop issues for network 
> operators. Some details 
> inhttps://datatracker.ietf.org/doc/html/rfc8277#section-1 I have other more 
> recent examples but I’d rather avoid pointing to specific implementations.


So you’re admitting that ‘MUST’ doesn’t guarantee interoperability. So why 
fight about it?

T


___
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)

[Tony Li]

Hi Bruno,
 
> I also want correctness and I’m fine with your definition of MUST.
> The issue with current text in -05 is that everyone can do MUST and MUST NOT 
> and things may not work. e.g., one node is allowed to send MP-TLV for TLV 22 
> whatever is configured by the network operator.  If other nodes do not 
> support MP-TLV for TLV 22, things will not work.
> How do you propose to make this work?

Please see section 7.  It is both necessary and sufficient.

T


___
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)

[Tony Li]

Hi Robert,

> So why keep pretending that the spec wording is useful ? I would much better 
> see to state in the RFC that let's leave how the TLVs are filled to the 
> discretion of the implementation and move on ... Forget about any normative 
> language. 

The current language in the spec is exactly correct: you MUST NOT discard TLVs 
just because you don’t like them.  We want that for interoperability.

Then, we SHOULD do a decent job of packing them because we don’t want 
unnecessary parts running around.

T


___
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)

[Tony Li]

Hi Robert,


>> You do not make the network safer by mandate.  You make it safer by writing 
>> more forgiving code.
> 
> Hope you agree that above all you make network interop safer by writing 
> deterministic protocol specifications. 


No! I disagree completely.  As soon as you make the specification 100% 
deterministic you block out all implementation lattitude and introduce 
unnecessary brittleness into the protocol.  Should flooding be deterministic?  
Do you really want: “You must transmit LSPs are 10ms intervals.”? Or: “TLVs 
must appear in ascending numerical order, packed as tightly as possible.”? 

I want correctness.  If everyone does the MUST and MUST NOTs, then things will 
work. SHOULDs will make it run better.  I do NOT want to overconstrain things, 
especially for unnecessary reasons.


> The section 5 says: 
> 
>Although MP-TLVs SHOULD NOT be sent unless the
>capacity of a single TLV (255 octets) is exceeded, receivers MUST NOT
>reject MP-TLVs if senders do not strictly adhere to this constraint.
>See Section 7.3 for guidance when sending MP-TLVs.
> 
> If you replace "SHOULD NOT" above with "MUST NOT" perhaps the request for 
> MUST to be able to disable MP-TLV (on a per TLV basis) would make a bit of a 
> weaker case. 


Do you agree that receivers MUST NOT reject MP-TLVs if the senders do not 
strictly adhere to maximum packing?  If you do agree, then why does it matter?  
There may be good reasons for not doing maximum packing, such as optimal LSP 
packing.  A little lattitude here would be a good thing.

Again, Postel’s law.


> But for now keeping SHOULD in both places (section 5 and 7.1) just opens room 
> for individual vendor's interpretation and behaviours and are soft while MUST 
> in any of those paragraphs would IMO help protocol robustness. 


I respectfully disagree. 

T


___
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)

[Tony Li]

Hi Bruno,


> 
> First off, link identifiers are a sore spot.  Mistakes were made. However, we 
> have, after many tweaks, achieved interoperability in the field.
>  
> We are now just trying to formally document how to extend this into the 
> MP-TLV space. We do not want to upset the delicate balance of existing 
> implementations.
>  
> By documenting this as a ’SHOULD’, we encourage all implementations along a 
> certain direction without discrediting interoperable implementations that do 
> not 
> precisely follow the letter of the spec. Please understand that as soon as we 
> say ‘MUST’, it becomes a highly competitive issue and someone’s sales team 
> uses it as a lever to bash someone else’s sales team.  If, in fact, things 
> are interoperable, there is no practical problem. Why pick a fight when we 
> don’t have to?
>  
> [Bruno] There _is_ an interop issue. I believe Les has acknowledged this. “we 
> are at risk that some implementation which does not support Link IDs would 
> not be able to correctly match the two TLVs. I think this is a valid point 
> and I will modify the draft to address this.”
> https://mailarchive.ietf.org/arch/msg/lsr/qRiLP_XqhQqmTKWtM4B2EIPPAyM/


I believe that Les has already addressed this issue in -05.


> As for sales team speech, I sympathize but I can’t change sale teams behavior 
> (at my level I try to keep them honest, but I’m afraid that money seems a 
> bigger incentive). Plus it seems like sales teams would have a much bigger 
> lever by saying that an implementation not supporting the knob to disable the 
> sending of MP-TLV creates a risk for the network. So I’m not sure that the 
> “SHOULD” path is that much safer.


The “SHOULD” path completely disarms the sales team abuse. Again, everyone 
should already want to interoperate.  That’s why we’re all here.


> I understand the vendor position to protect the pre-standard implementation. 
> But I’m in the network operator position and I’m trying to make the network 
> as safe as possible. We’ll see what position the IETF will take.


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


> More philosophically, interoperability occurs because all parties see the 
> benefits of mutual interoperability, not because of the wording of the spec.  
> We are not lawmakers and there is no enforcement mechanism.  It behooves us 
> to write specs that gently encourage everyone to be interoperable. Despite 
> recent musing by the IAB, Postel’s law is still the best way forward.
>  
> [Bruno] RFC 2119 defines keywords for a reason. (to indicate Requirement 
> Levels).


Yes, clarity of intent. None of it has the power of law.

T


___
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)

[Tony Li]

Hi Bruno,

> As you know, there are several TLVs that have been MP-TLV for a very long 
> time (e.g. ROUTER CAPABILITY).  Having these be MP is a practical operational 
> necessity already today.  Disabling this on any node would likely break any 
> network that has some fairly common features (e.g. FlexAlgo) enabled.
>  
> [Bruno] I meant for the newly defined MP-TLV. The one for which MP handling 
> is changed by this document.  TLVs which have been defined with MP-TLV from 
> day one do not create interop issue. It’s the change of behavior when 
> handling TLV X of a new implementation which create an interop issue with the 
> handling of TLV X from old implementations.
> If it’s just a wording issue, I’m confident that someone can craft the right 
> wording.
>  
> What is the point of a knob that cannot be turned off?
> [Bruno] I agree that the point is to be able to turn it off.


Then you’re back to requiring per-TLV configuration. No thanks.

Also, I don’t think we’re trying to create any “newly defined MP-TLV”.  The 
point is to codify what has been done and create a default path moving forward.

T

___
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)

[Tony Li]

Hi Bruno,

> I’m not asking for per-TLV controls.
> I’m asking for REQUIRED “configuration controls to enable/disable generation 
> of MP-TLVs.”
>  
> IOW
> OLD:   It is RECOMMENDED that implementations which support the sending of 
> MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs
> NEW: It is REQUIRED that implementations which support the 
> sending of MP-TLVs provide configuration controls to enable/disable 
> generation of MP-TLVs

Thank you for the clarification.

As you know, there are several TLVs that have been MP-TLV for a very long time 
(e.g. ROUTER CAPABILITY).  Having these be MP is a practical operational 
necessity already today.  Disabling this on any node would likely break any 
network that has some fairly common features (e.g. FlexAlgo) enabled.

What is the point of a knob that cannot be turned off?

T


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

[Lsr] Re: 【Major Issues Unsolved】I-D Action: draft-ietf-lsr-multi-tlv-05.txt

[Tony Li]

Hi Aijun,

Les is on vacation, so you’ll pardon while I pinch-hit.

Your opinions are duly noted.

Thank you very much for your comments.

Regards,
Tony


> On Sep 6, 2024, at 6:46 AM, Aijun Wang - wangaijun at tsinghua.org.cn 
>  wrote:
> 
> Hi, Les:
>  
> I have reviewed again this revised draft, and contrary to your declaration 
> that "it addressed all the comments/issues", IT IS NOT. 
> Here are my analysis:
>  
> 1) The document states in several places that the key is necessary for the 
> right process of MP-TLV, and gives two examples for the TLV 22 and TLV 135, 
> their respective key definitions, but, there is no key definition for other 
> code points.
>  
> 2) If you think it is impossible to define the key definition for all the 
> MP-TLV applicable TLV that you list in the sec 8.1(IANA consideration) in 
> your document, then this is the WRONG direction to solve the MP-TLV related 
> problem.
>   If you can't define such key information, the interoperability problem will 
> be arose within the operator network.
>  
> 3) Such consideration is same for the MP-TLV Capability Advertisement. In 
> your solution, MP-TLV capability advertisement is not per-codepoint basis, 
> then how you require the operator "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." ? 
> By manual? By other OOB methods?
>  
> 4) Based on the above comments, I think your draft should be renamed as 
> "MP-TLV Key Definition for IS-IS TLV 22 and TLV 135", it is far to be 
> evaluated as one general solution for MP-TLV problem.
>  
> I can't see other values except the key definition of TLV 22 and TLV 135 from 
> the current version.
> Following such direction, the operator will be busy to coordinate the 
> vendors, the deployment for the opened Pandora's box
>  
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> -邮件原件-
> 发件人: forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org> 
> [mailto:forwardingalgori...@ietf.org] 代表 internet-dra...@ietf.org 
> <mailto:internet-dra...@ietf.org>
> 发送时间: 2024年9月6日 1:57
> 收件人: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
> 抄送: lsr@ietf.org <mailto:lsr@ietf.org>
> 主题: [Lsr] I-D Action: draft-ietf-lsr-multi-tlv-05.txt
>  
> Internet-Draft draft-ietf-lsr-multi-tlv-05.txt is now available. It is a work 
> item of the Link State Routing (LSR) WG of the IETF.
>  
>Title:   Multi-part TLVs in IS-IS
>Authors: Parag Kaneriya
> Tony Li
> Antoni Przygienda
> Shraddha Hegde
> Les Ginsberg
>Name:draft-ietf-lsr-multi-tlv-05.txt
>Pages:   27
>Dates:   2024-09-05
>  
> Abstract:
>  
>New technologies are adding new information into IS-IS while
>deployment scales are simultaneously increasing, causing the contents
>of many critical TLVs to exceed the currently supported limit of 255
>octets.  Extensions exist that require significant IS-IS changes that
>could help address the problem, but a less drastic solution would be
>beneficial.  This document codifies the common mechanism of extending
>the TLV content space through multiple TLVs.
>  
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/
>  
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-05
>  
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-multi-tlv-05
>  
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts
>  
>  
> ___
> Lsr mailing list -- lsr@ietf.org <mailto:lsr@ietf.org>
> To unsubscribe send an email to lsr-le...@ietf.org 
> <mailto:lsr-le...@ietf.org>___
> Lsr mailing list -- lsr@ietf.org <mailto:lsr@ietf.org>
> To unsubscribe send an email to lsr-le...@ietf.org <mailto:lsr-le...@ietf.org>
___
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

[Lsr] Re: 答复: Re: 【Please Abandon this WGLC document】答复: Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Tony Li]

Hi Aijun,

Please see the IETF procedures for determining rough consensus. We do not need 
unanimity.

AFAICT, this draft is currently opposed only by you and Bruno and supported by 
many others.

You’re welcome to look at the proof yourself, it’s quite obvious.

Please also review RFC 7154 while you’re at it.

Regards,
Tony


> On Sep 2, 2024, at 8:38 PM, Aijun Wang - wangaijun at tsinghua.org.cn 
>  wrote:
> 
> Hi, Chris:
> 
> Please give the proof where is the WG's consensus? We all can see and 
> retrieve all the responses from its WGLC process publicly.
> Please note: The chairs' preference doesn’t represent the WG's consensus.
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -邮件原件-
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
> Christian Hopps
> 发送时间: 2024年9月3日 11:18
> 收件人: Aijun Wang 
> 抄送: bruno.decra...@orange.com; 'Yingzhen Qu' ; 
> 'lsr-chairs' ; 'lsr' 
> 主题: [Lsr] Re: 【Please Abandon this WGLC document】答复: Re: WG Last Call for 
> draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)
> 
> 
> "Aijun Wang"  writes:
> 
>> I would like to emphasize that this document will lead to more chaos 
>> for the operators network, even it solves the control of when to send 
>> the MP-TLV problems.
>> 
>> Please see:  https://mailarchive.ietf.org/arch/msg/lsr/
>> Gf4D3REVNXWO9BlIVPqnZ3f-GcM/ for more unsolved problems.
>> 
>> 
>> 
>> It’s time to ABANDON it.
> 
> As WG Chair.
> 
> This document will NOT be abandoned. We're literally in WGLC with WG 
> consensus on the general solution.
> 
> Chris.
> 
> ___
> 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: Consensus Call on "IS-IS Distributed Flooding Reduction" - draft-ietf-lsr-distoptflood-05

[Tony Li]

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] Re: Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-labv-registration-03: (with COMMENT)

[Tony Li]

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 
>  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: Paul Wouters' No Objection on draft-ietf-lsr-labv-registration-03: (with COMMENT)

[Tony Li]

Hi Paul,

First, allocating those code points would require an RFC.  Thus, it has the 
same overhead as changing the registration procedure.

Second, the result would be a range of uncoordinated code points, which is not 
what we’re after.  We do want to register and have unique code points for 
experiments.

Third, we would very much like to have all of the IS-IS registries using the 
Expert Review procedure. This is the only one that isn’t. Expert Review gives 
us much more flexibility.

T


> On Aug 7, 2024, at 12:30 PM, Paul Wouters via Datatracker  
> wrote:
> 
> Paul Wouters 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:
> --
> 
> 
> 
>"In practice, this registration procedure is unnecessarily restrictive, as
>it prevents
> allocation of bits to experimental protocols, which in turn increases the
> risk of conflicts introduced by use of unregistered code points (so-called
> "code point squatting")
> 
> Why not create a few "Private use and/or Experimental" values and leave the
> registration policy Standards Track?
> 
> 
> 

___
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)

[Tony Li]

Hi Bruno,


> 
> However, it is not the job of this draft to resolve existing problems in 
> every single TLV in IS-IS.
>  
> I would argue that this is not an existing problem, but a new problem created 
> by this document. So it would seem fair for this document to address the 
> problems it creates


As Les has already pointed out, the problem already exists and has for a long 
time.  It will continue to exist even without this document.


>  If nothing else, that would turn this document into more of an encyclopedia 
> than it already is.  That is simply not practical and not in keeping with how 
> the IETF works.  Scalability dictates that issues with specific TLVs should 
> be handled in documents that are specific to the TLV.
>  
> I understand your point. Yet that issue has been raised by a significant 
> percentage of external reviewers of this draft.
> May be a reasonable middle ground would be for this document to specify the 
> key of the few (sub) TLVs for which the existing definition may be ambiguous 
> (e.g. TLV 22 as already done in the draft).


Then someone will object that we were not thorough and that we have to do all 
of them, whether obvious or not.


Tony

___
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)

[Tony Li]

Bruno,

We agree that interoperability is paramount.

However, it is not the job of this draft to resolve existing problems in every 
single TLV in IS-IS.  If nothing else, that would turn this document into more 
of an encyclopedia than it already is.  That is simply not practical and not in 
keeping with how the IETF works.  Scalability dictates that issues with 
specific TLVs should be handled in documents that are specific to the TLV.

Regards,
Tony


> On Aug 6, 2024, at 3:36 AM, bruno.decra...@orange.com wrote:
> 
> Thanks Les for your reply.
> Please see 1 comment inline [Bruno]
>  
> From: Les Ginsberg (ginsberg)  >
> 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  >
> 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  >
> 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.
>  
> [Bruno] I think that interoperability is important, especially for a link 
> state IGP.
> If interop depends on the “generosity” of the receivers, why not specifying 
> (I mean mandating with MUST) the level of generosity which is required for 
> interop (well I mean “for things to work”)
>  
> Thanks,
> --Bruno
>  
> 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://m

[Lsr] Re: 答复: 【What's the reason to move forward this document to be published?】答复: I-D Action: draft-ietf-lsr-multi-tlv-03.txt

[Tony Li]

It is the job of the WG chairs to determine consensus.

T


> On Aug 4, 2024, at 11:53 PM, Aijun Wang  wrote:
> 
> Hi, Tony:
> 
> You agree also the IETF operates on "rough consensus".  Then Let's examine 
> carefully the last call responses of this 
> draft(https://mailarchive.ietf.org/arch/browse/lsr/?gbt=1&index=pxypKxuH2PtQ2Jd9DE8Q_tBg0Co):
> 
> There are totally 16 replies to this WGLC: 
> 9 from the authors(include none-IPR declarations), 
> 1 from Yingzhen to call the IPR responses
> 2 from Ketan(with similar "key definition" suggestions), 1 from 
> Peter(friendship support), 1 from Acee(friendship support), 2 from Mine(with 
> objecting its forwarding)
> 
> Does the above statists represent "Rough Consensus"? I don't think so, I 
> think you can't easily call it "Rough Consensus", right?
> 
> Even the author himself admitted it was difficult to elaborate the "key 
> fields" of each code 
> point(https://mailarchive.ietf.org/arch/msg/lsr/pxypKxuH2PtQ2Jd9DE8Q_tBg0Co/,),
>  then what's the value of this document?
> 
> As my suggestions, it will be more easy to declare "Every code point may 
> emerge multiple times within one LSA, and it depends the vendor to implement 
> it".
> 
> To answer your question "Where to start", my replies is that we need other 
> creative solution to solve such issue in one extensible manner.
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> -邮件原件-
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
> Tony Li
> 发送时间: 2024年8月5日 12:40
> 收件人: Aijun Wang 
> 抄送: lsr@ietf.org
> 主题: [Lsr] Re: 答复: 【What's the reason to move forward this document to be 
> published?】答复: I-D Action: draft-ietf-lsr-multi-tlv-03.txt
> 
> 
> Hi Aijun,
> 
> Where to start?
> 
> There is no hurry for this document. It started in Jan. 2022. It has evolved, 
> been discussed, and evolved some more, to the point where almost everyone is 
> happy with it and it’s time to publish it.
> 
> We recognize that you don’t like it.  That’s fine.  The IETF operates on 
> rough consensus and we are very happy to progress without your assent.
> 
> We’ve discussed these points with you before and made no progress.  I see no 
> point in repeating myself.
> 
> Regards,
> Tony
> 
> 
>> On Aug 4, 2024, at 7:01 PM, Aijun Wang  wrote:
>> 
>> give to clue to the vendors to implement it /s give no clue to the vendors 
>> to implement it.
>> 
>> -邮件原件-
>> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
>> Aijun Wang
>> 发送时间: 2024年8月5日 9:56
>> 收件人: lsr@ietf.org
>> 主题: [Lsr] 【What's the reason to move forward this document to be 
>> published?】答复: I-D Action: draft-ietf-lsr-multi-tlv-03.txt
>> 
>> Hi, WG chairs and authors of this draft:
>> 
>> I have reviewed again the evolution of this draft, and am struggled to 
>> understand what's the reason for this WG to move forward this document to be 
>> adopted, to be WG LCed and even to be published, in such hurry manner?
>> 
>> As pointed out during its adoption call, its WGLC process, if it doesn't 
>> address(or can't be, as Les expressed in 
>> https://mailarchive.ietf.org/arch/msg/lsr/pxypKxuH2PtQ2Jd9DE8Q_tBg0Co/) the 
>> definition of key part of each code point, how to assure the 
>> interoperability? 
>> 
>> What's the differences that we just state simply that every TLV, sub-TLV 
>> within IS-IS is multi-part applicable instead of the authors list onerously 
>> almost for every TLV, sub-TLV for its applicability? 
>> 
>> And, as stated in abstract of this document, it "codifies the common 
>> mechanism", where is it, please point me out clearly which part in this 
>> document describe the "common mechanism"?
>> 
>> Yes, The Chairs has the right to put forward it, even to publish it as RFC. 
>> BUT, as the person from the operator, I can assert that this document bring 
>> no benefit to the operators who want to deploy it, give to clue to the 
>> vendors to implement it.
>> 
>> 
>> Look forward the WG, or IESG abandon it.
>> 
>> Best Regards
>> 
>> Aijun Wang
>> China Telecom
>> 
>> 
>> 邮件原件-
>> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
>> internet-dra...@ietf.org
>> 发送时间: 2024年8月3日 9:08
>> 收件人: i-d-annou...@ietf.org
>> 抄送: lsr@ietf.org
>> 主题: [Lsr] I-D Action: draft-ietf-lsr-multi-tlv-03.txt
>> 

[Lsr] Re: 答复: 【What's the reason to move forward this document to be published?】答复: I-D Action: draft-ietf-lsr-multi-tlv-03.txt

[Tony Li]

Hi Aijun,

Where to start?

There is no hurry for this document. It started in Jan. 2022. It has evolved, 
been discussed, and evolved some more, to the point where almost everyone is 
happy with it and it’s time to publish it.

We recognize that you don’t like it.  That’s fine.  The IETF operates on rough 
consensus and we are very happy to progress without your assent.

We’ve discussed these points with you before and made no progress.  I see no 
point in repeating myself.

Regards,
Tony


> On Aug 4, 2024, at 7:01 PM, Aijun Wang  wrote:
> 
> give to clue to the vendors to implement it /s give no clue to the vendors 
> to implement it.
> 
> -邮件原件-
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
> Aijun Wang
> 发送时间: 2024年8月5日 9:56
> 收件人: lsr@ietf.org
> 主题: [Lsr] 【What's the reason to move forward this document to be 
> published?】答复: I-D Action: draft-ietf-lsr-multi-tlv-03.txt
> 
> Hi, WG chairs and authors of this draft:
> 
> I have reviewed again the evolution of this draft, and am struggled to 
> understand what's the reason for this WG to move forward this document to be 
> adopted, to be WG LCed and even to be published, in such hurry manner?
> 
> As pointed out during its adoption call, its WGLC process, if it doesn't 
> address(or can't be, as Les expressed in 
> https://mailarchive.ietf.org/arch/msg/lsr/pxypKxuH2PtQ2Jd9DE8Q_tBg0Co/) the 
> definition of key part of each code point, how to assure the 
> interoperability? 
> 
> What's the differences that we just state simply that every TLV, sub-TLV 
> within IS-IS is multi-part applicable instead of the authors list onerously 
> almost for every TLV, sub-TLV for its applicability? 
> 
> And, as stated in abstract of this document, it "codifies the common 
> mechanism", where is it, please point me out clearly which part in this 
> document describe the "common mechanism"?
> 
> Yes, The Chairs has the right to put forward it, even to publish it as RFC. 
> BUT, as the person from the operator, I can assert that this document bring 
> no benefit to the operators who want to deploy it, give to clue to the 
> vendors to implement it.
> 
> 
> Look forward the WG, or IESG abandon it.
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> 邮件原件-
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
> internet-dra...@ietf.org
> 发送时间: 2024年8月3日 9:08
> 收件人: i-d-annou...@ietf.org
> 抄送: lsr@ietf.org
> 主题: [Lsr] I-D Action: draft-ietf-lsr-multi-tlv-03.txt
> 
> Internet-Draft draft-ietf-lsr-multi-tlv-03.txt is now available. It is a work 
> item of the Link State Routing (LSR) WG of the IETF.
> 
>   Title:   Multi-part TLVs in IS-IS
>   Authors: Parag Kaneriya
>Tony Li
>Antoni Przygienda
>Shraddha Hegde
>Les Ginsberg
>   Name:draft-ietf-lsr-multi-tlv-03.txt
>   Pages:   26
>   Dates:   2024-08-02
> 
> Abstract:
> 
>   New technologies are adding new information into IS-IS while
>   deployment scales are simultaneously increasing, causing the contents
>   of many critical TLVs to exceed the currently supported limit of 255
>   octets.  Extensions exist that require significant IS-IS changes that
>   could help address the problem, but a less drastic solution would be
>   beneficial.  This document codifies the common mechanism of extending
>   the TLV content space through multiple TLVs.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-03
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-multi-tlv-03
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> 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 mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-labv-registration-03.txt

[Tony Li]

FYI…

T

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-labv-registration-03.txt
> Date: July 29, 2024 at 12:39:31 PM PDT
> To: "Tony Li" 
> 
> A new version of Internet-Draft draft-ietf-lsr-labv-registration-03.txt has
> been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-labv-registration
> Revision: 03
> Title:Revision to Registration Procedures for IS-IS Neighbor 
> Link-Attribute Bit Values
> Date: 2024-07-29
> Group:lsr
> Pages:3
> URL:  
> https://www.ietf.org/archive/id/draft-ietf-lsr-labv-registration-03.txt
> Status:   https://datatracker.ietf.org/doc/draft-ietf-lsr-labv-registration/
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-labv-registration
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-labv-registration-03
> 
> 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".  This document updates
>   RFC5029.
> 
> 
> 
> The IETF Secretariat
> 
> 

___
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)

[Tony Li]

Hi Roman,

Thank you for your comments.

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


RFC 5029 created the registry that we are modifying.  Thus, it behooves the 
designated expert to be familiar with RFC 5029.
The more specific guidance is relative to the registry and functionality that 
is captured in the registrants.

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


If a Designated Expert was acting inappropriately, there is an unbounded number 
of factors that they could 
consider, including the phase on the moon, the affiliations of the authors, or 
whether last night’s dinner
was satisfactory.


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


Yes.  All other IS-IS registries are already under “expert review”.  This has 
functioned well to date, up
until us trying to make an experimental entry in this registry. We choose 
“expert review” to “specification
required” because we put more weight in the opinions of the experts than in the 
fact that someone
has written a specification.  Writing something down is a very low bar and it 
would be very easy for
someone to write a bad specification.  Thus, the primary criteria is to satisfy 
the oversight of the designated
experts, who presumably will ensure that there is a good and sensible 
specification as well.

> 
> ** 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 …”


Sentence added in -03.

T




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

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

[Tony Li]

Hi,

I was going to stay out of this, but then you went and picked on me.


> The links that you provided has no relation for the discussions of "proxy of 
> LSA originator".  Would you like to provide other pointer to support Tony's 
> assertion?


If you look back a few years, you will find the discussion of IS-IS purge 
origination TLV.  Part of that was a band-aid to counter the fact that the 
original protocol allowed any system to purge anything at any time for any 
reason.  This was basically an undebuggable problem as any system in the area 
could have triggered it.


> And, we have now the "area proxy for IS-IS 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-12";, why 
> can't we try the neighbor proxy solution?


Just because both use the word ‘proxy’ doesn’t mean that they have anything to 
do with one another.  In Area Proxy, it is VERY clear who the actor is: the 
area leader. All systems have elected this.


> Why don't clear the stale LSPs in advance by the proxy neighbor?


Because you create a race condition and you create a traceability problem.  And 
there are already simpler ways of solving this without protocol additions.

Tony

___
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

[Tony Li]

Sue,

Glad you’re doing better.  I’ve submitted this change as -02.  Thank you!

See you in Vancouver!

T


> On Jul 8, 2024, at 11:52 AM, Susan Hares  wrote:
> 
> Tony:
>  
> This change is wonderful.  Thank you for your patience regarding my response.
>  
> Sue 
>  
> From: Tony Li  On Behalf Of Tony Li
> Sent: Wednesday, June 26, 2024 11:06 AM
> To: Susan Hares 
> Cc: ops-...@ietf.org; draft-ietf-lsr-labv-registration@ietf.org; 
> last-c...@ietf.org; lsr 
> Subject: Re: Opsdir last call review of draft-ietf-lsr-labv-registration-01
>  
>  
>  
>  
> > On Jun 26, 2024, at 4:51 AM, Susan Hares via Datatracker  > <mailto:nore...@ietf.org>> 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] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

[Tony Li]

Support, as co-author.

I am unaware of any IPR that pertains to this document.

T


> On Jul 1, 2024, at 11:07 PM, Yingzhen Qu  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: Opsdir last call review of draft-ietf-lsr-labv-registration-01

[Tony Li]

> 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] Re: Shepherd review of draft-ietf-lsr-labv-registration

[Tony Li]

Done.  Thank you for your suggestions.

T


> On Jun 7, 2024, at 11:28 AM, Yingzhen Qu  wrote:
> 
> Hi Tony,
> 
> Thanks for working on this document.
> 
> I have the following comments for you to consider:
> The working group should be set to "LSR Working Group" instead of "Network 
> Working Group".
> In the IANA consideration, you may consider adding: "General guidance for the 
> designated experts is defined in [RFC7370 
> ]."
> Thanks,
> Yingzhen

___
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

[Tony Li]

Thank you for making this happen and proving that the IETF process is not 
wholly ossified.

T


> On Jun 7, 2024, at 9:52 AM, Yingzhen Qu  wrote:
> 
> Hi,
> 
> The WGLC is now concluded. Thanks to everyone who reviewed and commented on 
> the draft.
> 
> I'll upload my shepherd write-up, then submit the draft to the IESG for 
> publication.
> 
> Thanks,
> Yingzhen
> 
> On Wed, May 22, 2024 at 8:59 AM Yingzhen Qu  > wrote:
>> 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 mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

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

[Tony Li]

Support, as author.

T


> On May 22, 2024, at 8:59 AM, Yingzhen Qu  wrote:
> 
> 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 mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

[Lsr] Re: WG Adotpion call - draft-li-lsr-labv-registration (5/2/2024-5/16/2024)

[Tony Li]

Done.

Can we please now progress the document?

Thanks,
Tony


> On May 20, 2024, at 7:04 AM, Yingzhen Qu  wrote:
> 
> The adoption call is now concluded, and the draft is adopted.
> 
> Authors, please publish the draft as draft-ietf-lsr-labv-registration.
> 
> Thanks,
> Yingzhen
> 
> On Mon, May 6, 2024 at 6:06 PM  > wrote:
>> Support the adoption.
>> 
>> Thanks,
>> 
>> Sandy
>> 
>> 
>>  
>> 
>>  
>> 
>>  
>> Original
>> From: YingzhenQu mailto:yingzhen.i...@gmail.com>>
>> To: lsr mailto:lsr@ietf.org>>;lsr-chairs > >;
>> Date: 2024年05月02日 22:35
>> Subject: [Lsr] WG Adotpion call - draft-li-lsr-labv-registration 
>> (5/2/2024-5/16/2024)
>> ___
>> Lsr mailing list
>> Lsr@ietf.org 
>> https://www.ietf.org/mailman/listinfo/lsr
>> 
>> 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
> 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

Re: [Lsr] WG Adotpion call - draft-li-lsr-labv-registration (5/2/2024-5/16/2024)

[Tony Li]

As author, I support adoption.

I am unaware of any undisclosed IPR.

Tony



> On May 2, 2024, at 7:35 AM, Yingzhen Qu  wrote:
> 
> 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

___
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

[Tony Li]

Dear LSR chairs,

It’s been a week and you haven’t even given Les a polite response.  Will you 
take up this challenge?

Could we please start a WG adoption call?

Tony


> On Apr 23, 2024, at 4:21 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> 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

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

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

[Tony Li]

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

[Tony Li]

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] Fwd: New Version Notification for draft-li-lsr-labv-registration-00.txt

[Tony Li]

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

Re: [Lsr] Gunter Van de Velde's No Objection on draft-ietf-lsr-dynamic-flooding-17: (with COMMENT)

[Tony Li]

Gunter,

Thank you for your comments.  Please see inline.

> Thank you for the work put into this document. This document is a joy to read
> and documents an elegant solution to a well known IGP problem problem space.


Thank you.


> 409Similarly, if additional redundancy is added to the flooding
> 410topology, specific nodes in that topology may end up with a very 
> high
> 411degree.  This could result in overloading the control plane of 
> those
> 
> The text reads smooth, until the term 'degree' pops up without explanation 
> what
> it entails. I (non-native English speaker) suspect it is terminology from 
> graph
> theory. I do recall it being mentioned within the presentations about this
> draft in LSR WG. Maybe a short line explaining what degree in graph theory is
> may help with the document for non-native English speakers.
> 
> In my search for some level of understanding on what to understand of degree:
> 
> "In graph theory, the degree of a vertex refers to the number of edges
> connected to that vertex. For undirected graphs, this simply means the count 
> of
> edges touching the vertex. For directed graphs, you can distinguish between 
> the
> "in-degree" and the "out-degree" of a vertex: the in-degree is the number of
> edges coming into the vertex, and the out-degree is the number of edges going
> out from the vertex.
> 
> For example, in an undirected graph, if a vertex has three edges connected to
> it, its degree is 3. In a directed graph, if a vertex has two arrows pointing
> to it and one arrow pointing away, its in-degree is 2 and its out-degree is 
> 1."


This is exactly correct. I will add a definition.


> 417If the leader chooses to include a multi-access broadcast LAN 
> segment
> 418as part of the flooding topology, all of the links in that LAN
> 419segment should be included as well.  Once updates are flooded on 
> the
> 420LAN, they will be received by every attached node.
> 
> The links mentioned here seem to not correspond to the physical links but
> instead to the graph links. I assume a link here is from each unique router on
> the LAN segment to the DR/DIS and from the DR/DIS to each unique router
> connected on the LAN segment? Or is the term link referencing to something 
> else?


As you may recall, IS-IS handles LANs by modeling them as adjacencies from each 
node to the DIS.

It would be more correct here to talk about adjacencies than links.  Amended.


> 422 4.4.  Topologies on Complete Bipartite Graphs
> 
> I agree with the comments from others that a short drawing would make the
> topology descriptions easier to comprehend


A better representation mechanism than ASCII art would make this much
easier.


> 493If two nodes are adjacent on the flooding topology and there are a
> 494set of parallel links between them, then any given update MUST be
> 495flooded over a single one of those links.  The selection of the
> 
> small proposed re-edit for reading clarity:
> 
> "If two nodes are adjacent in the flooding topology and there is a set of
> parallel links between them, then any given update MUST be flooded over only
> one of those links"


Sure.


> 513these edges is optional.  Note that this may result in the
> 514possibility of "hidden nodes" which are part of the flooding 
> topology
> 
> I have sometimes seen the term "stealth" used for hidden nodes or devices


Added.


> 525Other encodings are certainly possible.  We have attempted to make 
> a
> 526useful trade-off between simplicity, generality, and space.
> 
> Not sure who is 'we'? i have seen mostly in IETF style suggestions avoiding it
> in favor of more direct or passive constructions to maintain formal tone and
> objectivity.


Ok.


> 662 5.1.3.  IS-IS Area Node IDs TLV
> 
> Not sure it is clear from the text paragraph where this TLV is inserted in the
> hierarchy of TLVs. For example, for the "IS-IS Dynamic Flooding Sub-TLV" it is
> explicitly mentioned. (TLVs in section 5.1.4/5.1.5/5.1.6 do not have a 
> explicit
> indication of place in the TLV hierarchy either)


This is a top level TLV.  This falls out from the code point allocation.


> 693   Length: 3 + ((System ID Length + 1) * (number of node IDs))
> 
> Should it be mentioned that the unit is octets?


Octets is IS-IS standard, so that’s not really necessary.


> if ever a yang is created it
> will be in there documented anyway why does length start with '3'? I am 
> missing
> a calculation logic


Starting index (2) +
L/Reserved bits (1) +
Number of node IDs * (length of a node ID == system ID + pseudonode index)


> 826In support of advertising which edges are currently enabled in the
> 827flooding topology, an implementation MAY indicate that a link is 
> part
> 828of the flooding topology by advertising a bit-value in the Link
> 829Attributes sub-TLV defined by [RFC5029].
> 
> T

Re: [Lsr] Genart last call review of draft-ietf-lsr-dynamic-flooding-16

[Tony Li]

Hi Reese,

Thank you for your comments.  Please see inline.


> Introduction:
> "However it is very clear that using an Exterior Gateway Protocol as an IGP is
> sub-optimal, if only due to the configuration overhead." To me, the "very
> clear" and the "if only due" sound like they're contradicting each other. If
> it's very clear, I expect a very strong reason or multiple. Please consider
> providing more reasons why an EGP is suboptimal or weakening the "very clear".


Sure.


> "The primary issue that is demonstrated when conventional mechanisms are
> applied is the poor reaction of the network to topology changes." Please
> consider clarifying what conventional mechanisms means specifically here.
> Conventional IGPs? Link state protocol specifically? Are the two the same?


All of our conventional IGPs are link state at this point, so yes.  Reworded to 
‘conventional IGPs’.


> "This problem is not entirely surprising. Link state routing protocols were
> conceived when links were very expensive and topologies were sparse. The fact
> that those same designs are sub-optimal in a dense topology should not come as
> a huge surprise. The fundamental premise that original designs addressed was 
> an
> environment of extreme cost and scarcity. Technology has progressed to the
> point where links are cheap and common. This represents a complete reversal in
> the economic fundamentals of network engineering" The text in and around this
> part seems a bit redundant, please consider shortening it to say the surprise
> part and the "link used to be costly" only once.


Sure.


> Section 3, Solution requirements:
> "Changes to nodes outside of the dense subgraph are not acceptable. "
> Please consider clarifying what "changes" means here - Is this to say that the
> solution needs to be backwards-compatible and/or an extension to an existing
> IGP?


Reworded.  I really meant any change.  Even software upgrades are out of the 
question.  Some production networks require 2 (or more) years to vet a new 
release.


> Section 4, Dynamic flooding:
> "New link state information that arrives from outside of the flooding topology
> suggests that the sender has different or no flooding topology information and
> that the link state update should be flooded on the flooding topology as 
> well."
> This part was not immediately obvious to me - "arrives from outside of the
> flooding topology" means it arrives from outside the subgraph that supports
> dynamic flooding and/or from a legacy device? Or does it mean that the
> information arrives from within the flooding topology but over a link that is
> not part of the flooding topology? Please consider clarifying this point.


Reworded.


> "When centralized mode is used and if, during a transient, there are multiple
> flooding topologies being advertised […]" The word "transient" is used as a
> noun multiple times during the draft, so I assume this is a standing term in
> routing which I have never heard before. Please consider adding a brief
> explanation of what a transient is.


Added.


> Section 4.1:
> Does "legacy flooding" and "standard flooding" refer to the same thing? If so,
> please consider unifying the terms here.


Converged on ’standard’.


> Section 4.3:
> "If the leader chooses to include a multi-node broadcast LAN segment as part 
> of
> the flooding topology, all of the connectivity to that LAN segment should be
> included as well." Please consider clarifying what "all the connectivity" 
> means
> here, as I think this is the first time LANs are discussed. Does it mean all
> links that connect to the LAN segment? Are LANs with multiple links the same 
> as
> "multi-access LANs" referenced later in the document, in which case please
> consider using a consistent term?


Fixed.


> Section 4.4:
> Please consider adding figures to help the explanation here.


I would be happy to, but my limited skills with ASCII art aren’t really up to 
the task.


> Section 4.4.2:
> "Adding one more leaf between the last and first spine will produce a cycle of
> N spines and N leaves." Are these both intended to be N, or is one intended to
> be M?


It is correct as stated.  


> Does the algorithm make any assumptions of how many spines and leaves
> there are in total?


No.  The only assumption is that there are more leaves than spines.  This is 
implicit in the definition of the topology.


> Section 4.5:
> "Instead, we choose to encode the flooding topology as a set of intersecting
> paths, where each path is a set of connected edges." I think this is the first
> time the document mentions paths. Please consider briefly expanding on how a
> path is defined, unless there is a clear consistent definition that is
> well-known in the routing area in general.


Path is a well known term in both graph theory and routing.  A path from node A 
to node B is a connected list of edges starting at A and ending at B.  

Please see RFC 4655 as one of many examples about path computation.

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

[Tony Li]

I am unaware of any undisclosed IPR.

T


> On Feb 19, 2024, at 2:20 PM, Acee Lindem  wrote:
> 
> Co-Authors, 
> 
> Are you aware of any IPR that applies to 
> draft-ietf-lsr-flex-algo-bw-con-07.txt?  
> If so, has this IPR been disclosed in compliance with IETF IPR rules  (see 
> RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> There are a few IPR statements already - 
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-dynamic-flooding
> 
> If you are listed as a document author or contributor please respond
> to this email regardless of whether or not you are aware of any
> relevant IPR. *The response needs to be sent to the LSR WG mailing
> list.* The document will not advance to the next stage until a
> response has been received from each author and contributor.
> 
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
> 
> Also, we have six authors and four from the same company. Please verify that 
> all co-authors should be included as such.
> 
> Thanks,
> Acee

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

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-dynamic-flooding-16.txt

[Tony Li]

FYI: A few more changes from AD review.

T

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-dynamic-flooding-16.txt
> Date: February 14, 2024 at 9:42:43 AM PST
> To: "Huaimo Chen" , "Luay Jalil" 
> , "Peter Psenak" , "Srinath 
> Dontula" , "Tony Li" 
> 
> A new version of Internet-Draft draft-ietf-lsr-dynamic-flooding-16.txt has
> been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-dynamic-flooding
> Revision: 16
> Title:Dynamic Flooding on Dense Graphs
> Date: 2024-02-14
> Group:lsr
> Pages:47
> URL:  
> https://www.ietf.org/archive/id/draft-ietf-lsr-dynamic-flooding-16.txt
> Status:   https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-dynamic-flooding-16
> 
> Abstract:
> 
>   Routing with link state protocols in dense network topologies can
>   result in sub-optimal convergence times due to the overhead
>   associated with flooding.  This can be addressed by decreasing the
>   flooding topology so that it is less dense.
> 
>   This document discusses the problem in some depth and an
>   architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
>   and OSPFv3 are described in this document.
> 
> 
> 
> The IETF Secretariat
> 
> 

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

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

[Tony Li]

Hi John,

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


Thanks again for your comments. Please see inline.


> ### Section 5.1.1
> 
>   • 1-127: Standardized distributed algorithms. Individual values are to 
> be assigned according to the "Specification Required" policy defined in 
> [RFC8126] (see Section 7.3).
> 
> But in 7.3 you’ve changed the policy to Expert Review. I suggest deleting the 
> conflicting sentence here, so,
> 
> NEW:
>   • 1-127: Standardized distributed algorithms. 
> 
> On the basis that it’s better to have a single source of truth when possible. 
> It would also be OK to update the conflicting text, though.


Agreed, fixed.


> ### Section 5.1.2
> 
>   2.  Indicate the set of algorithms that it supports, if any.
> 
> But since you pointed out that "6.4 prohibits zero algorithms”, can’t “if 
> any” be deleted since there must always be at least one?


Agreed, fixed.


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


We are talking about ‘old’ and ’new’ because that is the harsh reality that we 
have to deal with.
It’s not pretty, it’s not ideal, but it’s what we have. IS-IS is designed in a 
way that the
infrastructure can present us with arbitrary, overlapping, inconsistent 
information at any time. 
Fragments (and we can’t even agree to call them fragments) can show up 
arbitrarily and
the receiver has no idea whether they have a complete and consistent set of 
updates or not.

Implementors have to know how to deal with things. If an implementation has one 
flooding
topology in hand and receives fragments that add a second flooding topology, 
what does it do?
If I recall correctly, this question rightfully came up during WG discussions.  
That’s exactly what this
is trying to address.

I appreciate that your proposed text is trying to finesse the issue, but I 
disagree with your resolution.
Your text suggests that a node can simply use a single view of the topology. As 
our second 
paragraph is trying to explain, this could be problematic because the two 
topologies could be radically
different and not flooding on one of them could lead to under-flooding and 
inconsistency. This is
why we specifically want implementations to flood

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-dynamic-flooding-15.txt

[Tony Li]

Hi all,

This update contains changes prompted by John Scudder’s review plus a pass 
through Grammarly.

Comments? Questions?

Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-dynamic-flooding-15.txt
> Date: February 6, 2024 at 4:44:09 PM PST
> To: "Huaimo Chen" , "Luay Jalil" 
> , "Peter Psenak" , "Srinath 
> Dontula" , "Tony Li" 
> 
> A new version of Internet-Draft draft-ietf-lsr-dynamic-flooding-15.txt has
> been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-dynamic-flooding
> Revision: 15
> Title:Dynamic Flooding on Dense Graphs
> Date: 2024-02-06
> Group:lsr
> Pages:47
> URL:  
> https://www.ietf.org/archive/id/draft-ietf-lsr-dynamic-flooding-15.txt
> Status:   https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-dynamic-flooding-15
> 
> Abstract:
> 
>   Routing with link state protocols in dense network topologies can
>   result in sub-optimal convergence times due to the overhead
>   associated with flooding.  This can be addressed by decreasing the
>   flooding topology so that it is less dense.
> 
>   This document discusses the problem in some depth and an
>   architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
>   and OSPFv3 are described in this document.
> 
> 
> 
> The IETF Secretariat
> 
> 

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

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

[Tony Li]

John,

Thank you for your fantastic comments.  Please see inline.


> +++ draft-ietf-lsr-dynamic-flooding-14-jgs-comments.txt   2024-01-24 
> 07:16:47.0 -0500
> @@ -231,6 +231,10 @@
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>document are to be interpreted as described in RFC 2119 [RFC2119].
> +   
> +--
> +jgs: please update to use current BCP 14 boilerplate. 
> +--


Done


> 2.  Problem Statement
> 
> @@ -291,6 +295,22 @@
>topology, we can have efficient flooding and retain all of the
>resilience of existing protocols.  A node that supports flooding on
>the decoupled flooding topology is said to support dynamic flooding.
> +--
> +jgs: "scalable network" seems wrong. "Scaled network" is what a lot of
> +people would say, and I wouldn't openly object to it, although I'd hold
> +my nose and make a bad face. Perhaps,
> +
> +OLD:
> +   We have observed that the combination of the dense topology and
> +   flooding on the physical topology in a scalable network is sub-
> +   optimal.
> +   
> +NEW:
> +   We have observed that the combination of the dense topology and
> +   flooding on the physical topology is sub-
> +   optimal for network scaling.
> +--
> +


Done


>With dynamic flooding, the flooding topology is computed within an
>IGP area with the dense topology either centrally on an elected node,
> @@ -301,11 +321,11 @@
>operation.  If the flooding topology is computed in a distributed
>fashion, we call this the distributed mode of operation.  Nodes
>within such an IGP area would only flood on the flooding topology.
> -   On links outside of the normal flooding topology, normal database
> +   On links outside of the flooding topology, normal database
>synchronization mechanisms (i.e., OSPF database exchange, IS-IS
>CSNPs) would apply, but flooding may not.  Details are described in
>Section 6.  New link state information that arrives from outside of
> -   the flooding topology suggests that the sender has a different or no
> +   the flooding topology suggests that the sender has different or no
>flooding topology information and that the link state update should
>be flooded on the flooding topology as well.


Done


> @@ -317,6 +337,18 @@
>topology is stable.  The speed of the computation and its
>distribution, in the case of a centralized mode, is not a significant
>issue.
> +--
> +jgs: I think this is a little bit too terse, specifically the referent
> +of "it" isn't immediately obvious. Perhaps,
> +
> +NEW:
> +   Since the flooding topology is computed prior to topology changes, 
> +   the effort required to compute it
> +   does not factor into the convergence time and can be done when the
> +   topology is stable.  The speed of the computation and its
> +   distribution, in the case of a centralized mode, is not a significant
> +   issue.
> +--


Done


>If a node does not have any flooding topology information when it
>receives new link state information, it should flood according to
> @@ -383,6 +415,12 @@
>can remain stable in this condition is unknown and may be very
>dependent on the number and location of the nodes that support
>Dynamic Flooding.
> +--
> +jgs: Is the stability concern solely about scalability? Because, on the
> +face of it, "stability is unknown" sounds more alarming than that. If
> +it’s only scalability, some rewording seems indicated to help calm the
> +reader.
> +--


Flooding at small scale is never a problem, so yes, the concern is always about 
flooding
at large scale.

Reworded to: 
  Whether or not the
  network can remain stable in this condition is very
  dependent on the number and location of the nodes that
  support Dynamic Flooding.

It would be disingenous to suggest that this situation is stable. If the clique 
of 
legacy flooding is large enough, then havoc will undoubtedly ensue. Simply 
partitioning cliques 
of legacy flooding with boundaries of dynamic flooding is not sufficient: a 
single dynamic 
flooding system in a sea of legacy flooding only produces legacy flooding. It 
takes 
large swaths of dynamic flooding to encapsulate the churn of legacy flooding to 
give 
stability.


> @@ -476,7 +514,7 @@
>Similarly, if additional redundancy is added to the flooding
>topology, specific nodes in that topology may end up with a very high
>degree.  This could result in overloading the control plane of those
> -   nodes, resulting in poor convergence.  Thus, it may be optimal to
> +   nodes, resulting in poor convergence.  Thus, it may be preferable to
>have an upper bound on the degree of nodes in the flooding topology.
>Again, the optimal trade-off between graph diameter, node degree,
>convergence time, and topology computation time is for further study.


Done


> @@ -523,6 +561,9 @@
>topologies that

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Tony Li]

Paul,

There’s really no need for that to be a ‘MUST’. If multiple systems are 
advertising different proxy system identifiers, it should not 
cause confusion because all systems in the area should only use the identifier 
advertised by the area leader.  The other values are
irrelevant and should be ignored.

The only sane case where this might happen is if an area is being reconfigured 
to use a different proxy system identifier. This is a rare
case, to be sure, but it is definitely not an error. Thus, saying ‘MUST’ seems 
unnecessary.  Sane network managers should get the area
back into a consistent state in short order.

Regards,
Tony


> On Jan 21, 2024, at 5:52 PM, Paul Wouters  wrote:
> 
> 
> 
>> On Jan 21, 2024, at 20:45, Tony Li  wrote:
>> 
>> 
>> 
>> Hi Paul,
>> 
>> Already done.  Please see -12.
> 
> Thanks, I had a look. Why did the MUST get changed to a SHOULD? It is okay to 
> state a MUST as well as an action when that MUST is violated ?
> 
> Or was there another reason to change it ?
> 
> Paul
> 
> 
>> 
>> Thanks,
>> Tony
>> 
>> 
>>> On Jan 21, 2024, at 4:48 PM, Paul Wouters  wrote:
>>> 
>>> These changes look fine to me. Please cut another draft and I will update 
>>> my ballot to No Objection.
>>> 
>>> Paul
>>> 
>>> 
>>> 
>>> On Tue, Jan 9, 2024 at 4:15 PM Tony Li >> <mailto:tony...@tony.li>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> On second thought, I would like to retract and amend part of my answer to 
>>>> Paul.
>>>> 
>>>> 
>>>> >> I have a few minor discusses, which could be just because I'm not an 
>>>> >> ISIS
>>>> >> expert. Please bear with me :)
>>>> >> 
>>>> >>   Multiple proxy system identifiers in a single area is a
>>>> >>   misconfiguration and each unique occurrence SHOULD be logged.
>>>> >> 
>>>> >> This does not really answer what systems should do in this case? Use 
>>>> >> none
>>>> >> of them? What would the implication be? Use the one advertised by most 
>>>> >> nodes?
>>>> >> What would the risk be with that? The answers would be great additions 
>>>> >> to the
>>>> >> Security Considerations :)
>>>> > 
>>>> > 
>>>> > I propose to amend this to read:
>>>> > 
>>>> >  Multiple proxy system identifiers in a single
>>>> >   area is a misconfiguration and each unique occurrence
>>>> >   SHOULD be logged and the Area Leader MUST NOT generate the
>>>> >  Proxy LSP.
>>>> 
>>>> 
>>>> My proposal is unnecessarily draconian and disruptive. A better approach 
>>>> would be:
>>>> 
>>>>Multiple proxy system identifiers in a single
>>>>area is a misconfiguration and each unique occurrence
>>>>SHOULD be logged. Systems should use the proxy system
>>>>identifier advertised by the Area Leader.
>>>> 
>>>> I will maintain an increased level of caffeination. My apologies for the 
>>>> confusion.
>>>> 
>>>> Regards,
>>>> Tony
>>>> 
>>>> 
>> 

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

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Tony Li]

Hi Paul,

Already done.  Please see -12.

Thanks,
Tony


> On Jan 21, 2024, at 4:48 PM, Paul Wouters  wrote:
> 
> These changes look fine to me. Please cut another draft and I will update my 
> ballot to No Objection.
> 
> Paul
> 
> 
> 
> On Tue, Jan 9, 2024 at 4:15 PM Tony Li  <mailto:tony...@tony.li>> wrote:
>> 
>> Hi all,
>> 
>> On second thought, I would like to retract and amend part of my answer to 
>> Paul.
>> 
>> 
>> >> I have a few minor discusses, which could be just because I'm not an ISIS
>> >> expert. Please bear with me :)
>> >> 
>> >>   Multiple proxy system identifiers in a single area is a
>> >>   misconfiguration and each unique occurrence SHOULD be logged.
>> >> 
>> >> This does not really answer what systems should do in this case? Use none
>> >> of them? What would the implication be? Use the one advertised by most 
>> >> nodes?
>> >> What would the risk be with that? The answers would be great additions to 
>> >> the
>> >> Security Considerations :)
>> > 
>> > 
>> > I propose to amend this to read:
>> > 
>> >  Multiple proxy system identifiers in a single
>> >   area is a misconfiguration and each unique occurrence
>> >   SHOULD be logged and the Area Leader MUST NOT generate the
>> >  Proxy LSP.
>> 
>> 
>> My proposal is unnecessarily draconian and disruptive. A better approach 
>> would be:
>> 
>>Multiple proxy system identifiers in a single
>>area is a misconfiguration and each unique occurrence
>>SHOULD be logged. Systems should use the proxy system
>>identifier advertised by the Area Leader.
>> 
>> I will maintain an increased level of caffeination. My apologies for the 
>> confusion.
>> 
>> Regards,
>> Tony
>> 
>> 

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

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS and COMMENT)

[Tony Li]

Hi Roman,


>>> -- What are the relevant pointers to IS-IS security considerations?
>> 
>> 
>> AFAIK, there is no overall document for IS-IS’ security architecture. The 
>> only
>> pointers I can suggest are to RFC 5304 and 5310.  I will happily add 
>> references
>> to these if folks feel that’s helpful.
> 
> 
> Thanks for this explanation.  I clear on this point.  Adding those references 
> to the SecCons would be helpful.


Added.

Tony

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

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-12.txt

[Tony Li]

Another update addressing IESG comments.

T


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-12.txt
> Date: January 18, 2024 at 10:40:00 AM PST
> To: "Gyan S. Mishra" , "Gyan Mishra" 
> , "Sarah Chen" , "Tony Li" 
> , "Vivek Ilangovan" 
> 
> A new version of Internet-Draft draft-ietf-lsr-isis-area-proxy-12.txt has been
> successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 12
> Title:Area Proxy for IS-IS
> Date: 2024-01-18
> Group:lsr
> Pages:20
> URL:  
> https://www.ietf.org/archive/id/draft-ietf-lsr-isis-area-proxy-12.txt
> Status:   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-area-proxy-12
> 
> Abstract:
> 
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that allow level 1 areas to provide transit, yet
>   only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> 
> The IETF Secretariat
> 
> 

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

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-11.txt

[Tony Li]

Hi,

This version addresses the comments from the IESG review.

Other comments?

Regards,
Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-11.txt
> Date: January 9, 2024 at 3:32:24 PM PST
> To: "Gyan S. Mishra" , "Gyan Mishra" 
> , "Sarah Chen" , "Tony Li" 
> , "Vivek Ilangovan" 
> 
> A new version of Internet-Draft draft-ietf-lsr-isis-area-proxy-11.txt has been
> successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 11
> Title:Area Proxy for IS-IS
> Date: 2024-01-09
> Group:lsr
> Pages:20
> URL:  
> https://www.ietf.org/archive/id/draft-ietf-lsr-isis-area-proxy-11.txt
> Status:   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-area-proxy-11
> 
> Abstract:
> 
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that allow level 1 areas to provide transit, yet
>   only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> 
> The IETF Secretariat
> 
> 

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

Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-area-proxy-10: (with COMMENT)

[Tony Li]

Hi Murray,

Thank you for your comments.

> --
> COMMENT:
> --
> 
> Section 7 creates a registry whose policy is partly Expert Review, but doesn't
> give any particular guidance to the Designated Experts about what qualifying
> criteria might be.  Are there any that should be included?  I also suggest
> removing the names of proposed designated experts; that's appropriate for the
> shepherd writeup or an email and doesn't need to be in the document directly.


Names removed. I’ve got no specific criteria that I’d like to suggest.


> The SHOULD in Section 4.2 is bare.  When might an implementer or operator
> deviate from that advice?  If there's no legitimate condition, maybe it should
> be a MUST, or if it really doesn't matter, a MAY.


In this particular case, the primary reason would be a reconfiguration of the 
domain.

Other than operational consistency, there is no good reason to make this a 
‘MUST’. 
Everything should operate fine if the configurations are inconsistent. The 
information
should be taken from the Area Leader and the remaining information should be 
ignored.


> I actually have the same question about most of the 30+ SHOULDs in this
> document.  I wasn't able to tell just from the text in many cases what damage
> to interoperability I might trigger if I deviate from the advice.  And in the
> aggregate, as an implementer, I could do none of them and still claim I'm
> implementing this specification.  Is that intentional?


Yes. We like to be as liberal as possible.

Regards,
Tony

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

Re: [Lsr] Genart last call review of draft-ietf-lsr-isis-area-proxy-10

[Tony Li]

Hi Peter,

Thank you for your comments.

> Page 4, second paragraph, second sentence: change "MPLS based" to 
> "MPLS-based".


Fixed


> Page 4, section 1.1: in the text version that I read, the boilerplate contains
> the link "(https://tools.ietf.org/html/bcp14)". While this is found as a
> hyperlink in the PDF and HTML versions, I don't believe it should appear in 
> the
> text version. I don't know if this is a tool issue, but recent RFCs that I
> downloaded did not contain it. The hyperlink appears to cause idnits to
> complain about incorrect boilerplate text.


Fixed.


> Page 6, 1st paragraph, 1st sentence: change "i.e.  Ethernets" to "i.e.,
> Ethernets", which is to say, change the first space to a comma.


Fixed.


> Page 9, last paragraph, last sentence: change "implementation-dependent" to
> "implementation dependent”.


Fixed.

Thank you!
Tony




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

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS and COMMENT)

[Tony Li]

Hi Roman, Alexy,

Thank you for your comments.

> --
> DISCUSS:
> --
> 
> ** Section 4.3.  Do all the candidates need the Area Proxy System Identifier
> TLVs need the same system identifier?


I’m not sure I understand the question. Let me prattle on a bit and please let 
me know
if I do not address the question.

Vanilla IS-IS requires that each node in the routing domain have a unique 
system identifier.
This is unchanged.

Area Proxy extends this by requiring an additional system identifier for the 
Area Proxy. This is 
the Area Proxy System Identifier. This is normally advertised by the Area 
Leader so that all 
Interior Nodes know the value and it’s used by Interior Edge Nodes.  It’s a 
good idea
to have multiple candidates for Area Leader for resiliency, and having them all 
configured
with the same Area Proxy System Identifier is strongly preferred out of 
consistency. However,
it is NOT required. It is not an error for there to be multiple different 
candidate Area Proxy System
Identifiers.  In fact, this situation might happen if someone has decided to 
change the
Area Proxy System Identifier and is in the midst of reconfiguring part of the 
routing domain.

This does not cause confusion because Area Leader election is going to elect a 
single leader
and all systems will use the Area Proxy System Identifier that the leader is 
advertising.

Yes, if there is a change in leader, there may be a transient change in the 
Area Proxy System
Identifier. This would cause a set of adjacency flaps, just as changing any 
regular system identifier 
would. 


> -- Section 4.2 says “For consistency, all Area Leader candidates SHOULD be
> configured with the same Proxy System ID, Proxy Hostname, and any other
> information that may be inserted into the Proxy LSP.”


The rationale is similar to the above. Is there a separate question?


> -- Section 4.3.1 says: “All candidates advertising the Area Proxy System
> Identifier TLV MUST be advertising the same system identifier.”


I will relax this to a SHOULD.


> The first statement suggests that consistency might not always be required, 
> but
> the second statement is clear that it always must be the same identifier.
> 
> ** Section 8.  The following statement doesn’t appear to be accurate.
> 
> 8.  Security Considerations
> 
>   This document introduces no new security issues.  Security of routing
>   within a domain is already addressed as part of the routing protocols
>   themselves.  This document proposes no changes to those security
>   architectures.
> 
> -- Aren’t a few the filtering activities described in Section 5.2
> security-related?


No. These are key for ensuring the benefits of Area Proxy, most especially 
scalability, 
but if they are violated, it is not necessarily catastrophic.  

Some examples:

- If the L1 LSP of an Inside Router is leaked outside of the area, then it 
would be a 
protocol error, but other routers should recognize that they are not part of 
that area and 
ignore the LSP.

- If the L2 LSP of an Inside Router is leaked outside of the area, then it 
would be accepted
by other routers, but it would have no two-way adjacencies with anything else 
in L2 and
effectively be disconnected from the topology.

- Incorrect PSNP or CSNPs would prompt the receiving system to send PSNPs for 
Inside LSPs, but this would not per se cause problems.


> -- What are the relevant pointers to IS-IS security considerations?


AFAIK, there is no overall document for IS-IS’ security architecture. The only 
pointers I can
suggest are to RFC 5304 and 5310.  I will happily add references to these if 
folks feel that’s helpful.


> --
> COMMENT:
> --
> 
> Thank you to Alexey Melnikov for the SECDIR review.
> 
> ** Section 4.3.1
>   However, before withdrawing the Area Proxy
>   System Identifier, an implementation SHOULD protect against
>   unnecessary churn from transients by delaying the withdrawal.  The
>   amount of delay is implementation-dependent.
> 
> Are there any guidelines on how the delay period should be computed?


I don’t have any specific suggestions. My implementation practice is to
apply binary exponential backoff, with some ridiculous upper bound, but the
specifics are well outside of the boundaries of a protocol spec.


> ** Section 4.4.4.
>   An entry for a neighbor in both the IS Neighbors TLV and the Extended
>   IS Neighbors would be functionally redundant, so the Area Leader
>   SHOULD NOT do this.
> 
> Under what circumstances would this advice be ignored (i.e., why not a MUST)?


This is not a MUST because it’s a redundancy, not an error.


> ** Section 4.4.5 and 4.4.6 describe various behavior where fields “SHOULD” be
> copied.  What governs the choice of not 

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Tony Li]

Hi all,

On second thought, I would like to retract and amend part of my answer to Paul.


>> I have a few minor discusses, which could be just because I'm not an ISIS
>> expert. Please bear with me :)
>> 
>>   Multiple proxy system identifiers in a single area is a
>>   misconfiguration and each unique occurrence SHOULD be logged.
>> 
>> This does not really answer what systems should do in this case? Use none
>> of them? What would the implication be? Use the one advertised by most nodes?
>> What would the risk be with that? The answers would be great additions to the
>> Security Considerations :)
> 
> 
> I propose to amend this to read:
> 
>  Multiple proxy system identifiers in a single
>   area is a misconfiguration and each unique occurrence
>   SHOULD be logged and the Area Leader MUST NOT generate the
>  Proxy LSP.


My proposal is unnecessarily draconian and disruptive. A better approach would 
be:

   Multiple proxy system identifiers in a single
   area is a misconfiguration and each unique occurrence
   SHOULD be logged. Systems should use the proxy system
   identifier advertised by the Area Leader.

I will maintain an increased level of caffeination. My apologies for the 
confusion.

Regards,
Tony


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

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)

[Tony Li]

Hi Paul,

Thank you for your comments.

> --
> DISCUSS:
> --
> 
> I have a few minor discusses, which could be just because I'm not an ISIS
> expert. Please bear with me :)
> 
>Multiple proxy system identifiers in a single area is a
>misconfiguration and each unique occurrence SHOULD be logged.
> 
> This does not really answer what systems should do in this case? Use none
> of them? What would the implication be? Use the one advertised by most nodes?
> What would the risk be with that? The answers would be great additions to the
> Security Considerations :)


I propose to amend this to read:

   Multiple proxy system identifiers in a single
   area is a misconfiguration and each unique occurrence
   SHOULD be logged and the Area Leader MUST NOT generate the
   Proxy LSP.


>The Area Leader and other candidates for Area Leader MAY withdraw
>the Area Proxy System Identifier when one or more Inside Routers
>are not advertising the Area Proxy Router Capability. This will
>disable Area Proxy functionality.
> 
> Wouldn't this allow a malicious Inside Router to completely disable the Area
> Proxy functionality? Could this be part of an attack? Can this be mitigated
> somehow? Is there something to say about this for the Security Considerations?



Before we get into this specific question, we should talk about the security of
link state protocols in general. We do have authentication mechanisms in place 
to
ensure that all routers are known participants. However, once inside that 
crunchy
shell of authentication, there is a very soft, gooey interior.

Any node can advertise anything. Sane or not. Correct or not. Consistent or 
not. 
And an authenticated node can trivially DoS attack the entire domain. 
There are even configuration commands defined to do so ( “redistribute bgp …”).

This applies to both IS-IS and OSPF.

Now, to your point: yes, a malicious Inside Router can trivially disable Area 
Proxy 
functionality, there is no question about that. Could that be an attack? Yes, 
certainly.
It would be quite obvious and public as all of the LSDB is completely visible.

Is this worth mitigating? IMHO no. This is no better or worse than any other 
attack
that a malicious IS-IS router can launch. It’s exactly on-par with everything 
else
that’s in the protocol today.

Is this worth discussing in the Security Considerations?  IMHO no.  We decided a
long time ago that we were not going to chase the Byzantine Generals problem 
and 
that hasn’t proven to be problematic in practice.


> 
>0   1   2
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Type | Length|Proxy System ID|
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   Proxy System Identifier continued   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> This diagram seems incorrect. It shows 4 fields instead of 3.
> I suggest using:
> 
>0   1   2
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Type | Length|   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proxy System Identifier   |
>   |   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Thank you for the suggestion, adopted.


Tony

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

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-10.txt

[Tony Li]

FYI:

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-10.txt
> Date: December 7, 2023 at 6:00:28 PM PST
> To: "Gyan S. Mishra" , "Gyan Mishra" 
> , "Sarah Chen" , "Tony Li" 
> , "Vivek Ilangovan" 
> 
> A new version of Internet-Draft draft-ietf-lsr-isis-area-proxy-10.txt has been
> successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 10
> Title:Area Proxy for IS-IS
> Date: 2023-12-07
> Group:lsr
> Pages:20
> URL:  
> https://www.ietf.org/archive/id/draft-ietf-lsr-isis-area-proxy-10.txt
> Status:   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-area-proxy-10
> 
> Abstract:
> 
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that allow level 1 areas to provide transit, yet
>   only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> 
> The IETF Secretariat
> 
> 

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

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

[Tony Li]

Hi John,

>>> @@ -302,14 +315,23 @@
>>>  value of the SRGB advertised by all Inside Nodes MUST start at the
>>>  same value.  The range advertised for the area will be the minimum of
>>>  all Inside Nodes.
>>> ++---
>>> +jgs: shouldn't the document say something about what to do if
>>> +either one of the MUST requirements isn't met?
>>> ++---
>> 
>> 
>> If either is not met, it would be a protocol error and major malfunctions 
>> will occur.
>> The network manager should remedy the problem. I’m not sure that needs to be
>> called out.
>> 
>> If you’re suggesting that implementations should complain if those 
>> constraints are
>> not met, we did not specify that as that would require a walk through the 
>> LSDB
>> that is not otherwise required.
> 
> Doesn't the area leader already have to do an operation like that, to 
> determine what range to advertise? I had expected to be told what the area 
> leader is supposed to do if it encounters non-overlapping SRGB as it looks 
> for the minimum mentioned in the quoted text. Halt and catch fire? Give up 
> and log an error? Something else?


Not strictly, as one can cheat.  However, that’s probably cheating a bit too 
much.  I will add text suggesting logging and giving up.


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


Sure.


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


Exactly


>> We intentionally selected 2119 keywords because we wanted to explicitly
>> say what is permissible.
>> 
>> Again, the protocol would work syntactically and semantically if things are
>> omitted, but not meet network architectural requirements. Additionally,
>> we did not want to preclude filtering, so we did not think that ‘MUST’ was 
>> called
>> for.
> 
> I could swallow your justification for the various SHOULDs because you said 
> (my paraphrase) that there isn't any single one of them that's of the essence 
> for the utility of the protocol. However, if you don't advertise either of 
> the IS Neighbors or Extended IS Neighbors TLVs, I don't think you have a 
> useful routing protocol, do you? So, even though neither one of them, 
> individually, is of the essence, collectively they still are. I don't think 
> your text captures this. An example of text that would address this concern 
> is,
> 
> OLD:
>   An entry for a neighbor in both the IS Neighbors TLV and the Extended
>   IS Neighbors would be functionally redundant, so the Area Leader
>   SHOULD NOT do this.
> 
> NEW:
>   An entry for a neighbor in both the IS Neighbors TLV and the Extended
>   IS Neighbors would be functionally redundant, so the Area Leader
>   SHOULD NOT do this. Although considered in isolation, either of these 
>   two TLV types may be omitted, at least one MUST be included.
> 
> That's only an illustration, I don't think it's the most artful way to do it. 
> My own preference would be something more like, change both MAY to “can”, and 
> add something like,
> 
>   The Area Leader MAY omit either the IS Neighbors TLV or the Extended 
>   IS Neighbors TLV, but it MUST include at least one of them.
> 
> If you're stuck on having each subsection stand on its own, you’d put the 
> sentence in twice, once each. But I think you aren't stuck on that, because 
> you only include the "functionally redundant" paragraph I have quoted once.


I can live with your proposal.

Tony


_

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

[Tony Li]

Hi John,

Thank you for your comments and suggestions.  I’m incorporating most of 
them and only responding to ones that warrant further discussion.

> ++---
> +jgs: I suggested changing 'should' to 'will' for two reasons. First,
> +and less important, there's the annoying risk of conflation with the
> +RFC 2119 SHOULD. Second, and more important, I think what you're
> +saying is that by using the proxy system ID, as a matter of course
> +this is what will happen. "Should" makes it sound like maybe it will
> +happen, maybe it won't. But in fact, if the outside edge routers do
> +anything other than what you've written, that would be a protocol 
> +error, wouldn't it? 
> ++---


Yes, it would. I’m fine with the wording change.


> @@ -302,14 +315,23 @@
>value of the SRGB advertised by all Inside Nodes MUST start at the
>same value.  The range advertised for the area will be the minimum of
>all Inside Nodes.
> ++---
> +jgs: shouldn't the document say something about what to do if 
> +either one of the MUST requirements isn't met?
> ++---


If either is not met, it would be a protocol error and major malfunctions will 
occur. 
The network manager should remedy the problem. I’m not sure that needs to be 
called out.

If you’re suggesting that implementations should complain if those constraints 
are
not met, we did not specify that as that would require a walk through the LSDB
that is not otherwise required.


> @@ -533,6 +559,16 @@
>   Flags: 1 octet.
> 
>   SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1
> ++---
> +jgs: I'm not very happy with this definition for the field. I realize
> +it was copied verbatim from RFC 8667, I've started a discussion with
> +the authors of that RFC,
> +https://mailarchive.ietf.org/arch/msg/lsr/56_LEEZvHDHrnkC98f7BtpOkkY0/
> +
> +Perhaps cite RFC 8667 section 2.1 instead. It's at least equally, and
> +arguably more correct, and if there is an erratum it could benefit
> +from that.
> ++---


Per our private discussion, I’ve left this unchanged.

I believe that amending the title of 2.1.1.1 is both necessary and sufficient. 
I propose:
“V-Flag, L-Flag, and the SID/Index/Label Field”.


> ++---
> +jgs: of greater concern, I'm wondering why you've elected to use
> +SHOULD and not MUST in many of the subsections. Is it the case that
> +for each field specified as SHOULD, if any or all of these are
> +omitted, the protocol will still operate correctly and usefully?
> +Is it the case for each field specified as SHOULD, the authors think
> +there are plausible circumstances under which the right thing would be
> +to omit the relevant field?
> ++---


A combination of things: first, omitting any one of them will not break things 
syntactically or from a protocol or feature semantics perspective. However,
they may be required from a network architecture perspective in some 
circumstances
and may become a scalability barrier in different circumstances. It seems like 
implementations may want to exhibit some latitude here.


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


Yes, we would expect one and not both. There’s a sentence that even says
that. We intentionally selected 2119 keywords because we wanted to explicitly
say what is permissible.

Again, the protocol would work syntactically and semantically if things are
omitted, but not meet network architectural requirements. Additionally,
we did not want to preclude filtering, so we did not think that ‘MUST’ was 
called 
for.



> @@ -754,6 +846,15 @@
>If the inside area supports SRv6, the Area Leader SHOULD copy all
>SRv6 locator TLVs [I-D.ietf-lsr-isis-srv6-extensions] advertised by
>Inside Routers to the Proxy LSP.
> ++---
> +jgs: Really? Isn't this tantamount to saying, advertise at least one 
> +route for every IS in t

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

[Tony Li]

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] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Tony Li]

Hi Linda,

> I have the following concerns about the approach proposed by  this draft:
>  
> 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.


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

This would not be an improvement.

Tony


___
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)

[Tony Li]

Hi Bruno,

No, we are not going to document the behavior of every implementation for every 
TLV, sub-TLV, and sub-sub-TLV for you. We don’t have that kind of access nor 
would we get permission to do so. And we’re not young enough.

The point of clearly advertising capabilities is so that implementations have a 
scalable, automated way of providing what you ask for: information to network 
management. Modern networking is all about automation, and we are trying to 
push in that direction.

Regards,
Tony

> On Nov 30, 2023, at 2:50 AM, bruno.decra...@orange.com wrote:
> 
> Hi authors,
>  
> We are documenting existing behavior, codifying what we believe most 
> implementations are already doing
>  
> Could the authors share with the WG what are those existing behaviors (TLVs 
> supporting MP-TLV) and implementations?
>  
> Many be this is a reason for some disconnect as
> On one hand, if all implementations already support MP-TLV for all TLVs 
> indicated in this draft, then there is less deployment issues/risks. 
> (Although there are still some risks as not all nodes will get the support at 
> the same time, in particular for legacy platforms which will lack the MP TLV 
> support for years)
> On the other hand, if only a couple of implementations support MP-TLV for a 
> couple of TLVs,  the risk seems much higher.
>  
> If this is not known (1), we can’t assume that this is safe and deployable 
> without risk.
>  
> (1) or not sharable for some reasons, although a priori vendors should be 
> proud of their innovations
>  
> If the MP-TLV support capability declaration  doesn’t mean support all 
> relevant TLVs, and conform to the draft can’t assure the interoperability, 
> then, what the purpose of this draft?
> Same question with :s/draft/capability
> Although I believe I had already raised that point.
>  
> Regards,
> --Bruno
>  
> From: Lsr  On Behalf Of Tony Li
> Sent: Thursday, November 30, 2023 5:06 AM
> To: Aijun Wang 
> 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 Aijun,
>  
> If the MP-TLV support capability declaration  doesn’t mean support all 
> relevant TLVs, and conform to the draft can’t assure the interoperability, 
> then, what the purpose of this draft?
>  
>  
> We are documenting existing behavior, codifying what we believe most 
> implementations are already doing, and documenting the direction that we 
> think we should be going.
>  
> 
> 
> If you persist this direction, as proposed by Bruno, I think that documents 
> the capabilities(includes the definition of the key) for every TLV in one 
> Yang file(draft-isis-pics-multi-TLV”?) maybe more better.
>  
>  
> Then YANG model for reporting capabilities is a mostly orthogonal document.
>  
> 
> 
> The operator can compare such yang files from different vendor, and if they 
> support the multipart of the same TLV, and the key is same, then the operator 
> can safely enable the sending and receiving of the multi-part of this TLV.
>  
>  
> That alone is not sufficient.
>  
> 
> 
> Or else, we should think other solution to solve this issue.
>  
>  
> There is no other solution.
>  
> Regards,
> Tony
>  
>  
> 
> 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] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Tony Li]

Hi Aijun,

> If the MP-TLV support capability declaration  doesn’t mean support all 
> relevant TLVs, and conform to the draft can’t assure the interoperability, 
> then, what the purpose of this draft?


We are documenting existing behavior, codifying what we believe most 
implementations are already doing, and documenting the direction that we think 
we should be going.


> If you persist this direction, as proposed by Bruno, I think that documents 
> the capabilities(includes the definition of the key) for every TLV in one 
> Yang file(draft-isis-pics-multi-TLV”?) maybe more better.


Then YANG model for reporting capabilities is a mostly orthogonal document.


> The operator can compare such yang files from different vendor, and if they 
> support the multipart of the same TLV, and the key is same, then the operator 
> can safely enable the sending and receiving of the multi-part of this TLV.


That alone is not sufficient.


> Or else, we should think other solution to solve this issue.


There is no other solution.

Regards,
Tony


___
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)

[Tony Li]

Hi Aijun,



> On Nov 26, 2023, at 7:05 PM, Aijun Wang  wrote:
> 
> Some additional questions:
>  
> The draft say “The contents of a multi-part TLV MUST be processed as if they 
> were concatenated. 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.”
>  
> 1) How to deal with the TLV that has no key information? 


That’s the easiest case: the content between instances is not correlated, so 
each TLV can be individually processed independently.


> 2) And, to support multi-part TLV,  the key information (if the TLV has 
> such information) for each applied TLV must also be standardized, or else, 
> there will be error.
> The draft wants to just avoid to tackle such issues(as stated in draft 
> “Having inconsistent information in different parts of a MP-TLV is an error 
> and is out of scope for this document.), but it should be the MUST part of 
> the solution. 


I respectfully disagree. Having a single RFC that sorts through all of that is 
wholly unwieldy and guaranteed to be highly erroneous.  It’s far better to 
write separate documents that can be individually and carefully crafted and 
reviewed.

>  
> Or else, how to assure the interoperability?


Interoperability is never assured by documents. Careful thought, coding, and 
testing are required. This has not changed.

T


>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> 发件人: forwardingalgori...@ietf.org  
> [mailto:forwardingalgori...@ietf.org] 代表 Aijun Wang
> 发送时间: 2023年11月24日 16:11
> 收件人: 'Yingzhen Qu'  >; draft-pkaneria-lsr-multi-...@ietf.org 
> ; 'lsr'  >
> 主题: [Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
> 12/09/2023)
>  
> Do not support its adoption.
>  
> The draft just enumerate the requirements of MP-TLV support for relevant 
> TLVs, it is not the general solution to the issue.
>  
> There is no practical way in the draft to assure the current and future 
> implementation conforms to the newly defined explicit requirements, because 
> the MP-TLV Support sub-TLV is not per-TLV basis, and as stated in the draft, 
> one implementation declares support “MP-TLV” can’t assure it supports all 
> relevant TLVs. --“It is understood that in reality, a given 
> implementation might limit MP-TLV support to particular TLVs based on the 
> needs of the deployment scenarios in which it is used”-Will there be many 
> interoperability issues arises then? And also varies loop accidents within 
> the network when all of vendors declare they support “MP-TLV” but not all of 
> the relevant TLVs?
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> 发件人: forwardingalgori...@ietf.org  
> [mailto:forwardingalgori...@ietf.org] 代表 Yingzhen Qu
> 发送时间: 2023年11月18日 1:24
> 收件人: draft-pkaneria-lsr-multi-...@ietf.org 
> ; lsr  >
> 主题: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
> 12/09/2023)
>  
> Hi,
>  
> This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
> draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) 
> 
>  
> Please send your support or objection to the list before December 9th, 2023. 
> An extra week is allowed for the US Thanksgiving holiday.
>  
> Thanks,
> Yingzhen 

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

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

[Tony Li]

Hi Xiaohu,

What you’re proposing is already described in IS-IS Mesh Groups 
(https://www.rfc-editor.org/rfc/rfc2973.html) and improved upon in Dynamic 
Flooding 
(https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding).

Regards,
Tony


> On Nov 23, 2023, at 8:29 AM, xuxiaohu_i...@hotmail.com wrote:
> 
> Hi all,
> 
> Any comments or suggestions are welcome.
> 
> Best regards,
> Xiaohu
> 
> 
> 发件人: internet-dra...@ietf.org 
> 日期: 星期三, 2023年11月22日 11:37
> 收件人: Xiaohu Xu 
> 主题: New Version Notification for 
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> 
> A new version of Internet-Draft draft-xu-lsr-flooding-reduction-in-clos-01.txt
> has been successfully submitted by Xiaohu Xu and posted to the
> IETF repository.
> 
> Name: draft-xu-lsr-flooding-reduction-in-clos
> Revision: 01
> Title:Flooding Reduction in CLOS Networks
> Date: 2023-11-22
> Group:Individual Submission
> Pages:6
> URL:  
> https://www.ietf.org/archive/id/draft-xu-lsr-flooding-reduction-in-clos-01.txt
> Status:   
> https://datatracker.ietf.org/doc/draft-xu-lsr-flooding-reduction-in-clos/
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-xu-lsr-flooding-reduction-in-clos-01
> 
> Abstract:
> 
>In a CLOS topology, an OSPF (or ISIS) router may receive identical
>copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors.
>Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or
>LSP) simultaneously.  This results in unnecessary flooding of link-
>state information, which wastes the precious resources of OSPF (or
>ISIS) routers.  Therefore, this document proposes extensions to OSPF
>(or ISIS) to reduce this flooding within CLOS networks.  The
>reduction of OSPF (or ISIS) flooding is highly beneficial for
>improving the scalability of CLOS networks.
> 
> 
> 
> 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

Re: [Lsr] New Version Notification for draft-xu-lsr-fare-00.txt

[Tony Li]

Hi Xiaohu,

One way of achieving this would be to use the Unreserved Bandwidth TLV 
(https://datatracker.ietf.org/doc/html/rfc5305#autoid-10) to report the unused 
bandwidth on a link.

Then, you would have to explain how this does not become an oscillator. I’m not 
optimistic.

Regards,
Tony


> On Nov 23, 2023, at 8:27 AM, xuxiaohu_i...@hotmail.com wrote:
> 
> Hi all,
> 
> Any comments or suggestions are welcome.
> 
> Best regards,
> Xiaohu 
> 
> 
> 
> 发件人: internet-dra...@ietf.org 
> 日期: 星期五, 2023年11月24日 00:13
> 收件人: Xiaohu Xu 
> 主题: New Version Notification for draft-xu-lsr-fare-00.txt
> 
> A new version of Internet-Draft draft-xu-lsr-fare-00.txt has been successfully
> submitted by Xiaohu Xu and posted to the
> IETF repository.
> 
> Name: draft-xu-lsr-fare
> Revision: 00
> Title:Fully Adaptive Routing Ethernet
> Date: 2023-11-22
> Group:Individual Submission
> Pages:7
> URL:  https://www.ietf.org/archive/id/draft-xu-lsr-fare-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-xu-lsr-fare/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-xu-lsr-fare
> 
> 
> Abstract:
> 
>Large language models (LLMs) like ChatGPT have become increasingly
>popular in recent years due to their impressive performance in
>various natural language processing tasks.  These models are built by
>training deep neural networks on massive amounts of text data, often
>consisting of billions or even trillions of parameters.  However, the
>training process for these models can be extremely resource-
>intensive, requiring the deployment of thousands or even tens of
>thousands of GPUs in a single AI training cluster.  Therefore, three-
>stage or even five-stage CLOS networks are commonly adopted for AI
>networks.  The non-blocking nature of the network become increasingly
>critical for large-scale AI models.  Therefore, adaptive routing is
>necessary to dynamically load balance traffic to the same destination
>over multiple ECMP paths, based on network capacity and even
>congestion information along those paths.
> 
> 
> 
> 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

Re: [Lsr] draft-pkaneria-lsr-multi-tlv

[Tony Li]

Hi Bruno,

We are still waiting to hear whether or not you are in favor of adopting this 
document.

One might infer your intentions, but the chairs need it to be explicit.

Regards,
Tony


> On Nov 22, 2023, at 5:37 AM, bruno.decra...@orange.com wrote:
> 
> Hi authors,
>  
> Please find below some specific comments on the document.
>  
> Thank you for the effort put in the IANA section. (to indicate wo which 
> (sub-) TLV MPL applies to).
>  
> §1
> “However, this has not been done for many legacy TLVs, leaving the situation 
> somewhat ambiguous.”
> To me the current situation is not ambiguous. The behavior is defined in the 
> spec/RFC. If a behavior is not defined, then it’ is not specified and not 
> allowed.
> Please rephrase.
> --
> “The intent of this document is to clarify and codify the situation by 
> explicitly making multiple occurences of a TLV the mechanism for scaling TLV 
> contents, except where otherwise explicitly stated.”
> Similar comment. :s/clarify/specify
>  
> --
> “The mechanism described in this document has not been documented for all 
> TLVs previously”
> Similar comment.
> :s/documented/specified
>  
> --
> OLD: so it is likely that some implementations would not interoperate 
> correctly if these mechanisms were used without caution.
> NEW: so non compliant implementations would not interoperate correctly with 
> compliant implementations
> (alternatively, that part could be just removed)
>  
> --
> “The mechanism described in this document has been used explicitly by some 
> implementations, so this document is not creating an unprecedented mechanism.”
> Proprietary non-compliant implementations are not an excuse for RFC.
> If you need an introduction, you could to the existing TLV specified with MP. 
> (but since this is already stated at the beginning of this section IMO we can 
> just remove that part)
>  
> --
>  
> §4.1
> “It is RECOMMENDED that the link identifiers be the first sub-TLVs.”
>  
> For my information, why is so?
> As currently formulated implementations MUST support any order
> What the benefit of the ordering given that implementations MUST parse all 
> sub-TLVs?
>  
> --
> §4.1
>  
> “Optionally one or more of the following identifiers:”
> […]
> “The key information MUST be replicated identically.”
> Do you mean that all identifiers MUST be replicated?
> If so, could you please make this point even more explicit  e.g., “(i.e., 
> with all identifiers”)
>  
> --
> 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.”
>  
> Given that this section is the key normative part, I’m not found of the 
> “should”. I would suggest :s/should be/is  (but “MUST” also works for me)
> --
> §6
> “The lack of explicit indication of applicability of Multi-Part TLV 
> procedures to all codepoints to which such procedures could be applied 
> contributes to potential interoperability problems if/when the need arises to 
> advertise more than 255 bytes of information for such a codepoint.”
> Same comment. If it’s not specified in the existing RFC this is not 
> supported/compliant. This is not a “lack of indication of applicability”.
>  
> --
> “This document makes explicit the applicability of Multi-Part TLV procedures 
> for all existing codepoints”
> :s/makes explicit/specify
>  
> --
> §7.2 MP-TLV Capability Advertisement
>  
> “It is presumed that if such support is provided that it applies to all 
> relevant TLVs. It is understood that in reality, a given implementation might 
> limit MP-TLV support to particular TLVs based on the needs of the deployment 
> scenarios in which it is used.”
>  
> Let’s not presume anything. Let’s specify it. And we need to specify a clear 
> meaning for the capability, otherwise it has limited value.
> My preference would be that the meaning is “supports MP-TLV” for TLV x, y, z. 
> (or all TLVs). Alternatively, the value would carry the list of TLV 
> supporting MP-TLV (more complex but since it seems that no implementation 
> will act on the content that seems easy to implement). Alternatively, if 
> there is no clear meaning, let’s not bother with the capability.
>  
> Thanks,
> Regards,
> --Bruno
>  
> 
> Orange Restricted
> From: DECRAENE Bruno INNOV/NET
> Sent: Tuesday, November 21, 2023 1:51 PM
> To: 'Yingzhen Qu' mailto:yingzhen.i...@gmail.com>>; 
> draft-pkaneria-lsr-multi-...@ietf.org 
> 
> Cc: lsr mailto:lsr@ietf.org>>
> Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
> (11/17/2023 - 12/09/2023)
>  
> Hi all,
>  
>  
> I have some concerns with regards to the deployment of this extension in 
> brownfield multi-vendor networks as this could result in the formation of 
> persistent forwarding loops.
>  
> As a cons

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

[Tony Li]

Hi Bruno,

I’m in agreement with Les.  One more points below.


> Furthermore, it is highly unlikely that any implementation is going to 
> actually comply just because of our choice of adjective here.
> [Bruno] Exactly my above point: existing implementations may not bother and 
> claims compliancy anyway. So, what’s the problem with changing the text in 
> the draft?


I’m sorry for making a cultural reference, but the best way of explaining this 
is to cite the fairy tale, “The Boy Who Cried Wolf”. 
(https://www.storyarts.org/library/aesops/stories/boy.html).

If we cry “REQUIRED” when it’s not, then people will ignore us when it is. 
Therefore, we should only resort to “REQUIRED” when it is truly required for 
interoperability. Please see BCP 14.

Tony

___
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)

[Tony Li]

Hi Bruno,

Thank you for your comments.


> As a constructive proposal, and as mitigations, I would like the document be 
> improved with the following changes:
> Sending MUST be controlled by configuration [1]
> [1]
> OLD: It is RECOMMENDED that implementations which support the sending of 
> MP-TLVs provide configuration controls to enable/disable generation of 
> MP-TLVs.
> NEW: It is REQUIRED that implementations which support the sending of MP-TLVs 
> provide configuration controls to enable/disable generation of MP-TLVs.


As you know, some systems already generate multi-part TLVs. And they lack any 
controls for doing this today. The language that you’re suggesting would make 
these systems immediately out of compliance, thereby punishing them for 
providing leading technology. Furthermore, it is highly unlikely that any 
implementation is going to actually comply just because of our choice of 
adjective here. The control is clearly not necessary for interoperability and 
we should not overuse our ability to place requirements on implementations. We 
all know that the real power comes from customers who place requirements on 
vendors and the requirements that we place in RFCs are only meaningful when 
describing the requirements for correct operation of our protocols. 
Overextending ourselves dilutes our interoperability requirements.


> For existing TLVs (and “any level of sub-TLVs”), details the TLV which could 
> be advertised with no risks for the network and TLVs which must not be 
> advertised before all nodes be upgraded.


What is ’no risk’? We are not competent to make that assesment. That requires 
knowing everything about every implementation, past, present, and future and 
testing the full cross product of those implementations in all possible 
scenarios.


> Given this document typically may require global support before this be 
> enabled, I think this draft would be a good candidate for the addition of the 
> relevant yang module as per draft-qgp-lsr-isis-pics-yang [3]. I personally 
> don’t see a problem with adding a normative reference to an individual draft, 
> but if I’m wrong, an option for the chairs to consider would be to pause this 
> adoption call and start an adoption call for draft-qgp-lsr-isis-pics-yang.


That would stall this document indefinitely, pending progress on the YANG 
model. Please recall that this document is already two years old and that this 
is an adoption call, NOT WGLC.

The question on the table is not whether this document is perfect. The question 
is whether this is worth continuing to work on and whether this document is the 
correct basis for that work. I would like to see this document published 
sometime this century.

Regards,
Tony

___
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)

[Tony Li]

I support adoption as co-author.

T


> On Nov 17, 2023, at 9:23 AM, Yingzhen Qu  wrote:
> 
> Hi,
> 
> This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
> draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) 
> 
> 
> Please send your support or objection to the list before December 9th, 2023. 
> An extra week is allowed for the US Thanksgiving holiday.
> 
> Thanks,
> Yingzhen 

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

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

[Tony Li]

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


> On Nov 17, 2023, at 9:05 AM, Les Ginsberg (ginsberg)  
> wrote:
> 
> "No, I'm not aware of any IPR that applies to this draft"

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

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

[Tony Li]

Hi Acee,

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

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

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

Regards,
Tony


> On Nov 16, 2023, at 2:32 PM, Acee Lindem  wrote:
> 
> Speaking as a WG contributor: 
> 
> Hi Les, 
> 
> I think a simpler name is better - perhaps ietf-isis-feature-support.yang 
> with YANG prefix isis-fs would be better.  Which brings me to my next and 
> more important point… 
> 
> Like carbon neutrality, everyone at the LSR WG meeting who had an opinion 
> thought such a YANG model would be operationally useful. However, I think the 
> level of granularity is key. I believe that having a separate data node for 
> each TLV/sub-TLV as was done in the example ietf-isis-pics-sr-mpls.yang 
> module is way too granular to be useful. Rather, the YANG reporting should be 
> done at the feature level. Also, does a distinction need to be made as to 
> whether the IS-IS node supports the feature or both supports it and has it 
> enabled (as would be the case for non-backward compatible features)? 
> 
> Thanks, 
> Acee
> 
>> On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) 
>>  wrote:
>> 
>> Loa -
>> 
>> I agree with you that simply "IS-IS Support" may not be the best choice.
>> Although, the meeting minutes have not yet been posted, as I recall my 
>> response to Tony Li's suggestion of "IS-IS Support" was "Yes - something 
>> like that."
>> 
>> The draft authors have not yet discussed this - but we will and share the 
>> proposed new name.
>> Other suggestions welcomed.
>> 
>>   Les
>> 
>>> -Original Message-
>>> From: Lsr  On Behalf Of Loa Andersson
>>> Sent: Thursday, November 16, 2023 2:06 AM
>>> To: lsr@ietf.org
>>> Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
>>> 
>>> Working Group,
>>> 
>>> During the presentation of draft-qgp-lsr-isis-pics-yang there was a
>>> rather strong opposition in the chat against using the ISO-term "PICS"
>>> in an IETF document.
>>> 
>>> I think the term "Support" was suggested (excuse me if I missed
>>> something), but I'm not that impressed, and would rather like to see
>>> something like - "Supported Protocol Aspects".
>>> 
>>> /Loa
>>> --
>>> Loa Anderssonemail: l...@pi.nu
>>> Senior MPLS Expert  loa.pi...@gmail.com
>>> Bronze Dragon Consulting phone: +46 739 81 21 64
>>> 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt

[Tony Li]

Hi Eduard,

I know several different products that use different silicon on different line 
cards, ending up with different capabilities on different interfaces. 

This is more of a hardware issue than a software one.

Different chips will necessarily have different low layer micro-code. That 
already exists today, across vendors.

Tony


> On Aug 28, 2023, at 11:44 PM, Vasilenko Eduard 
>  wrote:
> 
> Hi Tony,
> Do you know any product that supports different label (or SID) stacks on 
> different PFEs? (Not mandatory to disclose the vendor)
> I remember many major upgrades for many vendors and all the time the whole 
> router supported the “common denominator”.
> Of course, it is possible to develop code and micro-code to support different 
> label stacks on different PFEs but looks like no one vendor has found a 
> business case for such a big development program.
> PS: I am not sure, I may missed a good example.
> Eduard
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Tony Li
> Sent: Tuesday, August 29, 2023 5:36 AM
> To: liu.ya...@zte.com.cn
> Cc: Les Ginsberg ; mpls ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for 
> draft-liu-lsr-mpls-inspection-msd-01.txt
>  
>  
> Hi Yao,
>  
> Please consider the case of a modular node with a number of different line 
> cards, where the line cards are based on different forwarding engines.
>  
> RLD needs to be link specific.
>  
> Regards,
> Tony
>  
> 
> 
> On Aug 28, 2023, at 6:55 PM,  <mailto:liu.ya...@zte.com.cn>>  <mailto:liu.ya...@zte.com.cn>> wrote:
>  
> Hi Les,
> 
> Thanks a lot for your review and comments.
> 
> This new MSD is a per-node capability just like ERLD-MSD, mainly because it 
> represents how many MPLS labels the node can read, and it is not related with 
> the links.
> 
> And the description in this draft you mentioned is written taking example by 
> RFC9088(section 4. Advertising ERLD Using IS-IS).
> 
> I'll explicitly state the scope of the new MSD in the next version. 
> 
>  
> 
> Best Regards,
> 
> Yao
> 
> Original
> From: LesGinsberg(ginsberg) mailto:ginsb...@cisco.com>>
> To: 刘尧00165286;m...@ietf.org  <mailto:m...@ietf.org>>;lsr@ietf.org mailto:lsr@ietf.org>>;
> Date: 2023年08月28日 20:57
> Subject: RE: [Lsr] Fw: New Version Notification for 
> draft-liu-lsr-mpls-inspection-msd-01.txt
> Yao –
>  
> Both RFC 8476(OSPF) and RFC 8491(IS-IS) define MSD advertisements with 
> per-link scope and per-node scope.
>  
> Your draft only states: 
>  
> “If a router has multiple interfaces with different capabilities of
>reading the maximum label stack depth, the router MUST advertise the
>smallest value found across all its interfaces.”
>  
> This suggests that you intend only to advertise a per-node capability – but 
> as you don’t explicitly state that – and you don’t provide a reason why a per 
> link capability isn’t applicable, I am unclear as to what your intentions are 
> here.
>  
> Could you clarify whether you intend to support both per link and per node 
> capability – and if not why not?
>  
> Thanx.
>  
>Les
>  
>  
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> liu.ya...@zte.com.cn <mailto:liu.ya...@zte.com.cn>
> Sent: Monday, August 28, 2023 12:33 AM
> To: m...@ietf.org <mailto:m...@ietf.org>; lsr@ietf.org <mailto:lsr@ietf.org>
> Subject: [Lsr] Fw: New Version Notification for 
> draft-liu-lsr-mpls-inspection-msd-01.txt
>  
> Hi All,
> 
> A new version of draft-liu-lsr-mpls-inspection-msd has just been uploaded.
> 
> In this document, a new type of MSD is defined to reflect the Readable Label 
> Depth(RLD), which helps in the MPLS MNA solution.
> 
> In this version, the main update is that some description is added to explain 
> why a new MSD is preferred instead of the ERLD-MSD.
> 
> Currently this new MSD is called Base MPLS Inspection MSD, it may be changed 
> to a more straightforward name like RLD-MSD based on the description in the 
> MNA architecture/solution document. 
> 
> Your comments and suggestions are more than welcome!
> 
>  
> 
> Thanks,
> 
> Yao
> 
> Original
> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> 
> mailto:internet-dra...@ietf.org>>
> Date: 2023年08月28日 14:55
> Subject: New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt
> A new version of Internet-Draft draft-liu-lsr-mpls-inspection-msd-01.txt has
> been successfully submitted by Yao Liu and posted to the
> IETF repository.
> 
> Name: draft-liu-lsr-mpls-inspection-msd
> Revision: 01
> Title:Signaling Base MPLS Insp

Re: [Lsr] New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt

[Tony Li]

Hi Yao,

IMHO, that was a mistake in the specification of ERLD.

I’m hopeful that we don’t repeat the same mistake. 

Tony


> On Aug 29, 2023, at 1:22 AM,   
> wrote:
> 
> Hi Tony,
> 
> 
> 
> Thanks a lot for your suggestion. This scenario would be taken into 
> consideration.
> 
> But on the other hand, what I haven't understood is that why ERLD-MSD is 
> limited to per-node scope considering that each line card may have different 
> capabilities to read through the label stack.
> 
> 
> 
> Best Regards,
> 
> Yao
> 
> Original
> From: TonyLi 
> To: 刘尧00165286;
> Cc: Les Ginsberg ;mpls ;lsr@ietf.org 
> ;
> Date: 2023年08月29日 10:36
> Subject: Re: [Lsr] New Version Notification for 
> draft-liu-lsr-mpls-inspection-msd-01.txt
> 
> Hi Yao,
> Please consider the case of a modular node with a number of different line 
> cards, where the line cards are based on different forwarding engines.
> 
> RLD needs to be link specific.
> 
> Regards,
> Tony
> 
> 
>> On Aug 28, 2023, at 6:55 PM,   
>> wrote:
>> 
>> Hi Les,
>> 
>> Thanks a lot for your review and comments.
>> 
>> This new MSD is a per-node capability just like ERLD-MSD, mainly because it 
>> represents how many MPLS labels the node can read, and it is not related 
>> with the links.
>> 
>> And the description in this draft you mentioned is written taking example by 
>> RFC9088(section 4. Advertising ERLD Using IS-IS).
>> 
>> I'll explicitly state the scope of the new MSD in the next version. 
>> 
>> 
>> 
>> Best Regards,
>> 
>> Yao
>> 
>> 
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 
> From: LesGinsberg(ginsberg) 
> To: 刘尧00165286;m...@ietf.org ;lsr@ietf.org ;
> Date: 2023年08月28日 20:57
> Subject: RE: [Lsr] Fw: New Version Notification for 
> draft-liu-lsr-mpls-inspection-msd-01.txt
> Yao –
> 
>  
> 
> Both RFC 8476(OSPF) and RFC 8491(IS-IS) define MSD advertisements with 
> per-link scope and per-node scope.
> 
>  
> 
> Your draft only states: 
> 
>  
> 
> “If a router has multiple interfaces with different capabilities of
> 
>reading the maximum label stack depth, the router MUST advertise the
> 
>smallest value found across all its interfaces.”
> 
>  
> 
> This suggests that you intend only to advertise a per-node capability – but 
> as you don’t explicitly state that – and you don’t provide a reason why a per 
> link capability isn’t applicable, I am unclear as to what your intentions are 
> here.
> 
>  
> 
> Could you clarify whether you intend to support both per link and per node 
> capability – and if not why not?
> 
>  
> 
> Thanx.
> 
>  
> 
>Les
> 
>  
> 
>  
> 
> From: Lsr  On Behalf Of liu.ya...@zte.com.cn
> Sent: Monday, August 28, 2023 12:33 AM
> To: m...@ietf.org; lsr@ietf.org
> Subject: [Lsr] Fw: New Version Notification for 
> draft-liu-lsr-mpls-inspection-msd-01.txt
> 
>  
> 
> Hi All,
> 
> A new version of draft-liu-lsr-mpls-inspection-msd has just been uploaded.
> 
> In this document, a new type of MSD is defined to reflect the Readable Label 
> Depth(RLD), which helps in the MPLS MNA solution.
> 
> In this version, the main update is that some description is added to explain 
> why a new MSD is preferred instead of the ERLD-MSD.
> 
> Currently this new MSD is called Base MPLS Inspection MSD, it may be changed 
> to a more straightforward name like RLD-MSD based on the description in the 
> MNA architecture/solution document. 
> 
> Your comments and suggestions are more than welcome!
> 
>  
> 
> Thanks,
> 
> Yao
> 
> Original
> 
> From: internet-dra...@ietf.org  
> mailto:internet-dra...@ietf.org>>
> 
> Date: 2023年08月28日 14:55
> 
> Subject: New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt
> 
> A new version of Internet-Draft draft-liu-lsr-mpls-inspection-msd-01.txt has
> been successfully submitted by Yao Liu and posted to the
> IETF repository.
> 
> Name: draft-liu-lsr-mpls-inspection-msd
> Revision: 01
> Title:Signaling Base MPLS Inspection MSD
> Date: 2023-08-27
> Group:Individual Submission
> Pages:7
> URL:  
> https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-01.txt
> Status:   https://datatracker.ietf.org/doc/draft-liu-lsr-mpls-inspection-msd/
> HTML: 
> https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-01.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-liu-lsr-mpls-inspection-msd
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-liu-lsr-mpls-inspection-msd-01
> 
> Abstract:
> 
>This document defines a new type of MSD, Base MPLS Inspection MSD to
>reflect the Readable Label Depth(RLD), and the mechanism to signal
>this MSD using IGP and BGP-LS.
> 
> 
> 
> The IETF Secretariat
> 
>  
> 
> 
> 

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

Re: [Lsr] New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt

[Tony Li]

Hi Robert,

Precise interface information naturally falls out of any path computation done 
for traffic engineering.

Regards,
Tony


> On Aug 29, 2023, at 2:31 AM, Robert Raszuk  wrote:
> 
> Hi Tony, 
> 
> Unless you are using precise interface based packet steering (which may not 
> be a great idea to start with) how do you know on which line card type your 
> packets arrive/exit ?
> 
> Just curious ... 
> 
> Thx,
> R.
> 
> On Tue, Aug 29, 2023 at 4:36 AM Tony Li  <mailto:tony...@tony.li>> wrote:
>> 
>> Hi Yao,
>> 
>> Please consider the case of a modular node with a number of different line 
>> cards, where the line cards are based on different forwarding engines.
>> 
>> RLD needs to be link specific.
>> 
>> Regards,
>> Tony
>> 
>> 
>>> On Aug 28, 2023, at 6:55 PM, >> <mailto:liu.ya...@zte.com.cn>> >> <mailto:liu.ya...@zte.com.cn>> wrote:
>>> 
>>> Hi Les,
>>> 
>>> Thanks a lot for your review and comments.
>>> 
>>> This new MSD is a per-node capability just like ERLD-MSD, mainly because it 
>>> represents how many MPLS labels the node can read, and it is not related 
>>> with the links.
>>> 
>>> And the description in this draft you mentioned is written taking example 
>>> by RFC9088(section 4. Advertising ERLD Using IS-IS).
>>> 
>>> I'll explicitly state the scope of the new MSD in the next version. 
>>> 
>>> 
>>> 
>>> Best Regards,
>>> 
>>> Yao
>>> 
>>> Original
>>> From: LesGinsberg(ginsberg) mailto:ginsb...@cisco.com>>
>>> To: 刘尧00165286;m...@ietf.org <mailto:m...@ietf.org> >> <mailto:m...@ietf.org>>;lsr@ietf.org <mailto:lsr@ietf.org> >> <mailto:lsr@ietf.org>>;
>>> Date: 2023年08月28日 20:57
>>> Subject: RE: [Lsr] Fw: New Version Notification for 
>>> draft-liu-lsr-mpls-inspection-msd-01.txt
>>> Yao –
>>> 
>>>  
>>> 
>>> Both RFC 8476(OSPF) and RFC 8491(IS-IS) define MSD advertisements with 
>>> per-link scope and per-node scope.
>>> 
>>>  
>>> 
>>> Your draft only states: 
>>> 
>>>  
>>> 
>>> “If a router has multiple interfaces with different capabilities of
>>> 
>>>reading the maximum label stack depth, the router MUST advertise the
>>> 
>>>smallest value found across all its interfaces.”
>>> 
>>>  
>>> 
>>> This suggests that you intend only to advertise a per-node capability – but 
>>> as you don’t explicitly state that – and you don’t provide a reason why a 
>>> per link capability isn’t applicable, I am unclear as to what your 
>>> intentions are here.
>>> 
>>>  
>>> 
>>> Could you clarify whether you intend to support both per link and per node 
>>> capability – and if not why not?
>>> 
>>>  
>>> 
>>> Thanx.
>>> 
>>>  
>>> 
>>>Les
>>> 
>>>  
>>> 
>>>  
>>> 
>>> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
>>> liu.ya...@zte.com.cn <mailto:liu.ya...@zte.com.cn>
>>> Sent: Monday, August 28, 2023 12:33 AM
>>> To: m...@ietf.org <mailto:m...@ietf.org>; lsr@ietf.org <mailto:lsr@ietf.org>
>>> Subject: [Lsr] Fw: New Version Notification for 
>>> draft-liu-lsr-mpls-inspection-msd-01.txt
>>> 
>>>  
>>> 
>>> Hi All,
>>> 
>>> A new version of draft-liu-lsr-mpls-inspection-msd has just been uploaded.
>>> 
>>> In this document, a new type of MSD is defined to reflect the Readable 
>>> Label Depth(RLD), which helps in the MPLS MNA solution.
>>> 
>>> In this version, the main update is that some description is added to 
>>> explain why a new MSD is preferred instead of the ERLD-MSD.
>>> 
>>> Currently this new MSD is called Base MPLS Inspection MSD, it may be 
>>> changed to a more straightforward name like RLD-MSD based on the 
>>> description in the MNA architecture/solution document. 
>>> 
>>> Your comments and suggestions are more than welcome!
>>> 
>>>  
>>> 
>>> Thanks,
>>> 
>>> Yao
>>> 
>>> Original
>>> 
>>> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> 
>>> mailto:internet-dra...@ietf.org>>
>

Re: [Lsr] New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt

[Tony Li]

Hi Yao,

Please consider the case of a modular node with a number of different line 
cards, where the line cards are based on different forwarding engines.

RLD needs to be link specific.

Regards,
Tony


> On Aug 28, 2023, at 6:55 PM,   
> wrote:
> 
> Hi Les,
> 
> Thanks a lot for your review and comments.
> 
> This new MSD is a per-node capability just like ERLD-MSD, mainly because it 
> represents how many MPLS labels the node can read, and it is not related with 
> the links.
> 
> And the description in this draft you mentioned is written taking example by 
> RFC9088(section 4. Advertising ERLD Using IS-IS).
> 
> I'll explicitly state the scope of the new MSD in the next version. 
> 
> 
> 
> Best Regards,
> 
> Yao
> 
> Original
> From: LesGinsberg(ginsberg) 
> To: 刘尧00165286;m...@ietf.org ;lsr@ietf.org ;
> Date: 2023年08月28日 20:57
> Subject: RE: [Lsr] Fw: New Version Notification for 
> draft-liu-lsr-mpls-inspection-msd-01.txt
> Yao –
> 
>  
> 
> Both RFC 8476(OSPF) and RFC 8491(IS-IS) define MSD advertisements with 
> per-link scope and per-node scope.
> 
>  
> 
> Your draft only states: 
> 
>  
> 
> “If a router has multiple interfaces with different capabilities of
> 
>reading the maximum label stack depth, the router MUST advertise the
> 
>smallest value found across all its interfaces.”
> 
>  
> 
> This suggests that you intend only to advertise a per-node capability – but 
> as you don’t explicitly state that – and you don’t provide a reason why a per 
> link capability isn’t applicable, I am unclear as to what your intentions are 
> here.
> 
>  
> 
> Could you clarify whether you intend to support both per link and per node 
> capability – and if not why not?
> 
>  
> 
> Thanx.
> 
>  
> 
>Les
> 
>  
> 
>  
> 
> From: Lsr  On Behalf Of liu.ya...@zte.com.cn
> Sent: Monday, August 28, 2023 12:33 AM
> To: m...@ietf.org; lsr@ietf.org
> Subject: [Lsr] Fw: New Version Notification for 
> draft-liu-lsr-mpls-inspection-msd-01.txt
> 
>  
> 
> Hi All,
> 
> A new version of draft-liu-lsr-mpls-inspection-msd has just been uploaded.
> 
> In this document, a new type of MSD is defined to reflect the Readable Label 
> Depth(RLD), which helps in the MPLS MNA solution.
> 
> In this version, the main update is that some description is added to explain 
> why a new MSD is preferred instead of the ERLD-MSD.
> 
> Currently this new MSD is called Base MPLS Inspection MSD, it may be changed 
> to a more straightforward name like RLD-MSD based on the description in the 
> MNA architecture/solution document. 
> 
> Your comments and suggestions are more than welcome!
> 
>  
> 
> Thanks,
> 
> Yao
> 
> Original
> 
> From: internet-dra...@ietf.org  
> mailto:internet-dra...@ietf.org>>
> 
> Date: 2023年08月28日 14:55
> 
> Subject: New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt
> 
> A new version of Internet-Draft draft-liu-lsr-mpls-inspection-msd-01.txt has
> been successfully submitted by Yao Liu and posted to the
> IETF repository.
> 
> Name: draft-liu-lsr-mpls-inspection-msd
> Revision: 01
> Title:Signaling Base MPLS Inspection MSD
> Date: 2023-08-27
> Group:Individual Submission
> Pages:7
> URL:  
> https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-01.txt
> Status:   https://datatracker.ietf.org/doc/draft-liu-lsr-mpls-inspection-msd/
> HTML: 
> https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-01.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-liu-lsr-mpls-inspection-msd
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-liu-lsr-mpls-inspection-msd-01
> 
> Abstract:
> 
>This document defines a new type of MSD, Base MPLS Inspection MSD to
>reflect the Readable Label Depth(RLD), and the mechanism to signal
>this MSD using IGP and BGP-LS.
> 
> 
> 
> 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

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

[Tony Li]

I object. This solution is a poor way of addressing the issues.  My reasons 
have been discussed to death already.

Tony


> On Aug 23, 2023, at 1:07 PM, Acee Lindem  wrote:
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> 
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] WG Last Call IPR Poll for "IS-IS Fast Flooding" - draft-ietf-lsr-isis-fast-flooding-04

[Tony Li]

I am unaware of any undisclosed IPR.

T


> On Jul 19, 2023, at 4:19 PM, Acee Lindem  wrote:
> 
> Authors,
> 
> A cornucopia of IPR declarations have already been disclosed:
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-isis-fast-flooding
> Are you aware of any additional IPR that applies to 
> draft-ietf-lsr-isis-fast-flooding-04.
> 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 been disclosed in conformance with IETF rules.
> 
> Thanks,
> Acee
> 
> 

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

Re: [Lsr] Working Group Last Call for "IS-IS Fast Flooding" - draft-ietf-lsr-isis-fast-flooding-04

[Tony Li]

Support

T


> On Jul 19, 2023, at 4:06 PM, Acee Lindem  wrote:
> 
> This begins three week LSR Working Group last call for the “IS-IS Fast 
> Flooding”. Please express your support or objection prior to Friday, August 
> 11th, 2023. The longer WG last call is to account for the IETF being next 
> week. 
> 
> Thanks,
> Acee

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

Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-dynamic-flooding-13

[Tony Li]

Hi Acee,

These issues have been addressed:

- The technical sections have been checked against implementations. The 
implementations have been found to be non-existant. All existing 
implementations only deal with the P2P case.

- We’ve added an informative reference. -14 published with the update.

Thanks,
Tony


> On Jun 5, 2023, at 10:30 AM, Acee Lindem  wrote:
> 
> Hi Sue, 
> 
> Thanks for your review of a fairly large specifying complex functionality 
> required prior IGP expertise. 
> 
> Authors, 
> 
> Please address Sue’s comments. 
> 
> Thanks,
> Acee (as document Shepherd) 
> 
>> On Jun 5, 2023, at 13:21, Susan Hares via Datatracker  
>> wrote:
>> 
>> Reviewer: Susan Hares
>> Review result: Ready
>> 
>> The document is written in a clear and concise manner.
>> The authors have done an excellent job of making a difficult subject clear 
>> and
>> readable.
>> 
>> Two technical sections should be checked against implementations of IS-IS 
>> with
>> dense flooding (section 6.6.2.1 and section 6.6.2.2.  I am not implementing 
>> so
>> this check is beyond my capabilities.
>> 
>> Editorial nit:
>> section 3, requirement 3, sentence 2.  "Just addressing a complete bipartite
>> topology such as K5, 8 is insufficient."  An informative reference to K5,8 
>> or a
>> bipartite topology might be helpful to readers.  This is an optional 
>> editorial
>> comment.
>> 
>> 
> 

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

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-dynamic-flooding-14.txt

[Tony Li]

FYI

This addresses a comment raised during the rtgdir last call review. We were 
asked to add an informative reference for graph theory.

Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-dynamic-flooding-14.txt
> Date: June 8, 2023 at 9:49:26 AM PDT
> To: "Huaimo Chen" , "Luay Jalil" 
> , "Peter Psenak" , "Srinath 
> Dontula" , "Tony Li" 
> 
> 
> A new version of I-D, draft-ietf-lsr-dynamic-flooding-14.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-dynamic-flooding
> Revision: 14
> Title:Dynamic Flooding on Dense Graphs
> Document date:2023-06-08
> Group:lsr
> Pages:48
> URL:
> https://www.ietf.org/archive/id/draft-ietf-lsr-dynamic-flooding-14.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-dynamic-flooding-14
> 
> Abstract:
>   Routing with link state protocols in dense network topologies can
>   result in sub-optimal convergence times due to the overhead
>   associated with flooding.  This can be addressed by decreasing the
>   flooding topology so that it is less dense.
> 
>   This document discusses the problem in some depth and an
>   architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
>   and OSPFv3 are described in this document.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

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

Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-dynamic-flooding-13

[Tony Li]

[+ Sarah]

Sarah, could you please review section 6.6.2.1. I no longer have access to an 
implementation, so it’s all up to you.

AFAIK, there is no implementation of dynamic flooding for OSPF, so I don’t know 
of a way to check against an implementation.

I would be happy to add a reference for K5,8. I have two references available: 
one is a textbook, the other is wikipedia.  Preferences?

Tony



> On Jun 5, 2023, at 10:30 AM, Acee Lindem  wrote:
> 
> Hi Sue, 
> 
> Thanks for your review of a fairly large specifying complex functionality 
> required prior IGP expertise. 
> 
> Authors, 
> 
> Please address Sue’s comments. 
> 
> Thanks,
> Acee (as document Shepherd) 
> 
>> On Jun 5, 2023, at 13:21, Susan Hares via Datatracker  
>> wrote:
>> 
>> Reviewer: Susan Hares
>> Review result: Ready
>> 
>> The document is written in a clear and concise manner.
>> The authors have done an excellent job of making a difficult subject clear 
>> and
>> readable.
>> 
>> Two technical sections should be checked against implementations of IS-IS 
>> with
>> dense flooding (section 6.6.2.1 and section 6.6.2.2.  I am not implementing 
>> so
>> this check is beyond my capabilities.
>> 
>> Editorial nit:
>> section 3, requirement 3, sentence 2.  "Just addressing a complete bipartite
>> topology such as K5, 8 is insufficient."  An informative reference to K5,8 
>> or a
>> bipartite topology might be helpful to readers.  This is an optional 
>> editorial
>> comment.
>> 
>> 
> 

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

Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00

[Tony Li]

Hi Huaimo,

The first draft builds on existing mechanisms and procedures. The second draft 
is redundant and adds no value whatsoever.

Regards,
Tony


> On Mar 26, 2023, at 3:40 AM, Huaimo Chen  wrote:
> 
> Hi Les,
> 
> Thanks much for your comments.
> My responses are inline below with HC.
> 
> Best Regards,
> Huaimo
> From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
> Sent: Thursday, March 23, 2023 3:35 AM
> To: lsr@ietf.org  mailto:lsr@ietf.org>>; 
> draft-chen-lsr-isis-big-tlv.auth...@ietf.org 
>  
>  >
> Subject: Comments on draft-chen-lsr-isis-big-tlv-00
>  
> Folks -
>  
> This draft proposes a new way to handle advertisement of more than 255 bytes 
> of information about a given object.
> It defines a new "container TLV" to carry additional information about an 
> object beyond the (up to) 255 bytes of information advertised in an existing 
> TLV.
>  
> The draft is defining a solution to a problem which has already been 
> addressed without requiring any protocol extensions. 
> [HC]: It seems that a protocol includes a set of procedures. Would you mind 
> telling me which existing protocols can be used to resolve the problem 
> without requiring any protocol extensions?
> 
> The existing solution - discussed in 
> https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/ 
> 
>  has already been successfully implemented and deployed by multiple vendors.
> [HC]: You are a co-author of this draft, called a first draft for resolving 
> the problem on big TLVs. This first draft contains some protocol extensions. 
> If there is a solution for the problem without requiring any protocol 
> extensions, then why do you as a co-author work on the first draft with 
> protocol extensions?
> 
> The definition of a second solution to the problem is not needed - and in 
> fact further complicates both implementation and deployment. Should the 
> existing solution be used? Should the new solution be used? What is the state 
> of support by all nodes in the network for each solution?
> [HC]:  It seems better to merge the two drafts (i.e., the first draft and the 
> second draft defining container TLV) into one. 
>  
> The motivation for the new solution seems to be the notion that it supports 
> partial deployment. Text in 
> https://www.ietf.org/archive/id/draft-chen-lsr-isis-big-tlv-00.html#name-incremental-deployment
>  
> 
>   states:
>  
> "For a network using IS-IS, users can deploy the extension for big TLV in a 
> part of the network step by step.
> The network has some nodes supporting the extension (or say new nodes for 
> short) and the other nodes not
> supporting the extension (or say old nodes for short) before the extension is 
> deployed in the entire network."
>  
> This suggests the authors believe that a network can function with some nodes 
> using all of the advertisements and some nodes using only the legacy 
> advertisements, but this is obviously false.
> Fundamental to operation of a link state protocol is that all nodes in the 
> network operate on identical LSPDBs.
> The suggestion that features will work correctly when some nodes use 
> attributes advertised in legacy TLVs and the new container TLV while some 
> nodes use only the attributes advertised in legacy TLVs is simply incorrect.
> [HC]: Every node in the network has the same LSPDB. The new nodes understand 
> the new container TLVs and may use them. The old nodes do not understand them 
> and do not use them.
>  
> It is also important to also state that the advertisement of more than 255 
> bytes of information is driven by configuration – not a protocol 
> implementation choice. Suppressing advertisement of some of the configured 
> information also does not result in a working network.
>  
> In short, there is no positive value from the proposed extension – and it 
> does harm by further complicating implementations and deployments.
> [HC]: The second draft defines a gener

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-area-proxy

[Tony Li]

I know of no undisclosed IPR on this document.

Tony


> On Mar 12, 2023, at 4:02 AM, Christian Hopps  wrote:
> 
> 
> This begins a 2 week WG Last Call, ending Mar 26, 2023, for:
> 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> 
> Authors,
> 
> Please indicate to the list, your knowledge of any IPR related to this work.
> 
> Thanks,
> Chris.

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

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-09.txt

[Tony Li]

FYI: no changes.

Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-09.txt
> Date: March 12, 2023 at 9:40:42 AM PDT
> To: "Gyan S. Mishra" , "Gyan Mishra" 
> , "Sarah Chen" , "Tony Li" 
> , "Vivek Ilangovan" 
> 
> 
> A new version of I-D, draft-ietf-lsr-isis-area-proxy-09.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 09
> Title:Area Proxy for IS-IS
> Document date:2023-03-12
> Group:lsr
> Pages:20
> URL:
> https://www.ietf.org/archive/id/draft-ietf-lsr-isis-area-proxy-09.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-area-proxy-09
> 
> Abstract:
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that would allow level 1 areas to provide transit,
>   yet only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

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

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

[Tony Li]

Hi all,

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

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

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

Please note the recurrence of the use of ‘IS’ in the next sentence and again in 
the next paragraph.

Regards,
Tony


> On Mar 4, 2023, at 1:28 PM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC9350,
> "IGP Flexible Algorithm".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7376
> 
> --
> Type: Editorial
> Reported by: Nikolai Malykh 
> 
> Section: 6
> 
> Original Text
> -
> One of the limitations of IS-IS [ISO10589] is that the length of a
>   TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
>   TLV, there are a number of sub-sub-TLVs (defined below) that are
>   supported.  For a given Flex-Algorithm, it is possible that the total
>   number of octets required to completely define a FAD exceeds the
>   maximum length supported by a single FAD sub-TLV.  In such cases, the
>   FAD MAY be split into multiple such sub-TLVs, and the content of the
>   multiple FAD sub-TLVs are combined to provide a complete FAD for the
>   Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
>   Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
>   Algorithm from a given IS.  
> 
> Corrected Text
> --
> One of the limitations of IS-IS [ISO10589] is that the length of a
>   TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
>   TLV, there are a number of sub-sub-TLVs (defined below) that are
>   supported.  For a given Flex-Algorithm, it is possible that the total
>   number of octets required to completely define a FAD exceeds the
>   maximum length supported by a single FAD sub-TLV.  In such cases, the
>   FAD MAY be split into multiple such sub-TLVs, and the content of the
>   multiple FAD sub-TLVs are combined to provide a complete FAD for the
>   Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
>   Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
>   Algorithm from a given IS-IS.  
> 
> Notes
> -
> Incorrect name of protocol (IS instead IS-IS).
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC9350 (draft-ietf-lsr-flex-algo-26)
> --
> Title   : IGP Flexible Algorithm
> Publication Date: February 2023
> Author(s)   : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, 
> A. Gulko
> Category: PROPOSED STANDARD
> Source  : Link State Routing
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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] Fwd: New Version Notification for draft-ietf-lsr-dynamic-flooding-12.txt

[Tony Li]

FYI,

This adopts Acee’s comments and a few other editorial changes.

Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-dynamic-flooding-12.txt
> Date: February 24, 2023 at 8:42:55 AM PST
> To: "Gyan S. Mishra" , "Dave Cooper" 
> , "David Cooper" , 
> "Gyan Mishra" , "Huaimo Chen" 
> , "Les Ginsberg" , "Luay Jalil" 
> , "Peter Psenak" , "Srinath 
> Dontula" , "Tony Li" , "Tony Przygienda" 
> , 
> 
> 
> A new version of I-D, draft-ietf-lsr-dynamic-flooding-12.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-dynamic-flooding
> Revision: 12
> Title:Dynamic Flooding on Dense Graphs
> Document date:2023-02-24
> Group:lsr
> Pages:47
> URL:
> https://www.ietf.org/archive/id/draft-ietf-lsr-dynamic-flooding-12.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-dynamic-flooding-12
> 
> Abstract:
>   Routing with link state protocols in dense network topologies can
>   result in sub-optimal convergence times due to the overhead
>   associated with flooding.  This can be addressed by decreasing the
>   flooding topology so that it is less dense.
> 
>   This document discusses the problem in some depth and an
>   architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
>   and OSPFv3 are described in this document.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

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

Re: [Lsr] Work Group Last Call IPR Call for 'Dynamic-Flooding on Dense Graphs" - draft-ietf-lsr-dynamic-flooding

[Tony Li]

Acee,

I’m unaware of any undisclosed IPR.

Tony


> On Feb 22, 2023, at 1:45 PM, Acee Lindem  wrote:
> 
> Co-Authors, 
> 
> Are you aware of any IPR that applies to 
> draft-ietf-lsr-dynamic-flooding-11.txt?  
> If so, has this IPR been disclosed in compliance with IETF IPR rules  (see 
> RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> There are a few IPR statements already - 
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-dynamic-flooding
> 
> If you are listed as a document author or contributor please respond
> to this email regardless of whether or not you are aware of any
> relevant IPR. *The response needs to be sent to the LSR WG mailing
> list.* The document will not advance to the next stage until a
> response has been received from each author and contributor.
> 
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
> 
> Also, since there are nine authors, it would be great if you could reduce the 
> author list and make
> the others contributors (which still requires an IPR response). 
> 
> Thanks,
> Acee

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-02.txt

[Tony Li]

Bruno, Les,

> Some responses inline – speaking only for myself – not necessarily for all of 
> the co-authors…


Likewise.


> 
> “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.”
>  
> I would rather call for a « must not ».
>  
> From a manageability standpoint, since the burden is now on the network 
> operators to ensure that this will work/not break the network, for existing 
> TLV, this seem to call:
> [LES:] There was never a choice here – the burden is on network operators – 
> and would be even if an advertisement of MP support were provided. Why? 
> Because there is no safe way for implementations to react to changes in the 
> network state regarding MP support without risking flooding storms.
> And, repeating a point I have made in the past, suppressing advertisement of 
> MP-TLVs when the current configuration requires sending them does not result 
> in a working network.
> I don’t think it is a productive discussion to try to determine which 
> condition is worse:
>  
> a)To send MP-TLVs in the presence of one or nodes which are unable to process 
> them or
> b)To suppress sending of some information required by the existing 
> configuration
>  
> Either way, the network will not be working as expected.


I disagree with Les, I don’t see how flooding storms can ensue, and never have. 
 But we’ve been over that point and I see no point in beating a dead horse. 
There was really no reason to bring it up again.

More specifically, I don’t see that “MUST NOT” buys us anything over “should 
not”.  What are we going to do if the operator chooses not to comply? Write a 
ticket? Wag our finger at them? If it was a protocol implementation feature, we 
would shrug our shoulders and say “bad implementation”. Since this is 
operational, and the consequences will impact the operator, I don’t think we 
would have any impact, especially after the fact.


> -  for a MUST implement knob to enable/disable (MAY/SHOULD on a per TLV 
> basis?). And possibly a SHOULD NOT be enabled by default. Current text says 
> RECOMMENDED and I don’t feel that this is enough given that this involves an 
> interop issue, and that some vendors/implementers tends to only implements 
> MUST.
>  
> [LES:] I am fine either way. But as you are trying to apply normative 
> language to a behavior which is not reflected “on the wire”, it is hard to 
> see that there is any ability to enforce this.
> SHOULD/RECOMMENDED seems appropriate to me.


I concur with Les here. This is not meant to be a BCP about how to run the 
network.


>  - a CLI and I would also suggest the document to specify a YANG extension to 
> allow network operators to know whether a given implementation support this 
> or not (on a per TLV basis?)
>  
> [LES:] This makes sense to me.


I can get behind saying that there should be a CLI output and a YANG model 
extension/augmentation.  If you’re asking us to actually propose the YANG 
augmentation, I would be very hesitant due to the OpenConfig/IETF split.  
Anything that we would do here seems like a total waste of time and effort.


>  2)
> “the key information MUST
>be replicated in additional TLV instances so that all contents
>specific to that key can be identified”
>  
> Are we all certain that for all TLVs and sub-TLVs, everyone/implementation 
> will agree on what the key is? (especially if the key were to be spread over 
> multiple fields or if a sub-TLV were to contain both a key and non-key data).
> In order to err on the safe side, I would prefer that this doc specifies the 
> key for all existing TLVs.
>  
> e.g. “4.1 
> .
>   Example: Extended IS Reachability”
> “Optionally one or more of the following identifiers:
>  
>   -  IPv4 interface address and IPv4 neighbor address as specified
>  in [RFC5305 ]
>  
>   -  IPv6 interface address and IPv6 neighbor address as specified
>  in [RFC6119 ] »
>  
> If multiple (N) IPv6 interface addresses are advertised, these N sub-TLVs are 
> part of the key and must be advertised in all instances./part? Or is a single 
> common 
> ID enough to be used as a key of the interface?
>  
> [LES:] Initially, we did not target this draft to serve as “closing the gap” 
> as regards existing TLVs where the relevant RFC is not explicit 
> regarding MP support. However, I think the discussion in the WG has 
> highlighted that some codepoints have explicit language regarding 
> MP support and some do not – and that it would be useful to have a place 
> where what is implicit is stated explicitly. This draft might be the 
> right place to do that. Be interested in feedback from others on this point.


Long, long ago, Jon Postel used to p

[Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-02.txt

[Tony Li]

Hi all,

This is an update on the multi-part TLV draft.

This irons out the nits in the previous version and removes the capability 
advertisement.

Comments or questions?

Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-pkaneria-lsr-multi-tlv-02.txt
> Date: November 30, 2022 at 10:49:51 AM PST
> To: "Antoni Przygienda" , "Chris Bowers" 
> , "Les Ginsberg" , "Parag Kaneriya" 
> , "Shraddha Hegde" , "Tony Li" 
> , "Tony Przygienda" 
> 
> 
> A new version of I-D, draft-pkaneria-lsr-multi-tlv-02.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-pkaneria-lsr-multi-tlv
> Revision: 02
> Title:Multi-part TLVs in IS-IS
> Document date:2022-11-30
> Group:Individual Submission
> Pages:9
> URL:
> https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-02.txt
> Status: https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-pkaneria-lsr-multi-tlv-02
> 
> Abstract:
>   New technologies are adding new information into IS-IS while
>   deployment scales are simultaneously increasing, causing the contents
>   of many critical TLVs to exceed the currently supported limit of 255
>   octets.  Extensions exist that require significant IS-IS changes that
>   could help address the problem, but a less drastic solution would be
>   beneficial.  This document codifies the common mechanism of extending
>   the TLV content space through multiple TLVs.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

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

Re: [Lsr] OSPF-GT

[Tony Li]

I’d suggest that the IGP is still not a dump truck. Putting labels on the side 
of it doesn’t make the situation better.

I’m opposed to this work.

Tony


> On Nov 10, 2022, at 3:07 AM, Aijun Wang  wrote:
> 
> Agree.
> 
> It is simple to put different application information onto different planes, 
> but it brings the complex for operator to manage such planes, and the inter 
> communication among different planes.
> 
> Lacks of deployments for Geninfo in IS-IS can also predict the future fate of 
> such approaches in some sense.
> 
> 
> Aijun Wang
> China Telecom
> 
>> On Nov 10, 2022, at 10:48, Robert Raszuk  wrote:
>> 
>> 
>> Thx Acee ... 
>> 
>> Since you mentioned "sparse" and since you highlighted that OSPF is better 
>> then ISIS for this as it runs over IP I took a risk if not using flooding is 
>> an option. 
>> 
>> Well ... apparently not. 
>> 
>> Of course you could build lots of parallel GT planes and still flood in each 
>> across interested parties for a given type of info present in such a plane, 
>> but this comes with much more overhead then pub-sub. 
>> 
>> Cheers,
>> R.
>> 
>> 
>> On Thu, Nov 10, 2022 at 11:34 AM Acee Lindem (acee) > > wrote:
>> Hi Robert,
>> 
>>  
>> 
>> From: Robert Raszuk mailto:rob...@raszuk.net>>
>> Date: Wednesday, November 9, 2022 at 10:37 AM
>> To: Acee Lindem mailto:a...@cisco.com>>, lsr > >
>> Subject: OSPF-GT
>> 
>>  
>> 
>> Hi Acee,
>> 
>>  
>> 
>> The point of sparse GT makes it much more attractive. 
>> 
>>  
>> 
>> With that I have two questions/suggestions to make it even more useful.
>> 
>>  
>> 
>> #1 Would you consider adding reflection function to spares mode GT ?
>> 
>>  
>> 
>> Within a flooding scope (e.g., area) , reflection is inherent in the 
>> flooding algorithm. One thing that applications will need to specify is 
>> whether or not information is re-originated outside the flooding scope 
>> (e.g., does the ABR re-originate application LSAs into other areas).
>> 
>>  
>> 
>>  
>> 
>> #2 If you do #1 would you considet pub-sub model ?
>> 
>>  
>> 
>> I wouldn’t change basic OSPF flooding. So, one could support pub-sub but 
>> everyone in the OSPF application routing domain would receive a superset of 
>> subscribed information (or the application would have to do something 
>> unnatural from an OSPF standpoint to limit the neighbors receiving the 
>> information, e.g., dynamically assign areas for unique subscriptions). I 
>> think other protocols are better suited to pub-sub.
>> 
>>  
>> 
>> Thanks,
>> Acee
>> 
>>  
>> 
>> Then this could be used for lot's of current use cases ... some of them even 
>> discussed today :)
>> 
>>  
>> 
>> Thx
>> 
>> R 
>> 
>> ___
>> 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] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi Acee,

> You realize the latest version still has the statement: 
> 
>If all routers in an area advertise the Multi-part TLV Capability a
>node MAY advertise multi-part TLVs to increase space for payload
>values, unless otherwise specified by the TLV.
>  
> At a minimum, the draft should specify a configuration parameter dictating 
> whether advertisement of the capability by all area IS-IS routers is required 
> for advertisement. With this new parameter, my preference would be to then 
> leave it to implementations as to the default value, i.e., beyond the scope 
> of the document.


Yes, I realize that the current draft is out of date.  The pending version of 
the draft relaxes this.

I cannot publish a new version of the draft until we have consent from all of 
the authors, which we have not achieved.

Tony

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Les,

> On Oct 7, 2022, at 8:16 AM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> What I am trying to highlight is that the existing implementations of MP-TLVs 
> for the "implicit" cases should not be penalized for sending MP-TLVs that are 
> encoded consistent with how MP-TLVs for the "explicit" cases have been done. 
> They are actually doing the right thing.
> 
> If we are in agreement on that - great!


I have no wish to penalize anyone.

T

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

> On Oct 6, 2022, at 1:56 PM, Christian Hopps  wrote:
> 
> Tony I think you may have interpreted these differently?


Ayup.  As stated, I am human.  I blew it.  Mea culpa.

I will rename the current columns and start over.  Contributors still welcome.

T

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Les,


> On Oct 6, 2022, at 7:22 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Chris -
> 
> Not trying to convince you of anything - just want to step back and summarize 
> where we are.
> 
> MP-TLV support has been explicitly allowed in multiple cases - and in these 
> cases no additional signaling has been specified i.e., all TLVs in the "set" 
> are encoded the same way they would be if the there were only 1 TLV in the 
> set and there is no signaling of MP-TLV support required in order to send 
> MP-TLVs.
> 
> Due to new features/increased scale, we now have a need to send MP-TLVs for 
> some additional TLVs (notably Prefix Reachability and Neighbor TLVs). The 
> RFCs defining these TLVs did not explicitly specify the use of MP-TLVs - but 
> they also did not specify any prohibition against doing so.
> 
> Some implementations have chosen to apply the same MP-TLV model used for the 
> "explicit-MP-TLV allowed" cases to these new cases.
> 
> Two possible protocol changes for these new cases have been suggested in this 
> thread:
> 
> 1)Require some additional encoding in the MP-TLVs to identify the TLV as a 
> member of an MP-TLV set
> 
> This would mean that the encoding of MP-TLVs would be different depending on 
> the TLV type.
> I see no justification for this.
> 
> 2)Prohibit the sending of MP-TLVs unless all nodes advertise support
> 
> Even though the encoding used by these early implementations is correct, they 
> would then be penalized and declared illegal because they did not come to the 
> WG and "ask for permission".
> I find this approach at best very petty.
> 
> I share the concern about how a network might behave when not all nodes 
> support MP-TLVs for a given TLV, but this is best handled by having an 
> implementation knob to disable the sending of MP-TLVs - thus giving the 
> operator control.
> 


Your summarization is incorrect.

The proposal is to advertise a advisory message that indicates that a node is 
ready to receive MP-TLVs. It prohibits nothing.

Tony


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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Gentlebeings,

The spreadsheet is NOT documenting implementations.  It’s documenting what I 
could find in the relevant specifications.

Tony


> On Oct 6, 2022, at 9:51 AM, Peter Psenak  
> wrote:
> 
> Chris,
> 
> On 06/10/2022 18:34, Christian Hopps wrote:
>> Peter Psenak  writes:
>>> Tony, Les,
>>> 
>>> I believe we can all agree that we do not want to change the behavior of
>>> existing implementations that support MP-TLVs based on the advertisements 
>>> of the
>>> MP-capability from other routers - it would break existing networks. Even 
>>> the
>>> text in the MP-TLV draft does not suggest that to be the case.
>> Are people not looking at the spreadsheet Tony put together?
>> Which implicit multi-part TLVs are these "existing implementations" 
>> advertising that keep getting referred to? Please let's work with real data 
>> -- the spreadsheet shows a grand total of *0* TLVs that could fall in this 
>> category.
> 
> then the spreadsheet is incorrect.
> 
> I know of implementation that can send and receive Multi part TLVs for 
> IPv4/IPv6 (MT) IP Reach, (MT) Extended IS reachability and IS-IS Router 
> CAPABILITY TLV to start with.
> 
> thanks,
> Peter
>> Thanks,
>> Chris.
>>> I find the discussion about advertising supported capabilities for 
>>> management
>>> purposes in IGPs interesting, but not specific, nor directly related to the
>>> MP-TLV draft. Keeping the two separate would make a lot of sense.
>>> 
>>> 
>>> my 2c,
>>> Peter
>>> 
>>> 
>>> 
>>> On 05/10/2022 22:18, Tony Li wrote:
>>>> Les,
>>>> 
>>>>> On Oct 5, 2022, at 1:14 PM, Les Ginsberg (ginsberg)
>>>>> >>>> <mailto:ginsberg=40cisco@dmarc.ietf.org>> wrote:
>>>>> 
>>>>> */[LES:] It is clear that we have different opinions on this – and there 
>>>>> are
>>>>> multiple folks on both sides of this discussion./*
>>>>> */What I would hope we can agree on is to separate the discussion of 
>>>>> adding
>>>>> advertisement of “feature supported” from the MP-TLV draft by writing a
>>>>> separate draft on this proposal./*
>>>>> */This would allow the two pieces of work to progress independently – as 
>>>>> they
>>>>> should./*
>>>>> *//*
>>>>> */This makes sense to me since the proposal to advertise feature support 
>>>>> is
>>>>> clearly not limited to MP-TLV and has no bearing on how MP-TLVs are
>>>>> encoded./*
>>>>> *//*
>>>>> */Can we agree on this?/*
>>>> Sorry, I’m not on board with this.  The two functions would end up
>>>> disconnected, all the way to the field.
>>>> T
>>>> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi Chris,

> On Oct 5, 2022, at 1:26 PM, Christian Hopps  wrote:
> 
> That is great news b/c it means we can fix those 3 unpublished TLV to be 
> explicit multi-part. After fixing those 3 we are in a much friendly place of 
> defining only future behavior/standard requirements without concern of 
> impacting current deployments.


Yes, those are easily ‘fixed’, if folks feel that those need fixing.

Please note that the real point of this draft is to allow us to treat TLVs that 
are in the “implicit single part TLV” column as being multi-part.

And the real bone of contention is whether or not we should have a router 
capability as a means of signaling readiness to accept those.

Tony

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Les,

> On Oct 5, 2022, at 1:14 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> [LES:] It is clear that we have different opinions on this – and there are 
> multiple folks on both sides of this discussion.
> What I would hope we can agree on is to separate the discussion of adding 
> advertisement of “feature supported” from the MP-TLV draft by writing a 
> separate draft on this proposal.
> This would allow the two pieces of work to progress independently – as they 
> should.
>  
> This makes sense to me since the proposal to advertise feature support is 
> clearly not limited to MP-TLV and has no bearing on how MP-TLVs are encoded.
>  
> Can we agree on this?


Sorry, I’m not on board with this.  The two functions would end up 
disconnected, all the way to the field.

T

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi Les,


> In this thread we talk about MP-TLV support – but this is less than precise. 
> What we are really talking about is MP-TLV support for specific TLVs. So this 
> now requires per/TLV advertisement.


No, it does not.  As you yourself verbally agreed, we are referring to the 
class of TLVs that Chris describes as ‘implicit’. They do not explicitly permit 
or reject MP-TLVs.  We need one bit of information to characterize this entire 
class.

Please stop misrepresenting what we are asking for. Please stop backpeddling on 
what you’ve already agreed to.


> One response to this is to say “we will limit this to ‘important’ 
> advertisements” – but how are we to agree on what is important and what 
> isn’t? Do we have an operational definition of “important”?


We might have to apply judgment and common sense.

Tony

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi Les,
 
> Using the protocol to send what is best described as some subset of a PICS 
> means that we propose to use the IGP flooding mechanism to send static 
> information which the protocol itself cannot (and should not) use in its 
> operation. This consumes space, bandwidth, gets periodically refreshed 
> unnecessarily, and now a complete copy of the information from every node 
> resides on every router in the network when it is only needed by an “NMS”. It 
> would be hard to come up with a better example of “IGP isn’t a dump truck” 
> than this.


If you can’t beat ‘em, join ‘em.


> If there is a belief that we can severely limit the amount of information 
> that is sent/node, I’d have to say that I am skeptical. Once we allow this 
> into the protocol, I don’t see any basis on which to separate what is allowed 
> and what is disallowed. It would not be unreasonable for an operator to say 
> that everything that is a candidate to be mentioned in a PICS is a legitimate 
> candidate for being advertised using this mechanism. Which means the amount 
> of information is likely to become very large – especially once it becomes 
> the de facto way of providing protocol management information.
>  
> The justification seems to be that we don’t have anything better – which 
> represents a longstanding failure of the management plane. While I agree with 
> you that management plane solutions are not adequate – not least because we 
> can’t get the industry to converge on a single solution – this does not mean 
> we should invest in the wrong solution.
>  
> We would be better served spending time and effort working on the right 
> solution - as difficult as that may be.
>  
> If we despair of getting a management plane solution, my suggestion would be 
> to use RFC 6823/6822 to define an IS-IS protocol management application that 
> could support the advertisement of such information. This is technically 
> straightforward to define/implement, easily extensible, and it separates the 
> management information from the information used by the protocol.  And 
> because a separate topology can be used for the “management instance”,  it 
> would be possible to reduce the number of copies in the network.


A blue dump truck is not an architectural improvement over a red dump truck and 
definitely not the right solution.

What we need is a management plane mechanism that can be easily consulted, even 
by nodes not running the IGP.  Or nodes not running any IGP. We should NOT 
require storing the management data on every node. That’s silly.  Rather, we 
should have a set of distributed, synchronized servers that can be easily 
referenced and updated. We need an auto-discovery mechanism so that nodes can 
learn where these servers are. We need a common hierarchical data schema so 
that data is organized consistently. And we needed this in 1992. ;-)

Even if you agree with this, I am not willing to stall the current work the 
decades that it will take for the IETF to make progress on this.

Tony

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi all,

> On Oct 3, 2022, at 8:37 AM, Christian Hopps  wrote:
> 
> 
> [As wg-member]
> 
> I think the draft should include a table of all top level TLVS as rows and 
> for columns we have
> 
> - "Implicit Single TLV Only" (e.g., no key info)
> - "Implicit Multi-TLV Only"
> - "Explicit Single TLV Only"
> - "Explicit Multi-TLV-Allowed"
> 
> This draft then would *explicitly* cover the existing "implicit" cases and we 
> have the table to point at to be precise about what we are talking about.


I have completed this effort.

Rather than burden the draft with this, I have created a spreadsheet and am 
sharing a link to the sheet: 
https://docs.google.com/spreadsheets/d/1VWQHsJTq7JRUVdRVcRd_QYYyY_LiOX7H0ZKn8feRZo4/edit?usp=sharing

There are numerous proprietary TLVs that I cannot evaluate. I have ignored them.

I am human. I expect that I will have missed several things. If you have a 
correction, please unicast me.

Regards,
Tony

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi Bruno,

> To clarify, are we talking about:
> - different nodes in the flooding domain having a different understanding of 
> the LSDB content


We are trying to prevent that.  We are trying to figure out how we can relax 
the cases where the specifications imply, but do not clearly state that a TLV 
may occur multiple times. If some nodes are not prepared for that, then they 
would misinterpret the advertisements, perceive different information content, 
and misbehave. What are the necessary and sufficient precautions to prevent 
this?


> And a standardization group defining specifications to allow for interop?


In particular, how do we propagate information to know which nodes are capable 
of correctly interpreting multi-part TLVs?

 
> Sure, I’d be interested in an implementation report to at least learn about 
> such (sub) TLV and those implementations.


Chris is not asking for an implementation report, nor is that what I’m working 
on.

T


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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi all,

> On Oct 3, 2022, at 8:37 AM, Christian Hopps  wrote:
> 
> 
> [As wg-member]
> 
> I think the draft should include a table of all top level TLVS as rows and 
> for columns we have
> 
> - "Implicit Single TLV Only" (e.g., no key info)
> - "Implicit Multi-TLV Only"
> - "Explicit Single TLV Only"
> - "Explicit Multi-TLV-Allowed"
> 
> This draft then would *explicitly* cover the existing "implicit" cases and we 
> have the table to point at to be precise about what we are talking about.


I am actively working on this. Collaboration would be most welcome.

T

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi Les,

> Folks may well complain that management tools are not as good as they need to 
> be, but trying to compensate for this by adding management information into 
> the protocol itself isn’t a good solution.


It is not a good solution. But it is the only practical solution available. At 
scale, we need automation. We have tried and failed (again) to get broad 
adoption of a management infrastructure. We continue to reject alternative 
approaches. The thought of someone keeping all of this in their heads is simply 
naive.

We have already painted ourselves into this corner. There is no good way out.

Tony


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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi Henk,

>> Yes, I'm advocate for putting things elsewhere, but that proposal has
>> met with crickets.  You don't get it both ways: no capabilities in the
>> protocol and nowhere else does not work.
> 
> I'm not sure I know what you are talking about.
> Did you write a draft?


I did.  You don’t remember it. It was that memorable.


>> Because the thought of trying to deploy this capability at scale without
>> this attribute seems impossible. Consider the case of Tier 1 providers
>> who have large IS-IS deployments. Are you really going to evaluate 2000+
>> nodes without some kind of help?
> 
> With the help of the management-plane?


There is no management plane.  We had the chance at one, but we had the great 
schism between OpenConfig and the IETF. So now we have nothing that we can rely 
on.


> How did those providers make changes to their configs/features/architecture 
> before?
> I would expect them to use the same tools.


They have configuration databases, but they do NOT have good tools that tell 
them about router capabilities. They MAY be able to do something ad hoc based 
on software release numbers, but this is far from a good solution.


>> And the routers will do computations based on the multi-part TLVs.
>> One level of indirection for a capability does not seem extreme.
> 
> Not extreme, indeed.
> But again, I rather not see 20 different minor or irrelevant things
> in the router-capability TLV. Certainly not at 2 octets per item.
> 1 Bit would already be (16 times) better.


I am happy to go with one bit.  However, there is no place to encode that 
single bit today.


>>> Regardless whether we do that or not, this discussion maybe should be done
>>> outside the multipart TLV  discussion. Maybe another draft should be written
>>> about these software-capabilities in general?
>> 
>> Please feel free.  My proposal was shot down.
> 
> Are you talking about a very recent proposal? Linked to the multipart-TLV
> draft? Or something older? I vaguely remember some idea about
> "generic transport" in IS-IS (or rather: outside the regular IS-IS instance).


This was outside of IS-IS entirely.  Several people disliked it so much that 
they wanted it thrown out of the WG.

T

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Tony Li]

Hi Henk,

> My point was: multipart TLVs exist today, before the introduction of the
> capability advertisement. So when you look at a LSPDB, you still don't know 
> for
> sure which routers support multipart TLVs. Some might, but don't advertise it.
> Because their software was written before the new capability existed.


True, but irrelevant. The point is that if a router does advertise the 
capability, then you can reasonably infer that it is ready to receive 
multi-part TLVs.


> I hope not. And I will oppose those attempts too.


Example: MPLS MNA is coming. It’s a bundle of independent network actions, plus 
user defined actions. The MPLS WG is going to need a capability for each 
action. I expect that they will come here (LSR) and ask.


>> we still do not have an effective management plane and
>> continue to stuff things into the LSDB that belong in the management plane.
> 
> Yes. But that does not make it an excuse to put just anything in the LSPDB.


That’s what we’ve been doing for decades.

Yes, I’m advocate for putting things elsewhere, but that proposal has met with 
crickets.  You don’t get it both ways: no capabilities in the protocol and 
nowhere else does not work.

If the IGP is not a dump truck, then what else is?


> I've seen you in this work-group as someone who tried to keep things out of
> IS-IS that don't belong there. I am surprised to see you want this capability 
> in.


Because the thought of trying to deploy this capability at scale without this 
attribute seems impossible. Consider the case of Tier 1 providers who have 
large IS-IS deployments. Are you really going to evaluate 2000+ nodes without 
some kind of help?


>> The entire definition of a Flex Algo topology constraint should be
>> in the management plane.
> 
> Sure. But at least the routers do make route-calculation decisions based on
> that information.


And the routers will do computations based on the multi-part TLVs.  One level 
of indirection for a capability does not seem extreme.


>> That's not an excuse for not trying to do a good job now.
> 
> That is the whole question. This capability is adding 2 more octets to LSPs..
> Is that worth it?


Yes.


> What if indeed a few dozen drafts will follow to advertise
> more of these capabilities?


They are coming regardless.


> Should we define a new top-level TLV for "feature/software support 
> capability"?


No, since duplicating an existing TLV is wasteful of TLV code points. The 
current capability TLV is both necessary and sufficient.


> Not whether something is configured or not (as does the router-capability 
> TLV),
> but whether a router's software has that capability to begin with.
> Or should we define a new variable-length bitmask sub-TLV for the existing 
> router
> capability TLV. Where every bit indicates another piece of software the router
> supports?


That’s coming. See above.


> Regardless whether we do that or not, this discussion maybe should be done
> outside the multipart TLV  discussion. Maybe another draft should be written
> about these software-capabilities in general?


Please feel free.  My proposal was shot down.

T

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