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

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

[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 

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 

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 

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 Inspectio

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=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 general mechanism for resolving the problem. 

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

[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

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

[Tony Li]

Hi Henk,

> > If we want to introduce MP-TLVs, that change would warrant the existence of 
> > the flag.
> 
> Multipart TLVs already exist today. 


Some exist today.  There are many TLVs where they have never been specified.


> As discussed here, after introducing a "software capability TLV", if a router 
> doesn't
> advertise any of those new capabilities, we still don't know whether that 
> router supports
> multipart TLVs or not.
> So the new capability seems to have limited value.


In particular, the current proposal on the table is to have the capability 
apply to the TLVs where multi-part has not been previously defined.


> > I dispute that a binary flag warrants the word 'complexity'.
> 
> You might think of a single bit now. 
> But people might want to add more. What TLVs on a router can and can not be 
> received
> multipart? What about sub-TLVs?


We are not proposing that level of specificity. It’s all or nothing.


> It seems these days we have more people in the LSR work-group that prefer to 
> write drafts
> than that prefer to write code.


Ok, I’m offended.


> I fear a large amount of drafts about router capabilities to
> advertise support for every bit, every TLV and every sub-TLV in LSPs. In the 
> end, every
> feature, every detail or option in a feature, will get its own router 
> capability.


That’s correct. It will. That’s going to happen independently of this draft.


> I'm happy nobody wants routers to react to advertised software capabilities. 
> But if routers don't react to info in a LSP, I don't think that info belongs 
> in the control-plane.
> It belongs in the management-plane.


Thank you, but we still (40 years in?) do not have an effective management 
plane and continue to stuff things into the LSDB that belong in the management 
plane.


> That's a different thing, imho. It's a single exception. It's very useful to 
> identify LSPs and routers.
> I don't see other management information we should put in LSPs.


There’s tons of stuff.  The entire definition of a Flex Algo topology 
constraint should be in the management plane. Almost everything that is in the 
router capability TLV should be in the management plane.

We stepped down this slippery slope a long, long, time ago.


> Twenty-five years ago, you and me were the first people to implement support 
> for wide metrics.
> I came up with a strategy to migrate a running network.
> I introduced the "metric-style [wide|narrow]" command. That was supposed to 
> be a temporary thing.
> Just for use in the next 1-2 years, when every IS-IS network was migrating to 
> wide metrics.


And it’s still there.


> When I came back to work, in 2015, I saw that the Nokia SR-OS routers still 
> have narrow metrics as
> the default setting. I laughed. Now I am back at cisco, and I see that IOS-XR 
> also has narrow metrics
> as the default. I cried. FYI, both OSes had their FCS many years after 1997. 
> If I am not mistaken, JunOS has "metric-style both" as the default. 
> So on all these 3 OSes, you need to explicitly configure "metric-style wide". 
> Twenty five years after the migration …..


Excellent point: things don’t progress. So if you want to move forward, you 
need to be very careful.  That’s all that we’re suggesting.


> I fear that the same will happen with your router-capability. The new 
> capability will have some
> value now. To help migrate to a network where all boxes support multipart 
> TLVs.
> But 1-2 years from now, all (major) IS-IS implementations will support 
> multipart TLVs for all TLVs.
> And then the new router-capability will have no use anymore. But routers all 
> around the world will
> still advertise it. I predict that 25 years from now, 23 years after all 
> IS-IS implementations started
> to support multi-part TLVs, routers will still advertise your capability.
> 
> I don't like that.


I know that it will take more than 2 years.  Deployment alone is another 2 
years. And I’m sorry that you don’t like it.  There are lots of things out 
there that could be better. That’s not an excuse for not trying to do a good 
job now.

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]

> MP-TLVs are sent by routers not simply because they have the ability to do 
> so, but because the configuration requires them to send more information 
> about an object than will fit in a single TLV. This means that any attempt to 
> suppress generation of a MP-TLV based on the current capabilities (advertised 
> or not) of the routers in the network will not result in a working network. 
> Some information required by the configuration would be missing – behavior of 
> the network in such a condition is unpredictable. In addition, suppression of 
> MP-TLVs triggered by the introduction of a router which does not have support 
> could result in flooding storms when the state of the network transitions 
> from “all nodes support” to “some nodes support” (or vice versa).


This is simply dishonest.

There has never been any text that even remotely suggested that nodes should 
withdraw MP-TLVs if capabilities were not seen.  Even if an implementation 
gated their advertisement of MP-TLVs based on the capability, it would hardly 
be a “flooding storm”.  It is a single update from all relevant nodes.  One 
copy of the full LSDB.  If the network can’t support that, then a partition is 
also going to collapse it.


> The only safe use of such an advertisement would be as informational.


Which is exactly the text that we have agreed to, yet, you are the only author 
blocking us from publishing it.


> Advertisement of “features supported” is unprecedented in IS-IS (existing 
> advertisements in Router Capability TLV are not advertising feature support – 
> they are advertising feature specific information used by other routers or 
> other entities (e.g., controllers ) in performing routing calculations).


This is irrelevant. We tweak semantics all of the time.  There is nothing in 
the definition of the router capability TLV that prevents what we are 
proposing.  You are the only one who objects.


> It introduces the sending of management information in real time protocol 
> updates – something which is more properly provided via management 
> applications, on box show commands, and/or vendor documentation.


We have been sending management information in the LSDB since we introduced the 
hostname TLV.


> There is also the reality that MP-TLVs are already being sent by multiple 
> implementations and that existing protocol specifications have explicitly 
> specified the use of MP-TLVs as valid in a number of existing cases including:
>  
>   242 Router Capability TLV  [RFC7981)
>   138 GMPLS-SRLG [RFC5307]
>   139   IPv6 SRLG  [RFC6119]
>   238 Application-Specific SRLG [RFC8919]
>   Also sub-TLV  16 Application-Specific Link Attributes [RFC8919]


This is also incorrect.  The new text of the document specifically excludes all 
of these cases from MP-TLV.

 
> Therefore, the absence of an MP-TLV supported advertisement cannot be 
> reliably used to indicate lack of support – it could just mean that the 
> feature support advertisement itself is not supported.


The absence of the MP-TLV support advertisement indicates that the node does 
not declare support for all MP-TLVs.  That is both necessary and sufficient.

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

> I am having troubles understanding the value of ‘The Multi-part TLV 
> Capability’ flag.
> What would break if ‘Multi-part TLV Capability’ flag would not exist?


A system that supported MP-TLVs would not be able to determine that there were 
other systems in the area that did not support MP-TLVs.  The system might then 
advertise MP-TLVs and they would be misinterpreted or cause system crashes in 
the systems that did not support them.


> IS-IS has been working well for many years. Why would that suddenly change 
> and mandate existence and complexity of a ‘Multi-part TLV Capability’ flag?


If we want to introduce MP-TLVs, that change would warrant the existence of the 
flag.  I dispute that a binary flag warrants the word ‘complexity’.


> Note: thoughts about the flag: What if a system by accident sends 
> flip-flopping (set/unset/set/unset/etc) of this flag?


Then other systems might misinterpret the results and generate inconsistent 
TLVs.  That would be bad.


> What if an advertising system support multi-tlv for TLV ‘A’ but not for TLV 
> ‘B’?


We are not allowing that level of granularity.  A system that is going to 
support MP-TLVs should take care to operate correctly for ALL TLVs before 
advertising that it supports them.

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

Thank you.  Not everyone is yet in agreement with this, so we are discussing 
correct wording.

T


> On Jul 5, 2022, at 7:00 AM, Hannes Gredler 
>  wrote:
> 
> Hi Tony, et al,
> 
> minor nit:
> 
> ---
>   As an example, consider the Extended IS Reachability TLV (type 22).
>   A neighbor in this TLV is specified by:
> 
>   *  7 octets of system ID and pseudonode number
>   *  3 octets of default metric
> 
>   This acts as the key for this entry.  The key is followed by up to
>   244 octets of sub-TLV information.
> ---
> 
> I believe that in most implementations the key in the LSDB is the 7 octets of 
> system ID and pseudonode number
> and does not include the metric (it's really an attribute to the key), 
> whereas the current wording might
> wrongly imply that the key is {sysid, PSN and metric}.
> 
> thanks,
> 
> /hannes
> 
> |From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf 
> Of Tony Li
> |Sent: Tuesday, July 5, 2022 3:09 AM
> |To: lsr mailto:lsr@ietf.org>>
> |Subject: [Lsr] Fwd: New Version Notification for
> |draft-pkaneria-lsr-multi-tlv-01.txt
> | 
> | 
> | 
> | 
> | 
> |Hi all,
> | 
> | 
> | 
> |This is an update to reflect some of the discussions to date. A diff is
> |attached.  Most of this is a change to terminology to stop using the word
> |‘instance’ and shift to using ‘multi-part TLV’.
> | 
> | 
> | 
> |We have been having a discussion about adding more discussion of keys in
> |this document.  We have not done that yet.  This is not an indication of
> |refusal, just making one baby step forward.  More to come… Text
> |contributions are more than welcome.
> | 
> | 
> | 
> |Other comments?
> | 
> | 
> | 
> |Regards,
> | 
> |Tony
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> |  Begin forwarded message:
> | 
> |   
> | 
> |  From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
> | 
> |  Subject: New Version Notification for
> |  draft-pkaneria-lsr-multi-tlv-01.txt
> | 
> |  Date: July 4, 2022 at 6:04:37 PM PDT
> | 
> |  To: "Antoni Przygienda" mailto:p...@juniper.net>>, 
> "Chris Bowers"
> |  mailto:cbo...@juniper.net>>, "Les Ginsberg" 
> mailto:ginsb...@cisco.com>>, "Parag
> |      Kaneriya" mailto:pkane...@juniper.net>>, 
> "Shraddha Hegde"
> |  mailto:shrad...@juniper.net>>, "Tony Li" 
> mailto:tony...@tony.li>>, "Tony Przygienda"
> |  mailto:p...@juniper.net>>
> | 
> |   
> | 
> |  A new version of I-D, draft-pkaneria-lsr-multi-tlv-01.txt
> |  has been successfully submitted by Tony Li and posted to the
> |  IETF repository.
> | 
> |  Name:  draft-pkaneria-lsr-multi-tlv
> |  Revision:  01
> |  Title:  Multi-part TLVs in IS-IS
> |  Document date:  2022-07-04
> |  Group:  Individual Submission
> |  Pages:  7
> |  URL:
> | 
> https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.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-01
> | 
> |  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 such as [RFC7356] 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
> | 
> | 
> | 
> |  
> _
> | 
> |  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,
>

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

[Tony Li]

Bruno,

Thank you, the authors are discussing this.

T


> On Jul 5, 2022, at 4:52 AM,  
>  wrote:
> 
> Hi Tony,
>  
> Thanks the update.
> 1 clarification question on §5 (new capability)
> « If all routers in an area advertise the Multi-part TLV Capability a node 
> MAY advertise multi-part TLVs “
>  
> Does this mean that if one router does not advertise the capability, routers 
> MUST NOT advertise multi-part TLVs? (and if necessary readvertises LSPs which 
> contained such multi-part TLV)
> If so, I would favor adding this explicitly.
>  
> Regards,
> --Bruno
>  
>  
> Orange Restricted
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Tony Li
> Sent: Tuesday, July 5, 2022 3:09 AM
> To: lsr mailto:lsr@ietf.org>>
> Subject: [Lsr] Fwd: New Version Notification for 
> draft-pkaneria-lsr-multi-tlv-01.txt
>  
>  
> Hi all,
>  
> This is an update to reflect some of the discussions to date. A diff is 
> attached.  Most of this is a change to terminology to stop using the word 
> ‘instance’ and shift to using ‘multi-part TLV’.
>  
> We have been having a discussion about adding more discussion of keys in this 
> document.  We have not done that yet.  This is not an indication of refusal, 
> just making one baby step forward.  More to come… Text contributions are more 
> than welcome.
>  
> Other comments?
>  
> Regards,
> Tony
>  
>  
>  
>  
> 
> 
> Begin forwarded message:
>  
> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
> Subject: New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt
> Date: July 4, 2022 at 6:04:37 PM PDT
> To: "Antoni Przygienda" mailto:p...@juniper.net>>, "Chris 
> Bowers" mailto:cbo...@juniper.net>>, "Les Ginsberg" 
> mailto:ginsb...@cisco.com>>, "Parag Kaneriya" 
> mailto:pkane...@juniper.net>>, "Shraddha Hegde" 
> mailto:shrad...@juniper.net>>, "Tony Li" 
> mailto:tony...@tony.li>>, "Tony Przygienda" 
> mailto:p...@juniper.net>>
>  
> 
> A new version of I-D, draft-pkaneria-lsr-multi-tlv-01.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-pkaneria-lsr-multi-tlv
> Revision: 01
> Title: Multi-part TLVs in IS-IS
> Document date: 2022-07-04
> Group: Individual Submission
> Pages: 7
> URL:
> https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.txt 
> <https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.txt>
> Status: 
> https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/ 
> <https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/>
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv 
> <https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv>
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-pkaneria-lsr-multi-tlv-01 
> <https://www.ietf.org/rfcdiff?url2=draft-pkaneria-lsr-multi-tlv-01>
> 
> 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 such as [RFC7356] 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
> 
> 
>  
> _
> 
> 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

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

[Tony Li]

Hi all,This is an update to reflect some of the discussions to date. A diff is attached.  Most of this is a change to terminology to stop using the word ‘instance’ and shift to using ‘multi-part TLV’.We have been having a discussion about adding more discussion of keys in this document.  We have not done that yet.  This is not an indication of refusal, just making one baby step forward.  More to come… Text contributions are more than welcome.Other comments?Regards,Tony<<< text/html; x-unix-mode=0644; name="Diff_ draft-pkaneria-lsr-multi-tlv-00.txt - draft-pkaneria-multi-tlv-01.txt.html": Unrecognized >>>
Begin forwarded message:From: internet-dra...@ietf.orgSubject: New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txtDate: July 4, 2022 at 6:04:37 PM PDTTo: "Antoni Przygienda" <p...@juniper.net>, "Chris Bowers" <cbo...@juniper.net>, "Les Ginsberg" <ginsb...@cisco.com>, "Parag Kaneriya" <pkane...@juniper.net>, "Shraddha Hegde" <shrad...@juniper.net>, "Tony Li" <tony...@tony.li>, "Tony Przygienda" <p...@juniper.net>A new version of I-D, draft-pkaneria-lsr-multi-tlv-01.txthas been successfully submitted by Tony Li and posted to theIETF repository.Name:		draft-pkaneria-lsr-multi-tlvRevision:	01Title:		Multi-part TLVs in IS-ISDocument date:	2022-07-04Group:		Individual SubmissionPages:		7URL:    https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.txtStatus: https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/Htmlized:   https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlvDiff:   https://www.ietf.org/rfcdiff?url2=draft-pkaneria-lsr-multi-tlv-01Abstract:   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 such as [RFC7356] 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] Handling multiple Extended IS Reachability TLVs for a link

[Tony Li]

Yes, we will.  We’re still discussing about who will present.  I can if there 
are no other volunteers.  You’re welcome to put my name down for now.

T


> On Jun 29, 2022, at 11:26 AM, Acee Lindem (acee)  wrote:
> 
> Speaking as WG chair: 
> 
> Can someone present this at IETF 114? It seems like there more interest than 
> most of the other agenda requests. 
>  
> Thanks,
> Acee
>  
> From: Lsr  on behalf of Tony Li 
> Date: Wednesday, June 29, 2022 at 12:58 PM
> To: Ketan Talaulikar 
> Cc: "draft-pkaneria-lsr-multi-...@ietf.org" 
> , lsr 
> Subject: Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link
>  
>  
> Hi Ketan,
>  
> 
> 
>> On Jun 29, 2022, at 9:33 AM, Ketan Talaulikar > <mailto:ketant.i...@gmail.com>> wrote:
>>  
>> Hi Tony,
>>  
>> No. It does not work. Take the following text from Sec 4.
>>  
>>If this is insufficient sub-TLV space, then the node MAY advertise
>>additional instances of the Extended IS Reachability TLV.  The key
>>information MUST be replicated identically and the additional sub-TLV
>>space may be populated with additional information.  The complete
>>information for a given key in such cases is the joined set of all
>>the carried information under the key in all the TLV instances.
>>  
>> There is a normative MUST there, but the "key information" is unspecified. 
>> Without that information these rules would not be really useful for 
>> implementation, would they?
>  
>  
> They would if the implementors understood the intent and spirit. Perhaps 
> that’s asking too much.
>  
> 
> 
>>  
>> I agree with the challenge of trying to catalog "keys" and "rules" on a per 
>> TLV/sub-TLV basis. Perhaps starting with the more widely used TLVs/sub-TLVs 
>> that are likely to exceed limits would be better than not covering any of 
>> them?
>  
>  
> Duly noted.  We have had this comment before, we will definitely consider it.
>  
> Tony
>  

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

Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

[Tony Li]

Hi Ketan,


> On Jun 29, 2022, at 9:33 AM, Ketan Talaulikar  wrote:
> 
> Hi Tony,
> 
> No. It does not work. Take the following text from Sec 4.
> 
>If this is insufficient sub-TLV space, then the node MAY advertise
>additional instances of the Extended IS Reachability TLV.  The key
>information MUST be replicated identically and the additional sub-TLV
>space may be populated with additional information.  The complete
>information for a given key in such cases is the joined set of all
>the carried information under the key in all the TLV instances.
> 
> There is a normative MUST there, but the "key information" is unspecified. 
> Without that information these rules would not be really useful for 
> implementation, would they?


They would if the implementors understood the intent and spirit. Perhaps that’s 
asking too much.


> 
> I agree with the challenge of trying to catalog "keys" and "rules" on a per 
> TLV/sub-TLV basis. Perhaps starting with the more widely used TLVs/sub-TLVs 
> that are likely to exceed limits would be better than not covering any of 
> them?


Duly noted.  We have had this comment before, we will definitely consider it.

Tony

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

Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

[Tony Li]

Hi Ketan,

We are hoping to not be that detailed in this document.  As soon as we become a 
catalog of LSPs, then the applicability of our statements is weakened with 
respect to TLVs that aren’t in the catalog.

What we’re trying to accomplish is to write some general rules that we all 
understand that apply uniformly across all TLVs that don’t specify their own 
overflow mechanisms.

Does this work for you?

Tony


> On Jun 29, 2022, at 6:47 AM, Ketan Talaulikar  wrote:
> 
> Hello Authors,
> 
> I was pointed to your draft while looking around for some clarifications on 
> how information for a single object can be split across multiple TLVs in ISIS.
> 
> Having gone through your document, I believe it is very useful and I am glad 
> to see that you have taken on this work.
> 
> While the problem is generic, there is some part of the solution that is not 
> generic - i.e. we may need to get into individual TLVs/sub-TLVs specifics.
> 
> To take an example, the draft talks about "keys" and there is a challenge 
> that "keys" for certain objects are not formally specified in ISIS specs. 
> E.g., the "keys" for Extended IS Reachability would need to also include the 
> local/remote addresses and/or the local/remote link-IDs. 
> 
> I wanted to check if the authors of this document are planning to tackle 
> these aspects as well.
> 
> Thanks,
> Ketan
> 

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

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Tony Li]

Robert,

> > So, can we PLEASE stop beating a dead horse?
> 
> Are you stating that computing dynamic flooding topologies has no use case 
> outside of MSDCs or for that matter ANY-DCs ? 


There may be a zillion use cases. But there is not critical mass for deploying 
this feature or other flooding reduction features. The time to solve this 
problem was back BEFORE people decided to repurpose BGP to solve their 
problems.  Now, it’s a classic ‘installed base’ problem. People will only 
consider alternatives if an alternative path represents less pain than the 
established path. We’re not there. BGP wins.


> PS. It is true that folks even running 10 racks think BGP is the only choice 
> for the underlay but to me this is failure of deployment folks in vendors to 
> properly position each dynamic routing protocol then nothing else. 


Well, we can blame marketing all we want.  All I know is that we, as a group, 
failed to come together and present a unified front with interoperable 
implementations. That left us in a position where marketing is pushing rocks up 
hills and customers are waiting for the dust to settle. 

T

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

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Tony Li]

