Re: [Lsr] Flags from draft-ietf-lsr-isis-srv6-extensions-19 and draft-ietf-lsr-ospfv3-srv6-extensions-08

Hi John, None of these are functional changes - just clarifying the OSPFv3 SR usage of the same IANA registry IS-IS SR. I don’t see why we can’t make these now or during AUTH48. > On Dec 14, 2022, at 4:59 PM, John Scudder > wrote: > > Hi Authors, WG, > > As part of my review of draft-iet

Re: [Lsr] Flags from draft-ietf-lsr-isis-srv6-extensions-19 and draft-ietf-lsr-ospfv3-srv6-extensions-08

Hi Peter, > On Dec 15, 2022, at 8:11 AM, Peter Psenak > wrote: > > On 15/12/2022 13:51, John Scudder wrote: >> Thanks, Peter. >> Doesn’t this mean that the OSPFv3 draft needs to create its own registry for >> the flags, then? > > it does. Section 2 defines the flags field in the OSPFv3 SR ca

Re: [Lsr] RFC 9339 on OSPF Reverse Metric

Authors and Reviewers, Thanks for the work on this OSPF enhancement to support existing IS-IS function. Acee > On Dec 21, 2022, at 2:49 AM, rfc-edi...@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > >RFC 9339 > >Title:

