Re: [Lsr] IETF 118 LSR Minutes

FWIW – The new format for the chatlog is much less readable than previous. Here is the format from IETF 116: Ketan Talaulikar 00:39:39 There is a WG draft for per-algo adj-sid : https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/ If we have large number of links,

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

Xiaohu – I also point out that there are at least two existing drafts which specifically address IS-IS flooding reduction in CLOS networks and do so in greater detail and with more robustness than what is in your draft: https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/ https://data

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

Bruno – You began your comments in the context of the adoption thread (Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)). I note that you subsequently started a new thread with new (Subject: draft-pkaneria-lsr-multi-tlv). But as the new thread continu

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

Huaimo - Every statement you make below is false. These points have been discussed - in WG meetings, on the mailing list, and in private conversations. But you persist in repeating false claims. This is not helpful. You are, of course, entitled to have whatever opinion you choose regarding MP v

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

Bruno - First, without dismissing your comments, this is a WG adoption call - not a Last Call to publish a draft as an RFC (as Tony has pointed out). Could you state unambiguously whether you support adoption or not? I am in agreement with Tony's responses. I think my earlier reply to you is ve

Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

I support adoption of this draft. It is a reasonable (and well proven) solution to a real world problem. Les > -Original Message- > From: Lsr On Behalf Of Acee Lindem > Sent: Friday, November 17, 2023 8:02 AM > To: Lsr > Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org > Subject:

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