Gyan,

Cisco has (reportedly) implemented this, but done so with their own 
proprietary, undocumented distributed algorithm.

The responses that I have seen from operators have been somewhat disappointing:

“There is no  way that I would ever let a  IGP 
into my data center.”

Others have been more polite, but similarly dismissive.

The fact of the matter is that there is an installed base of BGP and folks are 
not open to experimenting with anything else.

So, can we PLEASE stop beating a dead horse?

Tony


> On Jun 14, 2022, at 1:43 PM, Gyan Mishra  wrote:
> 
> All
> 
> I agree this is important work for operators in DC networks  NVO CLOS 
> architecture with extremely dense fabrics and massively scaled out spines.
> 
> I agree we can move forward with progressing with only ISIS being implemented.
> 
> I do think that after the draft is published hopefully implementations 
> include OSPF as well as there is a lot of OSPF used by operators.  
> 
> NVO CLOS architecture I would say is being universally being deployed as 
> defacto standard  in the DC arena.  As well as most operators don’t want to 
> go for the BGP only solution in the DC due to the complexity as well as 
> having to provision many public ASNs.
> 
> I support #1 first followed by #2.
> 
> So far we have Arista implementation, and we have both Cisco and Juniper 
> Co-Authors as  well  on the draft.  
> 
> I think we have a good chance at #1 - Standards track.
> 
> Les & Tony & Tony
> 
> What is the chance of getting this implemented by Cisco & Juniper?
> 
> 
> We also have a few major stakeholders in the industry supporting the draft, 
> Verizon, ATT and CenturyLink as co-authors which I think shows how important 
> this draft is for the industry.
> 
> Kind Regards 
> 
> Gyan
> 
> On Tue, Jun 14, 2022 at 4:05 PM John E Drake 
> mailto:40juniper@dmarc.ietf.org>> 
> wrote:
> Les,
> 
> I'm happy with either 1 or 2.  It's good work and I think it will become 
> important.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: Les Ginsberg (ginsberg)  > <mailto:40cisco@dmarc.ietf.org>>
> > Sent: Tuesday, June 14, 2022 4:01 PM
> > To: John E Drake mailto:jdr...@juniper.net>>; Les 
> > Ginsberg (ginsberg)
> > mailto:ginsb...@cisco.com>>; John Scudder 
> > mailto:j...@juniper.net>>
> > Cc: Tony Li mailto:tony...@tony.li>>; tom petch 
> > mailto:ie...@btconnect.com>>; Acee Lindem
> > (acee) mailto:a...@cisco.com>>; lsr@ietf.org 
> > <mailto:lsr@ietf.org>
> > Subject: RE: [Lsr] Dynamic Flooding on Dense Graphs - 
> > draft-ietf-lsr-dynamic-
> > flooding
> > 
> > [External Email. Be cautious of content]
> > 
> > 
> > John -
> > 
> > I would be inclined to agree with you - but...to my knowledge (happy to be
> > corrected...) -
> > 
> > There has been no interoperability testing.
> > It is really only possible to do interoperability testing on centralized 
> > mode at
> > present, since distributed mode requires standardization/multi-vendor
> > implementation of at least one algorithm - which hasn’t happened yet.
> > So, a significant portion of the protocol extensions remain untested. And 
> > since
> > enthusiasm for this work has waned - perhaps only temporarily - it seems
> > unlikely that these gaps will be closed in the immediate future.
> > Moving to standards track RFC with these gaps seems unwise and to some
> > degree "irresponsible".
> > 
> > I think there are then three viable paths:
> > 
> > 1)Continue to refresh the draft until such time as the gaps are closed or it
> > becomes clear the work is more permanently not of interest 2)Capture the
> > current contents as an Experimental RFC - noting the remaining work.
> > 3)Capture the current contents as a Historic RFC - noting the remaining 
> > work.
> > 
> > I am not in favor of #3.
> > I would be OK with #1 or #2.
> > 
> >Les
> > 
> > 
> > > -Original Message-
> > > From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf 
> > > Of John E Drake
> > > Sent: Tuesday, June 14, 2022 11:23 AM
> > > To: Les Ginsberg (ginsberg)  > > <mailto:40cisco@dmarc.ietf.org>>;
> > > John Scudder  > > <mailto:40juniper@dmarc.ietf.org>>
> > > Cc: Tony Li mailto:tony...@tony.li>>; tom petch 
> > > mailto:ie...@btconnect.com>>; Acee
> > > Lindem (acee) mailto:a...@cis

