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

Support, as author. T > On May 22, 2024, at 8:59 AM, Yingzhen Qu wrote: > > Hi, > > This email begins a 2 week WG Last Call for the following draft: > draft-ietf-lsr-labv-registration-00 - Revision to Registration Procedures for > IS-IS Neighbor Link-Attribute Bit Values >

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

Done. Can we please now progress the document? Thanks, Tony > On May 20, 2024, at 7:04 AM, Yingzhen Qu wrote: > > The adoption call is now concluded, and the draft is adopted. > > Authors, please publish the draft as draft-ietf-lsr-labv-registration. > > Thanks, > Yingzhen > > On Mon,

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

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

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

s 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 > > > >> -Origi

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

Per Les’ requeest. Elapsed time: 3 mins. T > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-li-lsr-labv-registration-01.txt > Date: April 23, 2024 at 4:24:44 PM PDT > To: "Tony Li" > > A new vers

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

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

@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 poste

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

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

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

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

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

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,

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

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

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

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

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

ate: 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 subm

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi Murray, Thank you for your comments. > -- > COMMENT: > -- > > Section 7 creates a registry whose policy is partly Expert Review, but doesn't > give any

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

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 >

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

Hi Roman, Alexy, Thank you for your comments. > -- > DISCUSS: > -- > > ** Section 4.3. Do all the candidates need the Area Proxy System Identifier > TLVs

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

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

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

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

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

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&q

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

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

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

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

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

Hi Linda, > Suppose the information to be carried by the Extended IS Reachability (type > 22) (in Example 4.1) is larger than 255. Does it mean the recipient will > receive 2 TLVs (both with the Type 22) in one LSA? For legacy routers, the > second TLV (Type =22) might overwrite the first

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

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

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

hat 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 ;

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

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

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

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

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,

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

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 >

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

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

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

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

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

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 >

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

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

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

"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

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

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

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

g 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[+ 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

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

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

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

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,

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

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

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

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

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

Gyan S. Mishra" , "Dave Cooper" > , "David Cooper" , > "Gyan Mishra" , "Huaimo Chen" > , "Les Ginsberg" , "Luay Jalil" > , "Peter Psenak" , "Srinath > Dontula" , "Tony Li" , "Tony Przy

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

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

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

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

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

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

Re: [Lsr] OSPF-GT

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

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

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

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

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"

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

> 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

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

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

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

rposes 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, T

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

t;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

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

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

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

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 >

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

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

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

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

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

rk 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, J

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 vers

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

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

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

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

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

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

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

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

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

> 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

  1   2   3   4   5   >