: Acee Lindem Cc: DECRAENE Bruno INNOV/NET ; Les Ginsberg (ginsberg) ; Loa Andersson ; lsr@ietf.org Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang Hi, About the name, here are some suggestions about the module name and prefix: * ietf-isis-feature-support.yang, isis-fs (YANG Module

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

+2 support adoption as coauthor (Chairs – is it really necessary for the authors to express support for their own draft? 😊) Les From: Tony Przygienda Sent: Friday, November 17, 2023 10:29 AM To: Tony Li Cc: Yingzhen Qu ; draft-pkaneria-lsr-multi-...@ietf.org; lsr Subject: Re: [Lsr] WG Ad

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

"No, I'm not aware of any IPR that applies to this draft" Les From: Yingzhen Qu Sent: Friday, November 17, 2023 9:01 AM To: draft-pkaneria-lsr-multi-...@ietf.org; lsr Cc: lsr-chairs Subject: IPR Poll for draft-pkaneria-lsr-multi-tlv Hi, This is an IPR call for draft-pkaneria-lsr-multi-tl

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

Acee – Thanx for the comments – inline. From: Acee Lindem Sent: Thursday, November 16, 2023 2:33 PM To: Les Ginsberg (ginsberg) Cc: Loa Andersson ; lsr@ietf.org Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang Speaking as a WG contributor: Hi Les, I think a simpler name is better

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

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 a

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Bruno – Thanx for the thoughtful comments. Please see responses inline. From: bruno.decra...@orange.com Sent: Thursday, November 16, 2023 6:40 AM To: Les Ginsberg (ginsberg) ; Christian Hopps Cc: lsr@ietf.org Subject: RE: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

Ketan – I am very happy to be wrong in this case. 😊 We are in full agreement. Les From: Lsr On Behalf Of Ketan Talaulikar Sent: Monday, November 6, 2023 11:52 PM To: Les Ginsberg (ginsberg) Cc: John Drake ; Peter Psenak (ppsenak) ; Aijun Wang ; lsr@ietf.org Subject: Re: [Lsr] Technical

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

To add to what Ketan has stated… draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism for both OSPF and IS-IS i.e., it proposes to use a prefix-originator sub-TLV with address set to 0.0.0.0 to indicate unreachability. For OSPF, this might be considered compatible with RFC 90

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Hopps > Sent: Monday, November 6, 2023 6:10 AM > To: Les Ginsberg (ginsberg) > Cc: Christian Hopps ; lsr@ietf.org > Subject: Re: draft-pkaneria-lsr-multi-tlv and "backwards compatibility" > > > My point is that people are not using the same definition of b

[Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Chris (and everyone) - A more complete response to your comments regarding "backwards compatibility", routing loops, etc. It is absolutely true that until all nodes in the network support advertisement (meaning at least receive processing) of more than 255 bytes for a given object, that an

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

, November 5, 2023 3:06 PM To: Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: RE: draft-chen-lsr-isis-big-tlv Hi Les, Thank you very much for your responses. draft-chen-lsr-isis-big-tlv resolves the issue: unpredictable behavior with partial deployment, which are stated in both IETF 117 and IETF

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

Huaimo - Thanx for bringing this up. Resolving this before the meeting hopefully will save us time during the meeting. "Backwards compatibility" is possible in situations where new advertisements are being introduced and the legacy nodes either: * Don't need to process the new advertiseme

Re: [Lsr] Fw: New Version Notification for draft-liu-lsr-igp-mpd-00.txt

Yao – A few comments… While I appreciate that the limits you are defining are different than any of the limits currently supported by the IGP MSD-Types registry, I think they still fall conceptually into the same generic bucket i.e., you want to advertise a limit related to a type of packet en

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

Acee - From: Acee Lindem Sent: Thursday, August 31, 2023 10:33 AM To: Acee Lindem Cc: lsr ; draft-ietf-lsr-isis-fast-flood...@ietf.org Subject: Re: Working Group Last Call for "IS-IS Fast Flooding" - draft-ietf-lsr-isis-fast-flooding-04 I support publication. I’ve done the shepherds review an

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

. Les Thanks Zhibo Les > > Thanks > > Zhibo Hu > > > -Original Message- > > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg > > (ginsberg) > > Sent: Thursday, August 31, 2023 12:31 AM > > To: Pet

Re: [Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

rereading is of no help – please ask someone else to explain it to you – I do not know how to state things more clearly than I have. Respectfully, Les From: Lsr On Behalf Of Aijun Wang Sent: Wednesday, August 30, 2023 8:37 PM To: 'Les Ginsberg (ginsberg)' ; 'Huzhibo&#

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

Zhibo - Please see inline. > -Original Message- > From: Huzhibo > Sent: Wednesday, August 30, 2023 6:33 PM > To: Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak) > ; linchangwang ; > Acee Lindem ; lsr > Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ie

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

Changwang - It is very important to note ... > > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and [RFC9084] to > indicate reachability by checking whether the originator information is > >NULL. This statement is incorrect. There is no existing mechanism defined in the protoc

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

needs to be made explicit (as RFC 9088 did) and some explanation as to “why” should be included in the draft. Les From: Tony Li On Behalf Of Tony Li Sent: Tuesday, August 29, 2023 7:15 AM To: liu.ya...@zte.com.cn Cc: Les Ginsberg (ginsberg) ; mpls ; lsr@ietf.org Subject: Re: [Lsr] New

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 f

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

I support WG adoption. The problem is a useful problem to solve and the solution defined in the document has been implemented and proven to work. Les > -Original Message- > From: Lsr On Behalf Of Acee Lindem > Sent: Wednesday, August 23, 2023 1:07 PM > To: lsr > Cc: draft-ppsenak-l

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

I am not aware of any undisclosed IPR. Les From: Acee Lindem Sent: Wednesday, July 19, 2023 4:20 PM To: draft-ietf-lsr-isis-fast-flood...@ietf.org Cc: lsr Subject: WG Last Call IPR Poll for "IS-IS Fast Flooding" - draft-ietf-lsr-isis-fast-flooding-04 Authors, A cornucopia of IPR declar

Re: [Lsr] Andrew Alston's No Objection on draft-ietf-lsr-rfc8919bis-03: (with COMMENT)

Andrew - Thanx for the review. S-bit is dataplane independent because it is applicable to both SR-MPLS and SRv6. Les > -Original Message- > From: Andrew Alston via Datatracker > Sent: Thursday, May 25, 2023 6:09 AM > To: The IESG > Cc: draft-ietf-lsr-rfc8919...@ietf.org; lsr-cha..

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

Rob - Thanx for the review. Yes, the update to the Introduction was done in response to Warren's comment. Some offline discussion resulted in adding this to the Introduction rather than the Abstract. Les > -Original Message- > From: Robert Wilton via Datatracker > Sent: Thursday, M

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

Lars - Thanx for the review. Responses inline - though I have to say your section references are a "little bit off" - not sure why. > -Original Message- > From: Lars Eggert via Datatracker > Sent: Wednesday, May 24, 2023 11:24 PM > To: The IESG > Cc: draft-ietf-lsr-rfc8920...@ietf.org;

Re: [Lsr] Secdir last call review of draft-ietf-lsr-rfc8920bis-03

Scott - Thanx for your review. I have uploaded V4 of the draft with the change you suggested. Les > -Original Message- > From: Scott Kelly via Datatracker > Sent: Monday, May 22, 2023 9:12 AM > To: sec...@ietf.org > Cc: draft-ietf-lsr-rfc8920bis@ietf.org; last-c...@ietf.org; ls

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

Done and posted new versions for both 8919bis and 8920bis. Les From: John Scudder Sent: Friday, May 19, 2023 7:41 AM To: Warren Kumari Cc: Les Ginsberg (ginsberg) ; The IESG ; draft-ietf-lsr-rfc8919...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; cho...@chopps.org Subject: Re: Warren

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

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

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

Watson - Where are we with this discission? Have my responses clarified things sufficiently or do you still have unresolved issues? Thanx. Les > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: Friday, May 5, 2023 4:54 PM > To: Watson Ladd > Cc: secdir ;

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

age- > From: Les Ginsberg (ginsberg) > Sent: Wednesday, May 3, 2023 1:00 PM > To: Robert Sparks ; John Scudder > > Cc: gen-...@ietf.org; draft-ietf-lsr-rfc8919bis@ietf.org; > last-c...@ietf.org; > lsr@ietf.org > Subject: RE: Genart last call review of draft-ietf-

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

Watson - Please see LES2: inline. > -Original Message- > From: Watson Ladd > Sent: Friday, May 5, 2023 3:32 PM > To: Les Ginsberg (ginsberg) > Cc: secdir ; draft-ietf-lsr-rfc8919bis@ietf.org; last- > c...@ietf.org; lsr@ietf.org > Subject: Re: Secdir last call

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

Watson - Before responding to your comments, I point out that this is a bis of RFC 8919 - and it makes no changes to the protocol extensions defined in RFC 8919 - it only provides some clarifications so that readers/implementors are more likely to have a common understanding. The Security secti

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

Joseph - Thanx for your review. Les > -Original Message- > From: Joseph Yee via Datatracker > Sent: Thursday, May 4, 2023 8:35 PM > To: a...@ietf.org > Cc: draft-ietf-lsr-rfc8919bis@ietf.org; last-c...@ietf.org; lsr@ietf.org > Subject: Artart last call review of draft-ietf-lsr-r

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

> -Original Message- > From: Robert Sparks > Sent: Wednesday, May 3, 2023 11:18 AM > To: John Scudder ; Les Ginsberg (ginsberg) > > Cc: gen-...@ietf.org; draft-ietf-lsr-rfc8919bis@ietf.org; > last-c...@ietf.org; > lsr@ietf.org > Subject: Re: Genart last call review of d

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

Robert - Thanx for your review - apologies for the delay in responding. Please see inline. > -Original Message- > From: Robert Sparks via Datatracker > Sent: Thursday, April 27, 2023 1:09 PM > To: gen-...@ietf.org > Cc: draft-ietf-lsr-rfc8919bis@ietf.org; last-c...@ietf.org; lsr@ietf

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

Tom - I have submitted V1 to address all of the comments from you that I deemed possible/desirable to do. Please see responses inline as to the unaddressed issues. > -Original Message- > From: tom petch > Sent: Friday, April 21, 2023 4:55 AM > To: Les Ginsberg (ginsberg) ;

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

Tom - https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml At the very top it says: "IS-IS TLV Codepoints" Les > -Original Message- > From: tom petch > Sent: Thursday, April 20, 2023 9:05 AM > To: John Scudder > Cc: cho...@chopps.org; draft-ietf-lsr-rfc89

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

John - > -Original Message- > From: John Scudder > Sent: Thursday, April 20, 2023 7:48 AM > To: Les Ginsberg (ginsberg) > Cc: tom petch ; cho...@chopps.org; draft-ietf-lsr- > rfc8919...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org > Subject: Re: [Ls

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

Tom - Thanx for catching this. John - will correct this in the next version. Also to John - if you have provided a review of the bis draft (as you suggest below) I don’t seem to have seen it. Did you send it to the list?? Or are you referring to your comments from last year which resulted in th

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm

etailed in the draft. Otherwise, casual readers will think that nothing is lost when the encoding efficiency is used. This isn’t a minor point in my view. Les > -Original Message- > From: Louis Chan > Sent: Thursday, April 13, 2023 11:21 PM > To: Les Ginsberg (ginsberg)

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm

the useful discussion. Les > -Original Message- > From: Louis Chan > Sent: Wednesday, April 12, 2023 8:45 PM > To: Les Ginsberg (ginsberg) ; Acee Lindem > > Cc: lsr ; Krzysztof Szarkowicz ; > Weiqiang Cheng > Subject: RE: [Lsr] IETF-116 LSR - IGP extension

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm

Louis – I am having increasing difficulty in correlating what you say in this thread and what is actually written in the draft. Please see responses inline. Look for LES2: From: Louis Chan Sent: Tuesday, April 11, 2023 7:46 PM To: Les Ginsberg (ginsberg) ; Acee Lindem Cc: lsr ; Krzysztof

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm

Louis - Please see inline. > -Original Message- > From: Louis Chan > Sent: Monday, April 10, 2023 11:01 PM > To: Les Ginsberg (ginsberg) ; Acee Lindem > > Cc: lsr ; Krzysztof Szarkowicz ; > Weiqiang Cheng > Subject: RE: [Lsr] IETF-116 LSR - IGP ex

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm

OK - since Acee opened the door - here are some comments from me - starting with the most important. (BTW - I still have limited enthusiasm for this draft.) 1)The proposal places some restrictions on how operators provision their network in terms of assigning SIDs and reserving space for future

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

restarting router before that router is ready to forward them. So long as whatever solution you come up with addresses that issue, then I am satisfied. Thanx. Les > -Original Message- > From: Acee Lindem > Sent: Tuesday, March 28, 2023 9:00 PM > To: Les Ginsberg (ginsberg)

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

Chris - > -Original Message- > From: Christian Hopps > Sent: Tuesday, March 28, 2023 11:40 PM > To: Les Ginsberg (ginsberg) > Cc: Christian Hopps ; Huaimo Chen > ; draft-chen-lsr-isis-big-tlv.auth...@ietf.org; > lsr@ietf.org > Subject: Re: [Lsr] Comments on dra

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

ay, March 28, 2023 6:45 PM > To: Les Ginsberg (ginsberg) ; Christian Hopps > > Cc: Huaimo Chen ; draft-chen-lsr-isis-big- > tlv.auth...@ietf.org; lsr@ietf.org > Subject: RE: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00 > > Les, all > > > From:

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

updated Router LSA from the restarting router and the updated Router LSA on the neighbor there is still some risk. Les > -Original Message- > From: Acee Lindem > Sent: Tuesday, March 28, 2023 2:19 PM > To: Les Ginsberg (ginsberg) > Cc: Liyan Gong ; Tony Przygienda &g

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

configuration, needs to be able to receive > >> > sub-TLVs 2,4,6,8,10 from A. > >> > > >> > > >> > > >> > There is no way that A can advertise all 10 sub-TLVs in a way which > >> > allows both B and C to correctly process the s

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

uld be said of any style. 😊 > -Original Message- > From: Christian Hopps > Sent: Tuesday, March 28, 2023 7:27 AM > To: Les Ginsberg (ginsberg) > Cc: Huaimo Chen ; draft-chen-lsr-isis-big- > tlv.auth...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Comments on draft-c

Re: [Lsr] UPA and planned/unplanned signalling

Shraddha - Glad we have come to a common understanding. One point inline. > -Original Message- > From: Shraddha Hegde > Sent: Monday, March 27, 2023 10:47 PM > To: Les Ginsberg (ginsberg) ; lsr@ietf.org > Subject: RE: UPA and planned/unplanned signalling > > Les

Re: [Lsr] UPA and planned/unplanned signalling

Les > -Original Message- > From: Shraddha Hegde > Sent: Monday, March 27, 2023 9:25 PM > To: Les Ginsberg (ginsberg) ; lsr@ietf.org > Subject: RE: UPA and planned/unplanned signalling > > Hi Les, > > Pls see inline for replies. > > > Juniper Busi

[Lsr] UPA and planned/unplanned signalling

Shraddha - To follow up on our discussion over chat at the LSR meeting yesterday... At a remote ABR, if BGP had already been told about a planned node maintenance event (by means that is outside the scope of the UPA draft), then BGP would have moved traffic away from the node on which the maint

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

Tony - From: Tony Przygienda Sent: Monday, March 27, 2023 5:11 PM To: Les Ginsberg (ginsberg) Cc: Acee Lindem ; Liyan Gong ; chen.mengxiao ; lsr ; Weiqiang Cheng ; linchangwang Subject: Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt I didn't say "

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

: Tony Przygienda Sent: Monday, March 27, 2023 3:29 PM To: Acee Lindem Cc: Liyan Gong ; chen.mengxiao ; Les Ginsberg (ginsberg) ; lsr ; Weiqiang Cheng ; linchangwang Subject: Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt thought about it. there are also other

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

Huaimo - Please see inline. From: Huaimo Chen Sent: Sunday, March 26, 2023 3:41 AM To: Les Ginsberg (ginsberg) ; lsr@ietf.org; draft-chen-lsr-isis-big-tlv.auth...@ietf.org Subject: Re: Comments on draft-chen-lsr-isis-big-tlv-00 Hi Les, Thanks much for your comments. My responses are

[Lsr] 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 i

Re: [Lsr] LSR WG Adoption Call for "IGP Flexible Algorithms Reverse Affinity Constraint" - draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-01

I support adoption of this very useful extension to flex-algo capabilities. Les > -Original Message- > From: Lsr On Behalf Of Acee Lindem > Sent: Friday, March 10, 2023 5:09 AM > To: lsr > Subject: [Lsr] LSR WG Adoption Call for "IGP Flexible Algorithms Reverse > Affinity Constraint"

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

Tony – Inline…but I agree we can let this simmer for a while… From: Antoni Przygienda Sent: Friday, March 10, 2023 12:55 PM To: Les Ginsberg (ginsberg) ; lsr@ietf.org; draft-ietf-lsr-distoptflood.auth...@ietf.org Subject: Re: Comments on draft-ietf-lsr-distoptflood-01 Thanks, most of the

[Lsr] Comments on draft-wang-lsr-redistribution-credibility-id

(Changing the subject to avoid confusion with all other "slot requests") I agree with Acee that there are existing solutions for this problem space. I also believe your approach is quite problematic. To maintain the count ("TTR") accurately, you would require full deployment of this extension -

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

I am somewhat belated in commenting on the updated draft - apologies for that. I thank the authors for addressing my comments and think the draft is significantly improved. I do still have two issues - one minor and one more significant. Minor issue: I think you need a formal IANA section

Re: [Lsr] New Version Notification for draft-cheng-ospf-adjacency-suppress-00.txt

+1 to what Acee has said. As historical context, the SA bit was defined in IS-IS precisely because IS-IS adjacency state machine does NOT include LSPDB sync as a requirement before the adjacency is usable (unlike OSPF). OSPF does not need SA bit. Les > -Original Message- > From: Lsr

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

(At the risks of giving this issue more attention than it merits…) My interpretation of the filed Errata is that the submitter incorrectly thought that the text should be referring to the protocol (IS-IS) and that the text had been inadvertently truncated. Consider that the “Note” says: “Incorr

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

I am not aware of any undisclosed IPR. Les > -Original Message- > From: Acee Lindem > Sent: Wednesday, February 22, 2023 1:46 PM > To: draft-ietf-lsr-dynamic-flood...@ietf.org > Cc: lsr > Subject: Work Group Last Call IPR Call for 'Dynamic-Flooding on Dense > Graphs" - draft-ietf-lsr

Re: [Lsr] Info on Authentication type for Keyed MD5 and HMAC-SHA2 family

Acee - Note that in IS-IS there is no keyid in the authentication TLV for MD5 (see RFC 5304), but there is a 16 bit keyid for crypto: https://www.rfc-editor.org/rfc/rfc5310.html#section-3.1 That said, I agree there is no significant advantage to including the authentication type. Les >

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

Chris - Thanx - my bad. Never noticed the second link. Les > -Original Message- > From: Christian Hopps > Sent: Wednesday, February 15, 2023 8:12 PM > To: Les Ginsberg (ginsberg) > Cc: Christian Hopps ; Chris Parker > ; Shraddha Hegde ; > Acee Lindem ; lsr@i

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

erlot and Shiraz and it would have no impact on traffic. Les > -Original Message- > From: Christian Hopps > Sent: Wednesday, February 15, 2023 4:54 AM > To: Chris Parker > Cc: Christian Hopps ; Shraddha Hegde > ; Les Ginsberg (ginsberg) ; > Acee Lindem ; ls

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

Chris – Indeed – welcome to the forum. The concept of area address in IS-IS has confused many – including folks with a much longer history than you. Please see inline. From: Chris Parker Sent: Tuesday, February 14, 2023 2:16 AM To: Shraddha Hegde Cc: Les Ginsberg (ginsberg) ; Acee Lindem

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

Disclaimer: I am not an author of the flex-algo draft. However, the text regarding "scope" of the FAD sub-TLV is in the context of the flooding scope of the containing Router Capability TLV (as defined in RFC 7981). There we have two scopes defined: 1)Area/level scope (S-bit clear) Such informa

Re: [Lsr] FW: I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

Shraddha - I think Mengxiao has raised a legitimate point. The use of max-metric to exclude a link is at best redundant in flex-algo since there are existing ways to exclude a link. Simply quoting RFC 5305 doesn’t really help in understanding the motivation of the authors in adding this restric

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt

Shraddha - Regarding the new Generic Metric sub-TLV, there is a significant omission in the draft: Given that (as you discuss in Sections 2.1 and 2.2) some metric types cannot be advertised in the new Generic Metric sub-TLV because they are specified to be advertised in a different encoding, i

Re: [Lsr] I-D Action: draft-ietf-lsr-rfc8920bis-01.txt

(Resending - minus id-announce list) This new version addresses those comments from Tom Petch which the authors agreed to address. I have previously replied to Tom indicating why some of his comments might not be addressed. Les > -Original Message- > From: Lsr On Behalf Of internet

Re: [Lsr] I-D Action: draft-ietf-lsr-rfc8920bis-01.txt

This new version addresses those comments from Tom Petch which the authors agreed to address. I have previously replied to Tom indicating why some of his comments might not be addressed. Les > -Original Message- > From: Lsr On Behalf Of internet-dra...@ietf.org > Sent: Tuesday, Janu

Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00

comments are being seriously considered, even if - in the end - the drafts are not changed in the way you suggest. More inline. Look for LES2. > -Original Message- > From: tom petch > Sent: Thursday, December 8, 2022 9:00 AM > To: Les Ginsberg (ginsberg) ; Christian Ho

Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00

Tom - > -Original Message- > From: tom petch > Sent: Thursday, December 8, 2022 2:52 AM > To: Christian Hopps ; lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr-rfc8920...@ietf.org > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00 > > From: Lsr o

Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00

I am not aware of any IPR related to this draft. Les > -Original Message- > From: Christian Hopps > Sent: Wednesday, December 7, 2022 5:20 AM > To: lsr@ietf.org > Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr- > rfc8920...@ietf.org > Subject: WG Last Ca

Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8919bis-00

I am not aware of any IPR related to this draft. Les > -Original Message- > From: Christian Hopps > Sent: Wednesday, December 7, 2022 5:20 AM > To: lsr@ietf.org > Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr- > rfc8919...@ietf.org > Subject: WG Last Cal

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

Bruno - Some responses inline - speaking only for myself - not necessarily for all of the co-authors... From: Lsr On Behalf Of bruno.decra...@orange.com Sent: Thursday, December 1, 2022 6:04 AM To: Tony Li ; lsr Subject: Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv

Re: [Lsr] Questions on draft-white-lsr-distoptflood

nothing needs to be said in this regard isn’t justified. Les From: Tony Przygienda Sent: Monday, November 28, 2022 10:27 AM To: Les Ginsberg (ginsberg) Cc: draft-white-lsr-distoptflood.auth...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] Questions on draft-white-lsr-distoptflood On Mon, Nov 28