Re: [Lsr] [rt5.ietf.org #7080] System ID in ISIS

[Tony Li]

Hi,

Neither of these mailing lists are appropriate for technical support.  Please 
contact your vendors directly.

Tony


> On Jun 14, 2022, at 12:12 AM, Jaideep Choudhary 
>  wrote:
> 
> Hi Team,
> I would like to know, whether in IS-IS, a system id can be .. or 
> it is an invalid value for sys I'd ?
> 
> As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't mention 
> explicitly whether SYS ID of .. could be invalid.
> 
> Also as per RFC 3784, it says System id is typically of 6 bytes, but doesn't 
> talk about any invalid option.
> 
> The reason I am asking this is that Juniper defines a SYS ID of 
> .. as invalid.
> 
> https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html
>  
> 
> 
> This can cause issues in inter-operability as some vendors like Cisco doesn't 
> define a SYS-ID of .. as invalid.
> 
> I would appreciate your response on this.
> 
> Regards
> 
> Jaideep Choudhary
> 
> 
> On Mon, 13 Jun, 2022, 11:08 pm Cindy Morgan via RT,  > wrote:
> Hi Jaideep,
> 
> You have reached the IETF Secretariat, which is the administrative branch of 
> the IETF, and as such, we are not qualified to answer your technical 
> questions.
> 
> You might have better luck if you try posing your question to the Link State 
> Routing (LSR) Working Group (https://datatracker.ietf.org/wg/lsr/about/ 
> ). LSR was formed by merging the 
> ISIS and OSPF WGs and assigning all their existing adopted work at the time 
> of chartering to LSR. Their mailing list address is lsr@ietf.org 
> .
> 
> Best regards,
> Cindy
> 
> On Mon Jun 13 10:10:54 2022, jaideepchoudhar...@gmail.com 
>  wrote:
> 
> Hi Team,
>  
> I would like to know, whether in IS-IS, a system id can be .. or 
> it is an invalid value for sys I'd ?
> 
>  
> As per ISO 10589 a system id can be of 1 to 8 bytes long, but doesn't mention 
> explicitly whether SYS ID of .. could be invalid.
> 
>  
> Also as per RFC 3784, it says System id is typically of 6 bytes, but doesn't 
> talk about any invalid option.
> 
>  
> The reason I am asking this is that Juniper defines a SYS ID of 
> .. as invalid.
> 
>  
>  
> https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/is-is-routing-overview.html
>  
> 
>  
> This can cause issues in inter-operability as some vendors like Cisco doesn't 
> define a SYS-ID of .. as invalid.
> 
>  
> I would appreciate your response on this.
> 
>  
> Regards
> 
> Jaideep Choudhary
> 
>  
>  
>  
> ___
> 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] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Tony Li]