Re: [Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

023, at 4:49 AM, Antoni Przygienda > wrote: > > Informational? That is weird. If this is not an “experiment” then I don’t > know what is … > > • Tony > From: Acee Lindem (acee) > Date: Monday, 2 January 2023 at 22:04 > To: lsr@ietf.org , Antoni Przygienda , &g

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

+LSR List…. Hi Shraddha, I’ll request the ADs approve early allocation. However, I recall unanswered questions as to whether the generic metric was required and how it would be used. It isn’t required for the bandwidth constraints defined in the draft. Can you comment on this point? Than

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

is draft > has defined and used. > > Rgds > Shraddha > > > Juniper Business Use Only > > -Original Message- > From: Acee Lindem > Sent: Wednesday, January 11, 2023 11:44 PM > To: Shraddha Hegde ; lsr-...@ietf.org > Cc: lsr-cha...@ietf.org; draf

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

Hi Chris, > On Feb 13, 2023, at 2:56 PM, Chris Parker wrote: > > Hi all, > > First time poster here. Sincere apologies if I make any mistakes in > etiquette. I work at Juniper, and am mailing on suggestion of Shraddha Hegde, > after a conversation about draft-ietf-lsr-flex-algo. > > Having

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

Hi Chris, > On Feb 13, 2023, at 3:15 PM, Acee Lindem wrote: > > Hi Chris, > >> On Feb 13, 2023, at 2:56 PM, Chris Parker wrote: >> >> Hi all, >> >> First time poster here. Sincere apologies if I make any mistakes in >> etiquette. I

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

Hi Gun, RFC 2328 defined type 2 to generically refer to all cryptographic authentication types. Given that the key-id implies both the specific authentication algorithm and the key, I don’t see that this is a problem or that using different OSPF authentication types would have provided any si

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

t include a key-id in the packet. Thanks, Acee > > Thanks, > Vinayaka G > > On Thu, Feb 16, 2023 at 10:52 PM Acee Lindem wrote: > Hi Gun, > > RFC 2328 defined type 2 to generically refer to all cryptographic > authentication types. Given that the key-id implies

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

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

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

Thanks Tony - It looks good we’ll move to WG last call. Acee > On Feb 24, 2023, at 11:44 AM, Tony Li wrote: > > > FYI, > > This adopts Acee’s comments and a few other editorial changes. > > Tony > > >> Begin forwarded message: >> >> From: internet-dra...@ietf.org >> Subject: New Version

[Lsr] Working Last Call for "Dynamic Flooding on Dense Graphs" - draft-ietf-lsr-dynamic-flooding-12

There was a lot of LSR Working Group interest and excellent technical work on this draft and we’ve decided publish it on the “Experimental” track. We chose that track due to the complexity and the fact that there is only one known implementation. This starts the Working Group Last call for draf

Re: [Lsr] Working Last Call for "Dynamic Flooding on Dense Graphs" - draft-ietf-lsr-dynamic-flooding-12

Speaking as WG member: I support publication of this draft on the Experimental track. Thanks, Acee > On Feb 24, 2023, at 3:58 PM, Acee Lindem wrote: > > There was a lot of LSR Working Group interest and excellent technical work on > this draft > and we’ve decided pu

[Lsr] IS-IS Traffic Engineering (TE) Metric LAN Extensions - draft-li-lsr-isis-te-metric-lan-extensions-01

Speaking as WG member: Hi Chenxi, Why would anyone want these precise P2P metric on a LAN? Since it is a shared media, these are impossible to guarantee (unless the it the LAN is scantily under-provisioned). Also, if you did want to do TE on a LAN, why not just model it as a P2MP network

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

Hi Tony, > On Mar 4, 2023, at 4:42 PM, Tony Li wrote: > > > 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: > > On

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

I would not do anything. "IS" is correct in the text and it's > well known. > > my 2c, > Peter > > > On 05/03/2023 14:32, Acee Lindem wrote: >> Hi Tony, >>> On Mar 4, 2023, at 4:42 PM, Tony Li wrote: >>> >>> >>> Hi all

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

FU would be fine as well. Thanks, Acee > > —John > > [1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ > >> On Mar 6, 2023, at 7:39 AM, Acee Lindem wrote: >> >> >> Hi Peter, >> >> I agree it is not an erra

Re: [Lsr] Slot request for LSR IETF 116

+LSR I’m sorry but I don’t get this draft from a quick read. An OSPF router would not advertise an adjacency until the router is in FULL state. An OSPF router will not attain FULL state until database synchronization is complete. The following statement from you use case is incorrect: So,

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

Hi Liyan, I should replied to this Email rather than your request for an IETF 116 slot. Please reply to this one. I’m sorry but I don’t get this draft from a quick read. An OSPF router would not advertise an adjacency until the router is in FULL state. An OSPF router will not attain FULL stat

Re: [Lsr] Slot request for LSR IETF 116

n IS-IS and OSPF. Thanks, Acee > > Thanks, > Mengxiao > > -Original Message- > From: Acee Lindem > Sent: Monday, March 6, 2023 11:59 PM > To: Liyan Gong ; lsr > Cc: Yingzhen Qu ; lsr-chairs ; > Weiqiang Cheng ; linchangwang (RD) > ; chenmengxiao (

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

d unless both sides advertise it. Refer to section 16.1, step (2), check (b). Acee > > Thanks, > Mengxiao > > -Original Message- > From: Lsr On Behalf Of Les Ginsberg (ginsberg) > Sent: Tuesday, March 7, 2023 1:29 AM > To: Acee Lindem ; Liyan Gong > Cc: lsr >

Re: [Lsr] New Version Notificationfordraft-cheng-ospf-adjacency-suppress-00.txt

s to occur until R1 regenerates and floods > its own LSAs with higher sequence numbers. > > Thanks, > Mengxiao > > -Original Message- > From: Lsr On Behalf Of Les Ginsberg (ginsberg) > Sent: Tuesday, March 7, 2023 1:29 AM > To: Acee Lindem ; Liyan Gong > Cc

Re: [Lsr] Slot request for LSR IETF 116

Speaking as WG Member: Hi WQ, I have no doubt that your proposed extension could be used to suppress redistribution loops between routing domains. The question is why this is needed when this has been accomplished using route tags for decades. This is a solved problem and you need to convinc

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

The begins the LSR WG adoption call for "IGP Flexible Algorithms Reverse Affinity Constraint" - draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-01. Please express your support or objection on this list prior to Saturday, March 25th, 2023. We now have RFC 9350 (IGP Flex Also) and have deploy

[Lsr] WG Adoption IPR Poll for "IGP Flexible Algorithms Reverse Affinity Constraint" - draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-01

Co-Authors, Are you aware of any IPR that applies to draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-01? 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 re

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

Speaking as WG member: I support adoption of this simple but useful extension to IGP Flex Algorithm. Thanks, Acee > On Mar 10, 2023, at 8:08 AM, Acee Lindem wrote: > > > The begins the LSR WG adoption call for "IGP Flexible Algorithms Reverse > Affinity Constraint"

Re: [Lsr] New Version Notificationfordraft-cheng-ospf-adjacency-suppress-00.txt

, Acee > On Mar 7, 2023, at 1:34 PM, Acee Lindem wrote: > > Hi Liyan, > > This is very unlikely to happen as flooding between the routers commences as > soon as they reach Exchange state. I’m wondering if you’ve actually seen this > situation or it is hypothetical. >

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

I’m still missing IPR responses from David Cooper and Srinath Dontula. Thanks, Acee > On Feb 22, 2023, at 4: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 di

[Lsr] WG Last Call Completed for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-ietf-lsr-ip-flexalgo-08

The WG Last Call has completed for “IGP Flexible Algorithms in IP Networks”. Changes based on last call comments are reflected in the -08 version - mainly related to the use of the NU-bit for IPv6 locators. I will request publication. Thanks, Acee __

[Lsr] Working Group Co-Chair Change of Affiliation

I am no longer employed by Cisco and am now working for LabN Consulting. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Slides for 116 LSR WG Meeting

IETF 116 LSR Presenters, We still only have 5 slide decks and we have the first agenda slot at !ETF 116 (only a day and a half from now). Don’t think we’re going to let you waltz up to the mic and present from your own laptop. Please send your slides ASAP!! Thanks, Acee

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

The WG adoption poll has completed with modest support and no objection to making this a WG document. Please republish the draft as draft-ietf-lsr-igp-flex-algo-reverse-affinity-00 Thanks, Acee > On Mar 10, 2023, at 8:08 AM, Acee Lindem wrote: > > > The begins the LSR WG adopt

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

t; 主题：Re: > [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt > > Hi Acee, > > > > Yes,it is a real problem we've actually seen. > > > > Especially when the neighbor Rouer B has many more LSAs than the Restart > Router A. >

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

> Best Regards, > > Liyan > > > > > 邮件原文 > 发件人："Les Ginsberg \\(ginsberg\\)" <mailto:ginsberg=40cisco@dmarc.ietf.org>> > 收件人：Tony Przygienda mailto:tonysi...@gmail.com>> > 抄　送: Acee Lindem mailto:acee.i...@gmai

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

That explains it and it is actually the right thing to do from the perspective of the IETF document process. https://www.rfc-editor.org/materials/abbrev.expansion.txt Note that LSP is not asterisked as being well known and “Label Switched Path” is the first alternative. It should always be exp

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

e the next link in V's LSA.[23] The restarting router can delay advertising the link to account for any required delays. Thanks, Acee > > If you don’t want to use SA bit that’s fine – but I think you do need some > signaling. > >Les > > &

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

last time it was restarted. In most cases, the router must then advance the LSA's LS sequence number one past the received LS sequence number, and originate a new instance of the LSA. Thanks, Acee >Les > From: Acee Lindem > Sent: Tuesday, March

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

nks, Acee > > Les > >> -Original Message- >> From: Acee Lindem >> Sent: Tuesday, March 28, 2023 2:19 PM >> To: Les Ginsberg (ginsberg) >> Cc: Liyan Gong ; Tony Przygienda >> ; chen.mengxiao ; lsr >> ; Weiqiang Cheng ; >>

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

d the updated Router LSA on > the neighbor there is still some risk. > So, Leaving behind the unaddressed concerns on A--B scenario，It seems to me > that SA-bit is better for A--B--C scenario. > > Best Regards, > Liyan > > 邮件原文 > 发件人："Les Ginsberg

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

Hi Louis, In the interest of initiating discussion, I would like to propose the term "Flex Algorithm Traffic Class (FATC)" for the sub-division of flex-algorithm traffic referred to in the draft as “Virtual Flex Algorithm”. Also, in your terminology, you refer referred to TLVs and fields with

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

time, through the VFA mechanism, in other non flex algo >> application scenarios, >> such as network slicing scenarios, the LSP space of IS-IS can also be saved > > ##PP2 > it seems to me you are trying to fix the implementation problem with the > protocol changes, which

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

+ John for approval. > On Apr 13, 2023, at 7:49 AM, Ketan Talaulikar wrote: > > +1 - please accept this Errata as editorial > > Thanks, > Ketan > > > On Tue, Mar 28, 2023 at 8:28 PM Acee Lindem wrote: > That explains it and it is actually the right thing to

Re: [Lsr] [yang-doctors] Yangdoctors early review of draft-ietf-ospf-sr-yang-20

Hi Reshad, Thanks for the review. You raised some very good points and especially the point about the OSPFv3 MPLS encoding being missing. We may delay the document until these are added. However, we will address your comments in the next revision of the document. > On Apr 3, 2023, at 23:18,

Re: [Lsr] [Last-Call] Last Call: (Update to OSPF Terminology) to Proposed Standard

I agree and believe the suggested text is fine. Acee > On Apr 21, 2023, at 6:59 AM, Alvaro Retana > wrote: > > Hi Adrian! > > Yes, I think that makes sense. > > Thanks! > > Alvaro. > > On April 19, 2023 at 5:47:49 PM, Adrian Farrel (adr...@olddog.co.uk) wrote: >> >> >> Hi, >> >> Just

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

> On Apr 20, 2023, at 11:36 PM, Barry Leiba via Datatracker > wrote: > > Reviewer: Barry Leiba > Review result: Has Nits > > I understand why it’s easier to do a single document with a batch update, but > I > question whether anyone will pay attention to it. Still, until the relevant > docu

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

Thanks for the review Jiankang!!! > On Apr 23, 2023, at 09:00, Jiankang Yao via Datatracker > wrote: > > Reviewer: Jiankang Yao > Review result: Ready > > Reviewer: Jiankang Yao > Review result: Ready > > This is an art-art Last Call review of draft-ietf-lsr-rfc8920bis-01. > This document is

Re: [Lsr] Genart last call review of draft-ietf-lsr-ospf-terminology-05

Hi Gyan, Thanks for the review. Acee > On Apr 27, 2023, at 6:00 PM, Gyan Mishra via Datatracker > wrote: > > Reviewer: Gyan Mishra > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processe

Re: [Lsr] AD review of draft-ietf-lsr-ip-flexalgo-08

Hi John, All your comments regarding duplication of TLVs got me thinking. We have covered this in recent RFCs in a more generalized manner. For example, see https://datatracker.ietf.org/doc/rfc7684/ and search for “same”. However, handling this general case of duplicate information isn’t comp

Re: [Lsr] AD review of draft-ietf-lsr-ip-flexalgo-09

Hi Ketan, Peter, > On May 3, 2023, at 9:30 AM, Ketan Talaulikar wrote: > > Hi Peter, > > Please check inline below. > > On Wed, May 3, 2023 at 6:16 PM Peter Psenak wrote: > Hi Ketan, > > On 03/05/2023 06:09, Ketan Talaulikar wrote: > > Hello Authors/All, > > > > I think there are a couple

Re: [Lsr] AD review of draft-ietf-lsr-ip-flexalgo-09

Hi Peter, I believe you need the additions you added for OSPFv2 for OSPFv3 as well. For OSPFv3, they are only applicable to the External-Prefix TLV. Thanks, Acee > On May 4, 2023, at 8:09 AM, Peter Psenak > wrote: > > Hi Ketan, > > please find the updated version and the diffs from previo

Re: [Lsr] AD review of draft-ietf-lsr-ip-flexalgo-09

authors 😎 Thanks, Acee > > Thanks, > Ketan > > > On Thu, May 4, 2023 at 11:55 PM Acee Lindem <mailto:acee.i...@gmail.com>> wrote: >> Hi Peter, >> >> I believe you need the additions you added for OSPFv2 for OSPFv3 as well. >> For OSPFv3, they

Re: [Lsr] Erik Kline's No Objection on draft-ietf-lsr-ospf-terminology-06: (with COMMENT)

Thanks Erik -you Nits will be included in the -07 version. > On May 8, 2023, at 1:09 PM, Erik Kline via Datatracker > wrote: > > Erik Kline has entered the following ballot position for > draft-ietf-lsr-ospf-terminology-06: No Objection > > When responding, please keep the subject line intact

[Lsr] Opsdir last call review of draft-ietf-lsr-ip-flexalgo-11 (Reformatted for Readability)

Hi Bill, Thanks for the Ops review. I reformatted your Email for readability and continued discussion. Thanks, Acee Reviewer: Qin Wu Review result: Has Issues I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the

Re: [Lsr] [Editorial Errata Reported] RFC7770 (7524)

The Errata should be accepted but with modification of text to “Bit additions” rather than “TLV additions”. Corrected Text -- o The values are defined in Section 2.5. All Router Informational Capability Bit additions are to be assigned through IETF Review [IANA-GUIDE].

Re: [Lsr] Paul Wouters' No Objection on draft-ietf-lsr-ospf-terminology-08: (with COMMENT)

Hi Paul, > On May 24, 2023, at 11:02 PM, Paul Wouters via Datatracker > wrote: > > Paul Wouters has entered the following ballot position for > draft-ietf-lsr-ospf-terminology-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included

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

> On May 25, 2023, at 10:34 AM, Les Ginsberg (ginsberg) > wrote: > > 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: We

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

Hi Lars, > On May 25, 2023, at 2:57 AM, Lars Eggert via Datatracker > wrote: > > Lars Eggert has entered the following ballot position for > draft-ietf-lsr-ospf-terminology-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in

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

> On May 25, 2023, at 11:53, John Scudder wrote: > >> On May 25, 2023, at 10:39 AM, Acee Lindem wrote: >> >> Please note that RFCs should use US English as opposed British English. See >> section 3.1 of RFC 7322. > > Correct citation, slightly inacc

Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-admin-tags-08.txt

from the on-line Internet-Drafts > directories. This Internet-Draft is a work item of the Link State Routing > (LSR) WG of the IETF. > > Title : Extensions to OSPF for Advertising Prefix Administrative > Tags > Authors : Acee Lindem >

Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-admin-tags-08.txt

Hi Tom, > On May 31, 2023, at 06:45, tom petch wrote: > > From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of > Acee Lindem mailto:acee.i...@gmail.com>> > Sent: 28 May 2023 20:35 > > Simply refreshed before expiration and updated a reference. We really nee

Re: [Lsr] Intdir telechat review of draft-ietf-lsr-ip-flexalgo-12

> On Jun 1, 2023, at 06:54, Peter Psenak wrote: > > Hi Antoine, > > thanks for the review, please see my response inline: > > > On 01/06/2023 11:22, Antoine Fressancourt via Datatracker wrote: >> Reviewer: Antoine Fressancourt >> Review result: Ready >> I have reviewed this document as part

Re: [Lsr] [Last-Call] Intdir telechat review of draft-ietf-lsr-ip-flexalgo-12

“administer” network devices (e.g., NETCONF and RESTCONF). However, this seems to be an orthogonal issue. And yes, if you use bad AI to drive this administration, there is an existential threat to the stability of your network. Acee > > On Thursday, June 1, 2023 at 06:19:

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

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

Re: [Lsr] Paul Wouters' Discuss on draft-ietf-lsr-ospfv3-srv6-extensions-12: (with DISCUSS)

Hi Paul, > On Jun 6, 2023, at 21:43, Paul Wouters via Datatracker > wrote: > > Paul Wouters has entered the following ballot position for > draft-ietf-lsr-ospfv3-srv6-extensions-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in

Re: [Lsr] Extended LSA: was I-D Action: draft-ietf-lsr-ospf-admin-tags-08.txt

t is to the extended LSAs YANG > model, the one you really want to publish and not to the admin tags (which > you will doubtless want to publish in due course). > > Tom Petch. > _____ > From: Acee Lindem > Sent: 31 May 2023 19:44 > Subject

[Lsr] NomCom 2023 Call for Volunteers

LSR WG - Please consider volunteering for NomCom. See info below: NomCom Chair 2023 Mon, 05 June 2023 23:50 UTCShow header The IETF Nominating Committee (NomCom) appoints people to fill the open slots on the I

[Lsr] Publication of draft-ietf-lsr-dynamic-flooding-13

nst 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

Re: [Lsr] Yangdoctors last call review of draft-ietf-lsr-ospfv3-extended-lsa-yang-14

Hi Mahesh, Thanks for the review - a lot of good comments. See inline and -16 version. > On Jun 15, 2023, at 5:18 PM, Mahesh Jethanandani via Datatracker > wrote: > > Reviewer: Mahesh Jethanandani > Review result: On the Right Track > > Document reviewed: draft-ietf-lsr-ospfv3-extended-lsa

Re: [Lsr] Yangdoctors last call review of draft-ietf-lsr-ospfv3-extended-lsa-yang-14

ressing my comments. >> >>> On Jun 27, 2023, at 1:23 PM, Yingzhen Qu >> <mailto:yingzhen.i...@gmail.com>> wrote: >>> >>> Hi Mahesh, >>> >>> We just uploaded version -17 and added a configuration example. Please let >>>

Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-20.txt

infra-structure are you using? > > You can find the project link here: https://github.com/rwestphal/holo Quite impressive!!! Thanks, Acee > > Thanks and regards, > Renato. > > > Em qui., 29 de jun. de 2023 às 07:06, escreveu: >> >>

Re: [Lsr] Intdir telechat review of draft-ietf-lsr-ospf-terminology-09

Thanks Dirk - these nits will be in the -10 version. Acee > On Jul 14, 2023, at 7:04 AM, Dirk Von Hugo via Datatracker > wrote: > > Reviewer: Dirk Von Hugo > Review result: Ready with Nits > > the document updates LSR/OSPF documents to inclusive language replacing > Master/Slave by Leader/Fo

Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-20.txt

Hi Renato, > On Jul 14, 2023, at 10:58, Renato Westphal wrote: > > Hi Acee, > > Thanks for accepting my suggestions. > > Em qui., 13 de jul. de 2023 às 18:23, Acee Lindem > escreveu: >>> Lastly, this might just be a small nitpick of mine, but I don't th

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

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 mai

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

Authors, A cornucopia of IPR declarations have already been disclosed: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-isis-fast-flooding Are you aware of any additional IPR that applies to draft-ietf-lsr-isis-fast-flooding-04. If so, has this IPR been disclosed in complia

Re: [Lsr] RtgDir Last Call review: draft-ietf-lsr-ospfv3-extended-lsa-yang-20

HI Victoria, Your comments will be incorporated into the -21 version when the draft submission opens back up. > On Jul 19, 2023, at 11:39 AM, Victoria Pritchard > wrote: > > Hello, > > Firstly, sorry for the delay - I missed the notification I'd been assigned to > this review. > > I have

Re: [Lsr] Opsdir telechat review of draft-ietf-lsr-pce-discovery-security-support-13

Hi Will, I’m not sure what happened with the scheduling of this review, but this document is already an RFC (since January). https://datatracker.ietf.org/doc/rfc9353/ RFC 9353: IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discover

Re: [Lsr] Opsdir telechat review of draft-ietf-lsr-pce-discovery-security-support-13

gt; Regards, | 致礼! > Will LIU | 刘树成 > > From: Acee Lindem mailto:acee.i...@gmail.com>> > Sent: Tuesday, July 25, 2023 9:47 PM > To: Liushucheng (Will LIU, Strategy & Industry Development) > mailto:liushuch...@huawei.com>> > Cc: ops-...@ietf.org <mailto:

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

Support as WG member. Thanks, Acee > On Jul 19, 2023, at 7: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 cal

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

I haven’t received IPR poll responses from Chris or Gunter. Thanks, Acee > On Jul 19, 2023, at 7:19 PM, Acee Lindem wrote: > > Authors, > > A cornucopia of IPR declarations have already been disclosed: > https://datatracker.ietf.org/ipr/search/?submit=draft&id=dr

Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-20.txt

Hi Renato, Chris, > On Aug 11, 2023, at 21:41, Renato Westphal wrote: > > Em dom., 16 de jul. de 2023 às 22:37, Christian Hopps > mailto:cho...@chopps.org>> escreveu: >>> On Jul 13, 2023, at 17:23, Acee Lindem wrote: >>> >>> Hi Renato, >>>

Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-20.txt

Hi Renato, > On Aug 11, 2023, at 9:41 PM, Renato Westphal wrote: > > Em dom., 16 de jul. de 2023 às 22:37, Christian Hopps > escreveu: >>> On Jul 13, 2023, at 17:23, Acee Lindem wrote: >>> >>> Hi Renato, >>>> >>>> Lastly

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

The Working Group Last Call has completed and we have enough support to advance the document. Thanks, Acee > On Jul 19, 2023, at 7: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 obj

Re: [Lsr] WG Last Call for draft-ietf-lsr-ospfv3-extended-lsa-yang

As a coauthor, I’m not aware of any IPR. Thanks, Acee > On Aug 18, 2023, at 20:26, Christian Hopps wrote: > > > This begins a 2 week WG Last Call, ending Sep 1, 2023, for: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ > > Authors, > > Please indicate to the

Re: [Lsr] WG Last Call for draft-ietf-lsr-ospfv3-extended-lsa-yang

As a coauthor, I believe this draft is ready and support publication. I’d also like to encourage the authors of WG OSPF YANG model drafts dependent on this augmentation to review and support publication (copied). Thanks, Acee > On Aug 18, 2023, at 20:26, Christian Hopps wrote: > > > This beg

Re: [Lsr] WG Last Call for draft-ietf-lsr-ospfv3-extended-lsa-yang

Hi Tom, Thanks for the review. > On Aug 21, 2023, at 06:57, tom petch wrote: > > From: Lsr on behalf of Christian Hopps > > Sent: 19 August 2023 01:26 > > This begins a 2 week WG Last Call, ending Sep 1, 2023, for: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-

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

Co-Authors, Are you aware of any IPR that applies to draft-posenak-lsr-igp-unreach-prefix-announce-04? 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.iet

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

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] IPR Poll for Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

Co-Authors, Are you aware of any IPR that applies to draft-posenak-lsr-igp-ureach-prefix-announce-04? 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

[Lsr] IPR Poll for Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name and IPR link)

Co-Authors, Are you aware of any IPR that applies to draft-posenak-lsr-igp-ureach-prefix-announce-04? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There is one IPR statement - https://datatracker.ietf.org/ipr/sea

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

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 ___

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

; > -邮件原件- > 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem > 发送时间: 2023年8月24日 4:07 > 收件人: lsr > 抄送: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org > 主题: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - &

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

st recent version of the draft. Thanks, Acee > > /hannes > > On Wed, Aug 23, 2023 at 02:09:46PM -0700, Tony Li wrote: > | > | I object. This solution is a poor way of addressing the issues. My reasons > have been discussed to death already. > | > | T

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

there is an unreachable prefix, the entire monolithic LSP must be re-advertised. Additionally, operators do not want to separate out the PE addresses into a separate address range as they haven’t done the in the past. Thanks, Acee > On Aug 23, 2023, at 15:58, Acee Lindem wrote: >

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

lution under adoption has running code and wide vendor support. Thanks, Acee > > > On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg) > wrote: > Zhibo - > Please see inline. > > -Original Message- > > From: Huzhibo > > Sent: Wednesday, A

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

> On Aug 31, 2023, at 12:32, Robert Raszuk wrote: > > Hi Acee, > >> In any case, one will need to update the signaling routers and the routers >> acting on the signal. > > I guess this is clear to all. > >> Additionally, your request for the adoption was that the draft have a >> stronger

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

Hi Les, > On Aug 31, 2023, at 4:39 PM, Les Ginsberg (ginsberg) > wrote: > > 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 Ca

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

: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> > [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem > 发送时间: 2023年9月1日 0:50 > 收件人: Robert Raszuk mailto:rob...@raszuk.net>> > 抄送: Les Ginsberg (ginsberg) <mailto:ginsberg=40cisco@dmarc.ietf.org>>; Huzhibo >

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

Hi Jayesh, As a document contributor, you also need to respond to the IPR poll. Thanks, Acee > Begin forwarded message: > > From: Acee Lindem > Subject: WG Last Call IPR Poll for "IS-IS Fast Flooding" - > draft-ietf-lsr-isis-fast-flooding-04 > Date: July 19,

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

n-7, > March 26, 2021, one year before the 00 version of draft-ppsenak(March > 25,2022) > > Then, which draft copy or incorporate which draft? > > Aijun Wang > China Telecom > >> On Sep 1, 2023, at 20:05, Acee Lindem wrote: >> >> Hi Aijun, &

  1   2   3   4   5   6   7   8   9   10   >