Re: [Lsr] Questions on draft-white-lsr-distoptflood

Tony - From: Tony Przygienda Sent: Monday, November 28, 2022 10:06 AM To: Les Ginsberg (ginsberg) Cc: r...@riw.us; draft-white-lsr-distoptflood.auth...@ietf.org; lsr@ietf.org Subject: Re: Re[2]: [Lsr] Questions on draft-white-lsr-distoptflood On Mon, Nov 28, 2022 at 6:22 PM Les Ginsberg

Re: [Lsr] Questions on draft-white-lsr-distoptflood

Hi Russ! > -Original Message- > From: r...@riw.us > Sent: Monday, November 28, 2022 4:56 AM > To: Les Ginsberg (ginsberg) ; Tony Przygienda > > Cc: draft-white-lsr-distoptflood.auth...@ietf.org; lsr@ietf.org > Subject: Re[2]: [Lsr] Questions on draft-white-lsr-di

Re: [Lsr] Questions on draft-white-lsr-distoptflood

draft and an analysis of the benefits under some realistic flooding scenarios. Les From: Tony Przygienda Sent: Friday, November 25, 2022 1:06 AM To: Les Ginsberg (ginsberg) Cc: draft-white-lsr-distoptflood.auth...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] Questions on draft-white-lsr