Les,


> So you are suggesting that we publish something that was never actually 
> published as an RFC as a "historic RFC"?


Yes, I see no point in being indirect.  It used to be that the path to 
publication was brief. We’ve now ossified to the point where a technology can 
go through an entire life-cycle before we act.  


> But I thought the intent of Acee's question was to see if publishing this as 
> Experimental serves a useful purpose i.e., even if the feature is not being 
> actively deployed the protocol extensions seem like they could be useful 
> someday and we would prefer not to have them disappear from the official 
> protocol definition.
> ??


And the code points are allocated and the code has shipped, so publishing 
something makes sense. Arguing about its status doesn’t.

T

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

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Tony Li]

Les,

The market looked at the technology and decided that it was not interested.  If 
that’s not the definition of ‘obsolete’, I don’t know what is.

Tony


> On Jun 13, 2022, at 10:27 AM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Tony -
> 
> "Historic" is for 
> 
> " A specification that has been superseded by a more recent
>   specification or is for any other reason considered to be obsolete..."
> 
> Hard to see how that applies here.
> 
> Although I appreciate Tom's concern, the fact that we may not be clear on how 
> to transition from Experimental to Standard (for example) seems to me to be a 
> problem to be solved outside of the context of this specific draft - not 
> something that should prevent us from using Experimental.
> 
> In regards to the state of the draft, here is my summary:
> 
> 1)There are multiple implementations of the draft
> 2)I am not aware that interoperability of the implementations has been 
> demonstrated 
> 3)To the extent that interoperability could be demonstrated, I think only 
> centralized mode could be validated at this time
> 4)Interoperability of distributed mode requires standardization of one or 
> more algorithms - which means the drafts defining those algorithms first have 
> to progress
> 
> To me, that makes "Experimental" the right track as further work is required 
> before we can say that all aspects of the draft are mature enough to consider 
> Standards track.
> 
>   Les
> 
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Tony Li
>> Sent: Monday, June 13, 2022 10:12 AM
>> To: tom petch 
>> Cc: Acee Lindem (acee) ; lsr@ietf.org
>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
>> flooding
>> 
>> 
>> Tom,
>> 
>> In this particular case, I believe the choices are Experimental or Historic. 
>>  I’m
>> fine with either.
>> 
>> T
>> 
>> 
>>> On Jun 13, 2022, at 8:43 AM, tom petch  wrote:
>>> 
>>> From: Lsr  on behalf of Acee Lindem (acee)
>> 
>>> Sent: 10 June 2022 15:10
>>> 
>>> Initially, there was a lot interest and energy in reducing the flooding
>> overhead in dense drafts. Now, it seems the interest and energy has waned.
>> IMO, this draft contains some very valuable extensions to the IGPs. I
>> discussed this with the editors and one suggestion was to go ahead and
>> publish the draft as “Experimental”. However, before doing this I’d like to 
>> get
>> the WG’s opinion on making it experimental rather standards track.
>> Additionally, I know there were some prototype implementations. Have any
>> of those been productized?
>>> 
>>> 
>>> The trouble with experimental is what happens next?  Does it stay
>> experimental for ever or is there some assessment at some point when it
>> becomes Standards Track?  What are the criteria?  I am not aware of an RFC
>> describing such a process and the IPPM WG seemed uncertain what to do
>> with RFC8321 and RFC8889 when such an issue arose.
>>> 
>>> The shepherd report for 8321 said
>>> 'the measurement utility of this extension still is to be demonstrated at a
>> variety of scales
>>>  in a plurality of network conditions'
>>> as the justification for experimental but did not state how that might later
>> be demonstrated.
>>> 
>>> Tom Petch
>>> 
>>> Thanks,
>>> Acee
>>> 
>>> 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Tony Li]

Tom,

In this particular case, I believe the choices are Experimental or Historic.  
I’m fine with either.

T


> On Jun 13, 2022, at 8:43 AM, tom petch  wrote:
> 
> From: Lsr  on behalf of Acee Lindem (acee) 
> 
> Sent: 10 June 2022 15:10
> 
> Initially, there was a lot interest and energy in reducing the flooding 
> overhead in dense drafts. Now, it seems the interest and energy has waned. 
> IMO, this draft contains some very valuable extensions to the IGPs. I 
> discussed this with the editors and one suggestion was to go ahead and 
> publish the draft as “Experimental”. However, before doing this I’d like to 
> get the WG’s opinion on making it experimental rather standards track. 
> Additionally, I know there were some prototype implementations. Have any of 
> those been productized?
> 
> 
> The trouble with experimental is what happens next?  Does it stay 
> experimental for ever or is there some assessment at some point when it 
> becomes Standards Track?  What are the criteria?  I am not aware of an RFC 
> describing such a process and the IPPM WG seemed uncertain what to do with 
> RFC8321 and RFC8889 when such an issue arose.
> 
> The shepherd report for 8321 said
> 'the measurement utility of this extension still is to be demonstrated at a 
> variety of scales
>   in a plurality of network conditions'
> as the justification for experimental but did not state how that might later 
> be demonstrated.
> 
> Tom Petch
> 
> 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] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Tony Li]