[Lsr] Questions on draft-white-lsr-distoptflood

Draft authors - The WG adoption call reminded me that I had some questions following the presentation of this draft at IETF 114 which we decided to "take to the list" - but we/I never did. Looking at the minutes, there was this exchange: Les: I'm not convinced that you don't need to

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

Chris/David - > > I was replying to Peter saying that implementations are using the max metric > announcements to avoid sending traffic to overload routers. [LES:] Are you claiming this because you know this to be true - or are you just speculating that an implementation "might" do this? If t

Re: [Lsr] Reply: Comments on draft-yue-lsr-loop-detection-for-imported-routes

ory. Thanx. Les From: yuezhuo Sent: Tuesday, November 8, 2022 6:36 PM To: Les Ginsberg (ginsberg) ; draft-yue-lsr-loop-detection-for-imported-routes.auth...@ietf.org Cc: lsr@ietf.org Subject: Reply: Comments on draft-yue-lsr-loop-detection-for-imported-routes Hi Les, Thanks for your comme

[Lsr] Last Call Request for draft-ietf-lsr-rfc8920bis

The authors of draft-ietf-lsr-rfc8920bis request WG last call. The changes in this bis draft are clarifications to the existing RFC which have been thoroughly discussed by the WG. The changes were originally discussed over a year a