Hi Acee,

Yes, the Arista implementation shipped.

T


> On Jun 10, 2022, at 7:10 AM, Acee Lindem (acee) 
>  wrote:
> 
> Initially, there was a lot interest and energy in reducing the flooding 
> overhead in dense drafts. Now, it seems the interest and energy has waned. 
> IMO, this draft contains some very valuable extensions to the IGPs. I 
> discussed this with the editors and one suggestion was to go ahead and 
> publish the draft as “Experimental”. However, before doing this I’d like to 
> get the WG’s opinion on making it experimental rather standards track. 
> Additionally, I know there were some prototype implementations. Have any of 
> those been productized? 
>  
> 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] New Version Notification for draft-li-lsr-droid-00.txt

[Tony Li]

Hi Robert,

>> Or you think that DROID as proposed could take on day one flowspec v2 with 
>> its various extensions as example ? 


I realized I did not answer this explicitly.  

DROID aspires to be completely generic. If it can be encoded in bytes, then 
there’s no reason that it can’t go in DROID.  Flowspec v2 is certainly within 
scope.

T

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

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

[Tony Li]

Hi Robert,

> Just two follow up points, 
> 
> #1 - I can't stop the feeling that DROID is very IGP centric and not generic 
> enough. Do you think we need DROID-2 to start offloading BGP or at least stop 
> trashing it ? Or you think that DROID as proposed could take on day one 
> flowspec v2 with its various extensions as example ? 
> 
> #2 - When I mentioned anycast I meant not in the view of anycast redundancy - 
> too many issues with that. I meant just as session/service bootstrapping then 
> falling into dedicated pair of IPs. Simple redundancy could be still easy 
> with two such domain wide addresses. 


The only thing about DROID that’s tied to the IGP at this point is service 
discovery, as Les points out.  AFAIK, we still don’t have an effective, 
domain-wide service discovery mechanism. I agree that that’s a problem, but I’m 
not about to wait for that to get deployed. :)

Yes, you could use two domain-wide addresses, if there was a good way of 
distributing those.  We don’t have one. See above.

T


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

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

[Tony Li]

Les,

 
> Nice acronym. 


Thank you. I blame the wordle craze. :)


> As regards the original use case (Node Liveness), my opinion hasn’t changed. 
> Repackaging this in a more generic wrapper (which makes sense to me) doesn’t 
> alter my opinion – which is this isn’t a good way to go.


This is well known and does not need restatement.  :)


> As regards the new use case (Capabilities), I think what you state as 
> historical behavior isn’t accurate. If you look at the existing sub-TLVs for 
> Router Capability, the information falls into two categories:
> Stuff directly used by the protocol
> TE related stuff (e.g., PCE)
>  
> I would oppose any attempt to move stuff directly used by the protocol out of 
> Router Capability and force the IGP to get this info from some application.


And that’s not what I was suggesting.

I am NOT suggesting we move anything that is currently defined, regardless of 
whether it is appropriate or not.  I would simply like to avoid forthcoming 
atrocities.


> Which leaves stuff NOT used by the IGP. The only existing example which 
> “might” fall into this category is: S-BFD Discriminators – which we stuck 
> into the IGP for lack of a better place.
> I therefore think your language regarding what is/is not a good candidate for 
> DROID capability advertisement needs refinement. As written, it suggests that 
> there are lots of existing cases that are being advertised by the IGP 
> inappropriately – which I do not think is the case.


Well, we can continue to disagree.

I was, in fact, thinking of the slew of capabilities that are about to be 
proposed for the MPLS MNA work.  I know of about ten new capabilities just from 
that direction.


>  I also think that asking the IGP to advertise the location(s) of DROID is an 
> abuse of the IGP – the very thing that you have argued should not be done. 
> The IGP – and specifically Router Capabilities – is not intended to serve as 
> a form of DNS – advertising the location of application services in the 
> network.


Yup. One small sin to prevent a host of subsequent sins.


> It is ironic to me – given that you have framed DROID as motivated by  
> “anti-IGP-as-a-dumptruck”  – that you would then abuse the IGP by asking it 
> to advertise the location of DROID. It opens the door to others who want the 
> IGPs to advertise application stuff – but when that is rejected by LSR WG (as 
> it should be) they say “OK – but can we advertise the identity of a place to 
> get the info in Router Capabilities?”.
> This is unjustifiable IMO – please remove it.


I will be happy to do as soon as there is a working service discovery protocol. 
 But I’m not holding my breath.  Until then this is expedient.


> Finally, there is the question of where such a draft belongs. LSR seems like 
> the wrong place.
> Where are you headed with this?


The LSR chairs have said that this is an appropriate home for now. There is no 
point in discussing this.  Nothing has changed.

Tony

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

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

[Tony Li]

Hi Robert,

> Very happy to see this draft. 


Thanks.


> First question - the draft seems to be focusing on hierarchical IGPs and is 
> clearly driven by liveness propagation discussion. 


The main problem in networking is scale. If you haven’t dealt with scale, you 
haven’t solved the problem. The way that we deal with scale is to install 
hierarchy. Thus, if you don’t have hiearchy, you don’t have a scalable network.

Single level networks are simply degenerate cases of hierarchical networks and 
should be dealt with as such.  Pick two routers.  Make them L1L2.  Poof, all 
done.


> But the motivation of offloading non routing information from IGPs (and/or 
> BGP) is also full applicable to non hierarchical IGPs where there is no ABRs. 
> Do you plan to rewrite section 3 accordingly ? 


No, since it’s not necessary.  :)

If you would like to see alternate text, please feel free to propose.


> Also putting liveness aside wouldn't it be feasible to also relax the 
> attachment to each area/level such that truly opaque information can be 
> exchanged even if we use as broker DROID cluster sitting only in core area 
> and listening to data or liveness from all clients ? 


I’m not sure that I parse this correctly.  Yes, you’re welcome to use DROID 
without worrying about liveness.  That’s one use case and it’s not mandatory.


> The DROID discovery in the latter case could be as simple as one line cfg. 
> Networks could also use well known anycast address to connect network 
> elements to DROID cluster. 


Yes, but TCP/QUIC anycast is not quite as reliable as I would like.  I prefer 
simple redundancy. :-)

Tony


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

[Lsr] Fwd: New Version Notification for draft-li-lsr-droid-00.txt

[Tony Li]

Hi all,

As discussed during our last meeting, the Node Liveness Protocol could be 
generalized to support arbitrary data.

I’ve done that work, turning it into a distributed object store.

In particular, node capabilities are now a generic example of the use of this 
mechanism.  Node Liveness is still included as an custom mechanism.

Comments?

Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-li-lsr-droid-00.txt
> Date: April 4, 2022 at 9:43:57 AM PDT
> To: "Tony Li" 
> 
> 
> A new version of I-D, draft-li-lsr-droid-00.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-li-lsr-droid
> Revision: 00
> Title:Distributed Routing Object Information Database (DROID)
> Document date:2022-04-04
> Group:Individual Submission
> Pages:17
> URL:https://www.ietf.org/archive/id/draft-li-lsr-droid-00.txt
> Status: https://datatracker.ietf.org/doc/draft-li-lsr-droid/
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-li-lsr-droid
> 
> 
> Abstract:
>   Over time, the routing protocols have been burdended with the
>   responsiblity of carrying a variety of information that is not
>   directly relevant to their mission.  This includes VPN parameters,
>   configuration information, and capability data.  All of the
>   additional data impacts the performance and stability of the routing
>   protocols negatively.
> 
>   This has been convenient since the backbone of a routing protocol is
>   a small distributed database of routing information.  Any service
>   needing a distributed database has considered injecting its data into
>   a routing protocol so that it can leverage the protocols database
>   service.  Architecturally, this is a mistake that puts the protocol
>   at risk from undue complexity and overhead.
> 
>   To avoid this, DROID is a subsystem that is tangential to, but
>   independent of the routing protocols, and provides distributed
>   database services for other routing services.  It is based on the
>   publish-subscribe (pub/sub) architecture and is intentionally crafted
>   to be an open mechanism for the transport of ancillary data.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

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

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

[Tony Li]

Hi Aijun,

> Let’s focus on the comparison of NLP and PUAM(Prefix Unreachable Announcement 
> Mechanism):
> For NLP, the receiver should register the interested prefixes first. Once the 
> node fails, all the receivers(normally the nodes within one area) that 
> register such interested prefixes will be notified.
> For PUAM, the receiver NEED NOT register anything.   Once the 
> node fails, all the receivers(normally the nodes within one area) will be 
> notified.
>  
> From the POV of the receiver, if it gets the same results, why don’t select 
> the approach that need less work or nothing to do?


Because the primary goal is stability, not efficiency.

PUA adds load to the IGP. That’s a Very Bad Thing.


> And regarding to your arguments of “Dump Truck” worry about IGP protocol, I 
> think defining one new protocol does not solve the ultimate pressure on 
> Router. Let’s explain this via one analogy:
> The customer(Operator) want the truck(IGP Protocol) to piggyback(via some 
> Tag) some information, the driver(Vendor) said he can’t, because the truck 
> may crush the station(Router) when it pass. The operator need another 
> truck(New Protocol) to carry it.
>  
> Here is the problem then, from the POV of station(Router), if it can’t endure 
> the pass of one truck, why can it can stand to pass the two trucks at the 
> same time?
> Wish you can explain the above paradox in reasonable/logical manner.


Very simple: one of those trucks is vital. The IGP MUST have highest priority 
at all times and should not be burdened with extraneous information. It is not 
a dump truck.

I’m proposing that we use NLP as the dump truck. It can run at a lower priority 
than the IGP. It does not impact IGP flooding or scale. If it gets behind, yes, 
it will affect higher function convergence, but IGP convergence should be 
unaffected.

And, if you didn’t notice, you can run it on a proxy, outside of any router. So 
it really can’t get in the way.

Regards,
Tony

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

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

[Tony Li]

Hi Aijun,

> Thanks for your clarification of the NLP mechanism during the meeting.
> 1. Regarding to the PUB/SUB model within IETF, there are already some of 
> them:
> 1) https://datatracker.ietf.org/doc/html/rfc8641 
>  (Subscription to YANG 
> Notifications for Datastore Updates)
> 2) https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09 
> 
> 3) https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile 
> 
> 4) https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-09 
> 
> Why do we need to invent the new one again?


Thank you, I was unaware of these.  If the WG is interested, I’m certainly 
willing to pursue using one of these.
As far as I can tell from a quick perusal, none of these is intended to be 
generic.  That is to say, none of them 
is a dump truck either.


> And, if we prefer to the PUB/SUB model to solve the discussed problem, why 
> RFC8641 can’t be used?


YANG is evil. :-)