[Lsr] Last Call Request for draft-ietf-lsr-rfc8919bis

The authors of draft-ietf-lsr-rfc8919bis request WG last call. The changes in this bis draft are clarifications to the existing RFC which have been thoroughly discussed by the WG. The changes were originally discussed over a year a

[Lsr] Comments on draft-yue-lsr-loop-detection-for-imported-routes

Draft authors - I have read the draft. Everything you propose has already been defined in RFC 7794. This draft is completely redundant and should be abandoned. In light of this, you should consider withdrawing your item from the WG meeting agenda - there is no reason for the WG to consider this

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

you are telling me that I do not need to restate that no encoding changes are required - point taken. Les > -Original Message- > From: Christian Hopps > Sent: Tuesday, October 25, 2022 2:29 PM > To: Les Ginsberg (ginsberg) > Cc: bruno.decra...@orange.com; Christian

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

encoding MP-TLVs requires no protocol extensions. This in no way conflicts with the previous sentence. Please see inline. > -Original Message- > From: bruno.decra...@orange.com > Sent: Monday, October 24, 2022 6:22 AM > To: Les Ginsberg (ginsberg) ; Christian Hopps >

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

WG Chairs - I note that the draft is still in Call For Adoption By WG Issued state. ?? I had hoped to be able to request WG Last Call at IETF 115. Is there anything blocking this? Les > -Original Message- > From: Lsr On Behalf Of Christian Hopps > Sent: Monday, August 8, 2022 3:17

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

WG Chairs - I note that the draft is still in Call For Adoption By WG Issued state. ?? I had hoped to be able to request WG Last Call at IETF 115. Is there anything blocking this? Les > -Original Message- > From: Lsr On Behalf Of Christian Hopps > Sent: Monday, August 8, 2022 3:17

[Lsr] Spreadsheet Documenting MP-TLV support

(starting a new thread) Folks - Based on a suggestion from Chris >> I think the [multi-tlv] 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 O

Re: [Lsr] Multi-part TLVs for extending sub-tlv space...

e are necessary i.e., please define your recommended solution. Thanx. Les > -Original Message- > From: Lsr On Behalf Of Christian Hopps > Sent: Sunday, October 9, 2022 11:51 AM > To: Christian Hopps > Cc: Les Ginsberg (ginsberg) ; Tony Li ; > Peter Psenak (

<    1   2   3   4   5   6   7   8   9   10   >