> 2. Regarding to the NLP mechanism itself:
> As you explained, current NLP adopt the “Subscribe Summary Prefixes, Notify 
> the failure of Specific Address” to reduces the pressures on ABRs. Such 
> approach has the following drawbacks again:
> 1) The register should know in advance the summary prefixes that the 
> peers‘ loopback address belong to. Once the summary prefixes are changed, 
> such information should be updated, which will be headache for the operators


Not at all. Loopback address configuration is already handled by the management 
plane. A prefix or multiple prefixes for loopback addresses will also be 
incorporated into the management plane.

Modern networking assumes automation. Yes, we didn’t have it back when I 
started, but it’s there today. Admittedly, it’s not perfect and it has a way to 
go, but there are MANY organizations now that are fully automated.  Anyone that 
wants to be, can be.


> 2) If the register subscribe the “summary prefixes”, then it will 
> receives all the nodes fail notifications within this summary prefixes, which 
> should be avoided when you argue that IGP flooding has such side 
> effect.The results is, NLP can’t avoid it also, then why don’t we utilize 
> IGP flooding mechanism directly?


Yes, if you register for a prefix, you may get multiple notifications back. 
This is a good thing. In the IGP, this would create a scalability problem. The 
very good news is that this is not a scalability problem for NLP.  There is no 
restriction for a finite sized LSDB. There are no real-time demands. The 
distribution of the data can be easily managed, even for slow receivers, by 
techniques that are well-known for BGP.

Using a real transport protocol instead of relying on flooding is a Very Good 
Thing.  And don’t get me wrong, I love flooding. For the things that should be 
flooded. :)


> 3) The controller is already in the network, why not rely on it to 
> relieve the pressure of ABRs if we prefer to the PUB/SUB model to solve the 
> questions. And, as you stated, the NLP mechanism may be used to transfer 
> other non-IGP information, then why bother ABR?


Yes, we can also solve the PUA problem via a controller. If the WG chooses to 
take that path, it can.  Heck, we could choose to say that we believe in the 
SDN philosophy completely and that IGPs should be deprecated in favor of SDN. 
Of course, this also addresses the PUA problem. :)

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

[Tony Li]

Peter,

> the combination is the (a) problem and that will be fixed. We are talking 
> problem (b) only now.


Ah, my apologies, I was unclear on the applicability of your statements.


> I'm not trying under-specify how to deal with overflow - we need to specify 
> it, no disagreement there.


I look forward to seeing a proposal. I propose allowing multiple FAD and 
concatenation of the contents.


> What I'm trying to see of we need to support the "merge" at FAD sub-TLV level.


I’ll agree that that’s lower priority.  I think we should, as a matter of 
completeness.

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

[Tony Li]

Peter,

> Once we get into FAD Sub-TLV overflow business, we would have to define, for 
> each FAD sub-TLV, whether multiple of them can exist and how to resolve 
> conflicts if only one is allowed. For all existing ones, I can only think of 
> SRLG to be the candidate for multiple.
> 
> I'm fine with adding extra complexity, but at least I would like to see some 
> practical use case behind it.


We are defining a mechanism right now that we would like to have be functional 
in perpetuity. We should not wait to redefine it when a P1 case comes in or 
when we get a billion dollar RFP.

Right now, we have the following subsubTLVs in the FlexAlgo draft:

Exclude Admin Group Sub-TLV
Include-Any Admin Group Sub-TLV
Include-All Admin Group Sub-TLV
Flags Sub-TLV
Exclude SRLG Sub-TLV

We can and should expect more in the future.  We cannot predict how many octets 
the future subsubTLVs will hold.

Each of the Admin Group subsubTLVs can hold an extended admin group. There is 
no hard bound to the number of bits 
in the extended admin group and thus each subsubTLV could, theoretically, fill 
the FAD subTLV. Obviously, the
combination of multiple ones could as well.

The flags subsubTLV is only one octet of contents today, but is also unbounded.

And the SRLG subsubTLV is, as noted, unbounded.

I submit that we are already in the overflow business, right now, and that not 
specifying how to deal with overflow is an egregious 
under-specification of the mechanism and a disservice to all of our 
implementors.

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

[Tony Li]

> On Mar 4, 2022, at 8:50 AM, Peter Psenak  wrote:
> 
> not at all.
> 
> I just don't want to get into business of merging info from several FAD's 
> sub-TLVs of the same type unless there is a compelling reason to do so? So 
> far I have not seen any. Asking for 100s of excluded SRLGs in the FAD does 
> not seem like a realistic case to me.


Then how do we deal with subTLV overflow?

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

[Tony Li]

Hi Peter,


> I would prefer to address the "else clause"  in a following way:
> 
> a) any FAD sub-TLV MUST only appear once in a the FAD definition for a given 
> algorithm from a given source
> 
> b) in case the FAD sub-TLV appear multiple times, the values in the sub-TLV 
> in the first occurrence in the lowest numbered LSP from a given source MUST 
> be preferred.
> 
> 
> Above does not support the "merge" of the values from multiple FAD sub-TLVs, 
> but as we all agree that is unlikely a requirement.



So, you’re in favor of mandating that FlexAlgo has fixed limitations on the 
scale and complexity of its definitions?

Will you be taking the phone calls from our irate customers?  

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

[Tony Li]

Peter,


> I believe there is a subtle difference between what each of you is saying:
> 
> a) Tony says that there may be many constraints used for a particular 
> flex-algo, so that we may not be able to fit them in a single FAD Sub-TLV. I 
> agree, we better address that. I will update the flex-algo draft accordingly.
> 
> b) Gunter says that a particular Sub-TLV of the FAD Sub-TLV, on its own, may 
> not fit into a single FAD Sub-TLV. Although theoretically possible (with 
> SRLGs only for now, I believe), I don't feel like it's very realistic.
> 
> I agree to address (a),  not very enthusiastic about addressing (b).
> 
> Please let me know what do you think.


Thank you for bringing out that distinction. Yes, that’s accurate and an 
important distinction that I had completely missed. 

I think that both issues are worth addressing. I am thrilled that you’re 
willing to address (a). 

On (b), I agree that it’s an issue and one that is unlikely to be seen in 
practice. Still, someone has to write code. As my friend Fletch has always 
said: “The programmer has to fill in that else clause.” So I would like to 
encourage you to address it as well. Yes, I realize that it’s no fun, but it 
does deserve to be written down. Please feel free to borrow language from the 
multi-tlv draft. :)

Regards,
Tony

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