Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

This also explains the mystery of why some Bruno, Robert, and possibly others were having problems joining. Thanks, Acee On 4/3/20, 6:26 AM, "Christian Hopps" wrote: Hi Bruno, This is very useful feedback. It looks like that link the secretary posted simply tries to join a

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Speak as WG Member... On 4/1/20, 8:08 AM, "Acee Lindem (acee)" wrote: There is also a difference between some of the existing applications advertised in IGP capabilities. For example, MSD is used with the routing information to construct SR paths. The information for all

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

There is also a difference between some of the existing applications advertised in IGP capabilities. For example, MSD is used with the routing information to construct SR paths. The information for all these OAM mechanisms doesn't share this affinity. Also, it seems like a slippery slope in

Re: [Lsr] 答复: 答复: New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02

Many thanks for your comments. Taking your suggestion I am writing a new LSR draft to combine the OSPF draft, ISIS draft and BGP-LS draft and will add more context on how to use the IFIT Capability information. Best regards, Yali -邮件原件- 发件人: Acee Lindem (acee)

Re: [Lsr] Agenda Posted Re: Link State Routing (lsr) WG Virtual Meeting: 2020-04-02

While I never concluded the discussion (until now), but there is very little support for the requirement from operators. The flooding reflector draft did have the most support with support from one operator who was not a co-author on the draft. We could move these presentations to the second

Re: [Lsr] LSR Interim Invitations (.ics attached)

Thanks Much Yingzhen! I will text Tony P 15 minutes before the start of each meeting  Given that the only routing WGs that are meeting next week are LSR and IDR, I hope that many of you will have time to read the drafts. Thanks, Acee From: Yingzhen Qu Date: Tuesday, March 24, 2020 at 11:45

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Hi Alvaro, On 3/23/20, 5:17 AM, "Peter Psenak" wrote: Hi Alavaro, On 20/03/2020 19:23, Alvaro Retana wrote: > On March 20, 2020 at 10:34:59 AM, Peter Psenak wrote: > > > Peter: > > > I don't really see why one would affect the other.

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Hi Peter Alvaro, On 3/20/20, 8:58 AM, "Peter Psenak" wrote: On 20/03/2020 11:59, Alvaro Retana wrote: > On March 20, 2020 at 6:22:38 AM, Peter Psenak wrote: > > > ... >>> Besides the in-line comments, I want to point out here that this >>> specification is

Re: [Lsr] Link State Routing (lsr) WG Virtual Meeting: 2020-04-02

This will take the place of the LSRs meetings that were scheduled to take place in Vancouver. We will honor the existing agenda requests. However, we intend to provide the WG document status prior on the list as opposed to taking interim meeting time. Thanks, Acee On 3/19/20, 3:54 PM, "Lsr

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Hi Alvaro - Thanks for the extensive review. Hi Peter - Thanks for the addressing all the comments. See one inline. On 3/16/20, 7:52 AM, "Peter Psenak" wrote: Hi Alvaro, thanks for your comments. Let's first close the ISIS ELC draft before starting to work on OSPF

Re: [Lsr] 答复: New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02

that head node can use. By using BGP-LS, a centralized controller can also learn the IFIT Capability of nodes to determine whether a particular IFIT Option type can be supported in a given network. Best regards, Yali -邮件原件- 发件人: Acee Lindem (acee) [mailto:a...

Re: [Lsr] 答复: Question about OSPF (transit area routing loop)

about OSPF (transit area routing loop) Acee, Because ABR_1 creates SumLSA-4 for the ASBR not from the backbone area. The cost of SumLSA-4 for ASBR is 300. Thanks, Sergey вт, 25 февр. 2020 г. в 22:44, Acee Lindem (acee) mailto:a...@cisco.com>>: Hi Sergey, I don’t see why RT_1 wouldn’t go thro

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

I looked at this again and the long Email thread and agree with Peter, Les, and Joel that we don't need a protocol specific registry for the Endpoint behaviors and associated SIDs. Thanks, Acee On 3/11/20, 1:42 PM, "Lsr on behalf of Joel M. Halpern" wrote: It does seem to me that using

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

Hi Peter, Chris, I agree that a number of IS-IS IANA registries have this level of specification. For example: https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 Thanks, Acee On 3/9/20, 8:28 AM, "Lsr on behalf of Christian

Re: [Lsr] New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02

Hi Yali, A couple of very basic comments on these drafts. They are definitely not ready for consideration. 1. IFIT is never expanded as an acronym. Seems it should be as early as the title. OSPF extensions for Advertising In-Situ Flow Information Telemetry (IFIT) Capability

Re: [Lsr] Question about OSPF (transit area routing loop)

> > Acee, > > Because ABR_1 creates SumLSA-4 for the ASBR not from the backbone area. The cost of SumLSA-4 for ASBR is 300. > > Thanks, > Sergey > > вт, 25 февр. 2020 г. в 22:44, Acee Lindem (acee) : > Hi Sergey, > > I do

Re: [Lsr] Question about OSPF (transit area routing loop)

the calculation begins on the router ABR_3 16.3. It is a bad idea? :) Thansk, Sergey пн, 2 мар. 2020 г. в 00:51, Acee Lindem (acee) mailto:a...@cisco.com>>: Hi Sergey, Seems it is a real problem that needs a solution. Let’s continue the discussion. Thanks, Acee From: Sergey SHpenkov

Re: [Lsr] IETF 107 LSR Presentation Slot Requests

Caught me just in time asking about this  Acee From: Linda Dunbar Date: Monday, March 2, 2020 at 1:57 PM To: Yingzhen Qu Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" Subject: RE: [Lsr] IETF 107 LSR Presentation Slot Requests Resent-From: Resent-To: Christian Hopps , Acee Lindem , Yingzhen Qu

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Authors Dearest, Please update all the out-of-date references and the copyright date to 2020. This will resolve the Nits. https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-isis-mpls-elc-10.txt Thanks, Acee (speaking as document shepherd) On 2/29/20, 12:00

Re: [Lsr] 答复: IETF 107 LSR Presentation Slot Requests

Yali – Can you give an overview on the list as well? Thanks, Acee From: wangyali Date: Friday, February 28, 2020 at 10:03 PM To: "lsr-cha...@ietf.org" , "lsr@ietf.org" Cc: Yingzhen Qu Subject: 答复: [Lsr] IETF 107 LSR Presentation Slot Requests Resent-From: Resent-To: Acee Lindem , Yingzhen Qu

Re: [Lsr] Question about OSPF (transit area routing loop)

г. в 22:44, Acee Lindem (acee) mailto:a...@cisco.com>>: Hi Sergey, I don’t see why RT_1 wouldn’t go through ABR_1 to get to the ASBR. Thanks, Acee From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Sergey SHpenkov mailto:sergey.v.shpen...@gmail.com>> Date: Tuesday, Februar

Re: [Lsr] Question about OSPF (transit area routing loop)

Hi Sergey, I don’t see why RT_1 wouldn’t go through ABR_1 to get to the ASBR. Thanks, Acee From: Lsr on behalf of Sergey SHpenkov Date: Tuesday, February 25, 2020 at 2:38 PM To: "lsr@ietf.org" Subject: [Lsr] Question about OSPF (transit area routing loop) Hi, In section 16.3 of the OSPF RFC

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

e refer to "specific algorithm topologies" in the flex algorithm draft? I haven't read it for a while... Thanks, Acee Thanks, Ketan -Original Message----- From: Acee Lindem (acee) Sent: 30 January 2020 23:02 To: Peter Psenak (ppsenak) ; Ketan Ta

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Peter, On 1/30/20, 12:25 PM, "Peter Psenak" wrote: Hi Acee, On 30/01/2020 18:12, Acee Lindem (acee) wrote: > Hi Peter, > > On 1/30/20, 11:36 AM, "Peter Psenak" wrote: > > Hi Acee, > > On 3

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Peter, On 1/30/20, 11:36 AM, "Peter Psenak" wrote: Hi Acee, On 30/01/2020 17:11, Acee Lindem (acee) wrote: > Hi Ketan, > > In that case, it doesn’t make sense to include it in the End.X > advertisement since you need to look it up to ch

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

All End.X SIDs MUST be subsumed by the subnet of a Locator with the matching algorithm which is advertised by the same node in an SRv6 Locator TLV. End.X SIDs which do not meet this requirement MUST be ignored. Thanks, Ketan From: Acee Lindem (acee) Sent: 30 January 2020 21:01 To: li_z

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

gt;; Christian Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org> CC: draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>; lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; Acee Lindem (acee)&

[Lsr] IS-IS Requirements for Area Abstraction (Corrected Alias for ADs)

Speaking as WG Co-chair: At IETF 107, we had a protracted discussion of several drafts having goal of reducing the amount of link-state information that must be flooded into the level-2 area. We have two drafts that do this essentially via abstraction of the level-1 areas. These are:

[Lsr] IS-IS Requirements for Area Abstraction

Speaking as WG Co-chair: At IETF 107, we had a protracted discussion of several drafts having goal of reducing the amount of link-state information that must be flooded into the level-2 area. We have two drafts that do this essentially via abstraction of the level-1 areas. These are:

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Speaking as WG member: I have reviewed the document and my comments have been incorporated. I support WG adoption. Thanks, Acee On 1/23/20, 3:25 PM, "Lsr on behalf of Christian Hopps" wrote: Hi LSR WG and Draft Authors, The authors originally requested adoption back @ 105;

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Speaking as WG member, I have reviewed revisions of this draft and support publication. Thanks, Acee On 1/21/20, 7:15 PM, "Christian Hopps" wrote: This begins a 2 week WG Last Call, ending after Feb 4, 2020, for draft-ietf-lsr-isis-srv6-extensions

Re: [Lsr] Methods to label the passive interfaces within ISIS

sted also before, we can change the description for “passive” to “stub” later. Is that more acceptable then? Yes – but I’d still like to know why this is needed. Thanks, Acee Aijun Wang China Telecom On Jan 14, 2020, at 06:40, Acee Lindem (acee) wrote: Hi Aijun, From: Aijun Wang Date: Mond

Re: [Lsr] Methods to label the passive interfaces within ISIS

ment that identifies an interface type isn’t sufficient to do anything useful IMO. Les From: Acee Lindem (acee) Sent: Monday, January 13, 2020 8:03 AM To: tony...@tony.li; Aijun Wang Cc: Les Ginsberg (ginsberg) ; Robert Raszuk ; lsr@ietf.org Subject: Re: [Lsr] Methods to label the passive interf

Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi Aijun, I guess the external use case for this is advertisement in BGP-LS for Network Management purposes?? There really isn’t IS-IS requirement to know whether or not an interface is a passive interface. Thanks, Acee From: Lsr on behalf of Tony Li Date: Monday, January 13, 2020 at 11:00 AM

Re: [Lsr] [Technical Errata Reported] RFC2328 (5956)

All, I don't agree this change is required. The non-normative appendix C text clearly states that this is the "cost of sending a packet on the interface". The examples cited are cases where reachability to a local address is provided. Now, there are cases where it is useful to specify a

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

Speaking as WG Member: I support publication. This is document fills a long-standing gap in the IS-IS specification. Thanks, Acee On 1/2/20, 2:09 PM, "Lsr on behalf of Christian Hopps" wrote: This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

Speaking as a WG member, I support WG adoption. Thanks, Acee On 12/13/19, 6:55 AM, "Lsr on behalf of Christian Hopps" wrote: Hi LSR WG and Draft Authors, This begins a 2 week WG adoption poll for the following draft:

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-reverse-metric

Speaking as a WG member, I support WG adoption. Thanks, Acee On 12/13/19, 6:29 AM, "Lsr on behalf of Christian Hopps" wrote: Hi LSR WG and Draft Authors, This begins a 2 week WG adoption poll for the following draft:

Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

The WG adoption poll has ended and the draft has been accepted. Chris – please republish as draft-ietf-lsr-yang-isis-reverse-metric-00.txt. Thanks, Acee From: Lsr on behalf of Acee Lindem Date: Monday, November 25, 2019 at 7:27 AM To: "lsr@ietf.org" Cc: Christian Hopps Subject: [Lsr] "YANG

[Lsr] OSPF/IS-IS Segment Routing RFCs - MPLS Dataplane

The OSPF/IS-IS Segment Routing drafts have been published as RFCs. There’s been a lot of iterations and work done here and I’d like to recognize the occasion as well as congratulate the authors. OSPF Segment Rouing - https://www.rfc-editor.org/info/rfc8665 OSPFv3 Segment Routing –

Re: [Lsr] some doubts about RFC3101

. It maybe fall under a configed error, but the result of the calculate result seems wrong. What is your opinion for it? Regards 发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 发送时间: 2019年12月5日 20:40 收件人: meicong ; lsr@ietf.org 主题: Re: [Lsr] some doubts about RFC3101 Hi Meicong, From: Lsr mailt

[Lsr] IETF 106 LSR Working Group Meeting Minutes

I’ve uploaded the IETF 106 LSR minutes at https://datatracker.ietf.org/meeting/106/materials/minutes-106-lsr-00 Please send me any additions or corrections. Thanks much to Yingzhen Qu for compiling the minutes. As you can see, we had quite a lot of lively discussion during the sessions –

Re: [Lsr] some doubts about RFC3101

Hi Meicong, From: Lsr on behalf of meicong Date: Thursday, December 5, 2019 at 4:48 AM To: "lsr@ietf.org" Cc: "draft-ietf-ospf-nssa-upd...@ietf.org" Subject: [Lsr] some doubts about RFC3101 Hi All, Could you please provide clarification for following section 2.5.(3) in rfc3101.

Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

Speaking as a WG member, I support adoption. Thanks, Acee From: Lsr on behalf of Acee Lindem Date: Monday, November 25, 2019 at 7:27 AM To: "lsr@ietf.org" Cc: Christian Hopps Subject: [Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02 This begins a

[Lsr] IPR Poll on "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

Authors, Are you aware of any IPR that applies to draft-hopps-lsr-yang-isis-reverse-metric-02? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to

[Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

This begins a two week LSR Working Group adoption call for the subject document. https://datatracker.ietf.org/doc/draft-hopps-lsr-yang-isis-reverse-metric/ Please indicate your support or objection to adoption to the LSR list (lsr@ietf.org) prior to 12:00 AM UTC on December

Re: [Lsr] draft-hopps-lsr-yang-isis-reverse-metric-02

Hi Tom, I agree with your comments. I'm going to start a WG adoption poll on this document as it is pretty straight-forward. See one inline. On 11/24/19, 2:44 AM, "Lsr on behalf of tom petch" wrote: Christian Some stray thoughts /intermediate system

Re: [Lsr] "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

xtensions-07 Questions/Comments Hi Acee, Thanks for your review and comments. Please check inline below. From: Acee Lindem (acee) Sent: 18 November 2019 06:18 To: draft-li-ospf-ospfv3-srv6-extensi...@ietf.org Cc: lsr@ietf.org Subject: "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv

[Lsr] "OSPFv3 Extensions for SRv6" - draft-li-ospf-ospfv3-srv6-extensions-07 Questions/Comments

Hi Authors, I know you have asked for adoption and I have some comments on the draft. I think these need to be addressed or at least answered prior to any LSR adoption call. In my opinion, this document is not ready. 1. Why do you define a separate SRv6 Locator LSA to advertise SRv6

Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10

Hi Alvaro, On 11/7/19, 11:58 AM, "Alvaro Retana" wrote: On November 3, 2019 at 2:28:29 PM, Padma Pillay-Esnault wrote: Padma: Hi! See below... > On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote: > > On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma

Re: [Lsr] Genart last call review of draft-ietf-ospf-ospfv2-hbit-10

See one inline. From: Acee Lindem Date: Thursday, October 31, 2019 at 2:39 PM To: Padma Pillay-Esnault , Mohit Sethi Cc: "gen-...@ietf.org" , "last-c...@ietf.org" , "draft-ietf-ospf-ospfv2-hbit@ietf.org" , "lsr@ietf.org" Subject: Re: Genart last call review of

Re: [Lsr] Genart last call review of draft-ietf-ospf-ospfv2-hbit-10

HI Padma, Mohit, From: Padma Pillay-Esnault Date: Thursday, October 31, 2019 at 2:17 PM To: Mohit Sethi Cc: "gen-...@ietf.org" , "last-c...@ietf.org" , "draft-ietf-ospf-ospfv2-hbit@ietf.org" , "lsr@ietf.org" , Padma Pillay-Esnault Subject: Re: Genart last call review of

[Lsr] Early Allocation request for "OSPF Prefix Originator Extension" - draft-ietf-lsr-ospf-prefix-originator-04

Hi Amanda, et al, We have some implementation momentum and wish to request early IANA allocation for OSPFv2 and OSPFv3 code points in the subject draft. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

[Lsr] "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" IPR

All, I you were paying attention, you noticed that publication was requested for both the OSPF and IS-IS Entropy Label signaling drafts. During the review, we found the IPR statement was missing from the OSPF draft in the data tracker. This was an oversite on my part as the “Replaces”

Re: [Lsr] IPR Call for New Co-authors of draft-ietf-ospf-mpls-elc-11.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (And this one)

BE/Antwerp)" Date: Monday, October 21, 2019 at 9:04 AM To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "Acee Lindem (acee)" Cc: "lsr@ietf.org" , Alvaro Retana , "Bocci, Matthew (Nokia - GB)" , Keyur Patel Subject: Re: IPR Call for New Co-a

Re: [Lsr] IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (Corrected)

Antwerp)" Date: Monday, October 21, 2019 at 9:03 AM To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "Acee Lindem (acee)" , "Bocci, Matthew (Nokia - GB)" , Keyur Patel Cc: "lsr@ietf.org" , Alvaro Retana Subject: Re: IPR Call for New Co-authors of dr

[Lsr] IPR Call for New Co-authors of draft-ietf-ospf-mpls-elc-11.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (And this one)

New Author and Contributors, Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-11? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to

[Lsr] IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using IS-IS" (Reply to this one)

New Author and Contributors, Are you aware of any IPR that applies to draft-ietf-isis-mpls-elc-10? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to

[Lsr] IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (Corrected)

New Author and Contributors, Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-11? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to

[Lsr] IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF"

New Author and Contributors, Are you aware of any IPR that applies to draft-ietf-isis-mpls-elc-07? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to

Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-yang-isis-cfg-41: (with COMMENT)

Hi Ben, Thanks again for the detailed review. I've made the editorial changes below in the -42 version. Thanks, Acee On 10/15/19, 1:38 AM, "Benjamin Kaduk via Datatracker" wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-isis-yang-isis-cfg-41: No

Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)

o range u16 or a 1..max range? > Thanks, > Chris. > >> On Oct 7, 2019, at 12:44 PM, Acee Lindem (acee) wrote: >> >>> grouping spf-parameters { >>>container spf-control { >>>leaf paths { >>>

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)

Hi Ben, Thanks for the excellent review - see one inline. On 10/8/19, 6:13 AM, "Benjamin Kaduk" wrote: Hi Stephane, Thanks for pulling in the fixes; just a few notes inline (and trimming)... On Tue, Oct 08, 2019 at 10:33:49AM +0200, slitkows.i...@gmail.com wrote: >

Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)

Hi Adam, Thanks for review. On 10/2/19, 6:31 PM, "Adam Roach via Datatracker" wrote: Adam Roach has entered the following ballot position for draft-ietf-isis-yang-isis-cfg-40: No Objection When responding, please keep the subject line intact and reply to all email

Re: [Lsr] WG Adoption poll for draft-acee-lsr-ospf-yang-augmentation-v1-01

Speaking as a co-author, I support this draft. When we froze the features in the base OSPF YANG model so it could be published, we committed to supporting new RFCs and drafts in separate model in a new draft. I don't know of any IPR. Thanks, Acee On 10/2/19, 5:29 PM, "Lsr on behalf of

Re: [Lsr] WG Adoption Poll for draft-acee-lsr-ospfv3-extended-lsa-yang-06

Speaking as co-author, I support this draft. It is required for all OSPFv3 extensions utilizing RFC8362 extended LSA encodings. Additionally, I'm not aware of any IPR. Thanks, Acee On 10/2/19, 5:27 PM, "Lsr on behalf of Christian Hopps" wrote: Hi Folks, This begins a 2 week WG

Re: [Lsr] Barry Leiba's No Objection on draft-ietf-isis-yang-isis-cfg-37: (with COMMENT)

Hi Alvaro, Co-authors, et al, I went ahead and changed to “should” for the YANG deviations as well as fixing a couple typos and changing the draft short name from “isis-cfg” to “isis-yang”. The -40 version is posted. Thanks, Acee From: Acee Lindem Date: Friday, September 27, 2019 at 8:30 AM

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Authors, The LSR Working Group Adoption Call has ended and there is sufficient support and interest in working on this draft here in LSR. Please republish the draft as draft-ietf-lsr-isis-extended-hierarchy-00.txt as we agreed during the discussion initiated by Robert Raszuk during the adoption

Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

The Working Group last call has completed and we have received IPR responses from all the authors. We have some comments from the Routing Directorate review on the corresponding IS-IS draft. I will hold off requesting publication in case the comments are also applicable to this version. Thanks,

Re: [Lsr] [mpls] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

The Working Group last call has completed and we have received IPR responses from all the authors. We have some comments from the Routing Directorate review. I will request publication of the version addressing these comments. Thanks, Acee From: mpls on behalf of Acee Lindem Date: Friday,

Re: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

Cc: "lsr@ietf.org" , "draft-ietf-isis-mpls-...@ietf.org" Subject: RE: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07 Acee, I am not aware of any IPR that applies to this draft

Re: [Lsr] Barry Leiba's No Objection on draft-ietf-isis-yang-isis-cfg-37: (with COMMENT)

Hi Barry, Thanks for your review - I've published the -38 version incorporating all your comments and Stewart Bryant's comments in order to avoid duplicates from other reviewers. I did take a pass over the document and added some additional articles. Thanks, Acee On 9/26/19, 1:37 AM, "Barry

Re: [Lsr] "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

Clarence – I still need a response to the IPR poll. Thanks, Acee From: Lsr on behalf of Acee Lindem Date: Friday, August 30, 2019 at 3:07 PM To: "draft-ietf-ospf-mpls-...@ietf.org" Cc: "lsr@ietf.org" Subject: [Lsr] "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth

Re: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

Clarence and Xiaohu (Tiger) – I still need responses to the IPR poll… Tiger – you replied to the poll for the OSPF ELC draft but not the IS-IS ELC draft. Thanks, Acee From: Lsr on behalf of Acee Lindem Date: Friday, August 30, 2019 at 3:11 PM To: "draft-ietf-isis-mpls-...@ietf.org" Cc:

Re: [Lsr] Rtgdir early review of draft-ietf-isis-mpls-elc-08

Dhruv - thanks much for the review. Authors - can you address Dhruv's comments? Thanks, Acee On 9/12/19, 6:06 AM, "Dhruv Dhody via Datatracker" wrote: Reviewer: Dhruv Dhody Review result: Has Issues Subject: RtgDir Early review: draft-ietf-isis-mpls-elc-08 Hello

Re: [Lsr] Genart last call review of draft-ietf-isis-yang-isis-cfg-37

Thanks Stewart - we will fix this nit in the -38 version. Acee On 9/18/19, 10:14 AM, "Stewart Bryant via Datatracker" wrote: Reviewer: Stewart Bryant Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews

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

Amanda et al, The IGP Flex Algorithm early allocations were made prior to the addition of Prefix Metric as defined in sections 16.3.2. 16.4.2. and 16.4.3 repectively for IS-IS, OSPFv2, and OSPFv3. Can these code points for prefix metric be added to the early allocations? Thanks, Acee On

Re: [Lsr] Rtgdir early review of draft-ietf-isis-mpls-elc-08

Thanks Dhruv for the review... Peter and other authors, Please include Dhruv's comments or respond as to why they are being omitted. Thanks, Acee On 9/12/19, 6:06 AM, "Dhruv Dhody via Datatracker" wrote: Reviewer: Dhruv Dhody Review result: Has Issues Subject: RtgDir

Re: [Lsr] Rtgdir early review of draft-ietf-ospf-mpls-elc-09

Thanks Dhruv for the review... Peter and other authors, Please include Dhruv's comments or respond as to why they are being omitted. Thanks, Acee On 9/12/19, 6:12 AM, "Dhruv Dhody via Datatracker" wrote: Reviewer: Dhruv Dhody Review result: Has Issues Subject: RtgDir

Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

and advertised per every local host prefix (link) . Is there any specific reason why link MSD is not considered instead ? ( https://tools.ietf.org/html/rfc8491) Because the intra-area link topology is not exposed across areas or to other protocols. Thanks, Acee -- Uma C. From: mpls On Behalf Of A

Re: [Lsr] AD Review of draft-ietf-isis-yang-isis-cfg-35

to:aretana.i...@gmail.com>) wrote: On September 5, 2019 at 3:09:44 PM, Acee Lindem (acee) (a...@cisco.com<mailto:a...@cisco.com>) wrote: Hi! Stephane and I have some more updates in -36 version. I’m ready to start the IETF LC, but there’s one small thing I need you to fix before: rfc29

Re: [Lsr] AD Review of draft-ietf-isis-yang-isis-cfg-35

Hi Alvaro, I see you approved for IESG review. Stephane and I have some more updates in -36 version. See inline. From: Alvaro Retana Date: Tuesday, July 30, 2019 at 3:29 PM To: "draft-ietf-isis-yang-isis-...@ietf.org" , Stephane Litkowski Cc: Yingzhen Qu , "lsr@ietf.org" ,

Re: [Lsr] [mpls] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

Speaking a WG member: I support publication. I have the same comments as the OSPF ELC draft. 1. There are a couple instances of “Signalling” here too. 2. Why does this referred to stacked LSPs? I think it could be applicable to a single LSP. 3. In the “Security Considerations”, please

Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

Speaking as a WG member (and someone who has followed this discussion for some time): I support publication of this document. I have a couple minor comments: 1. Please use the US English form of “Signaling” consistently. Right now there is a mix of “Signalling” and “Signaling”. 2. Why

[Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

We’ve gone through a number of iterations with these ELC drafts and I believe they are ready and meets all the use case requirements. Note that “Entropy Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the RFC editor’s queue. This begins a two week last call for the

[Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

We’ve gone through a number of iterations with these ELC drafts and I believe they are ready and meets all the use case requirements. Note that “Entropy Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the RFC editor’s queue. This begins a two week last call for the

[Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

Authors, Are you aware of any IPR that applies to draft-ietf-isis-mpls-elc-07? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email

[Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08 (Updated Subject)

From: Acee Lindem Date: Friday, August 30, 2019 at 3:06 PM To: "draft-ietf-ospf-mpls-...@ietf.org" Cc: "lsr@ietf.org" Subject: "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08 Authors, Are you aware of any IPR that applies

[Lsr] "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

Authors, Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-08? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email

Re: [Lsr] draft-ietf-isis-mpls-elc-07

-elc-07 Point taken… Les From: Acee Lindem (acee) Sent: Wednesday, August 28, 2019 1:56 PM To: Les Ginsberg (ginsberg) ; Uma Chunduri ; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-isis-mpls-elc-07 Les, Then what you meant in your response was, “generic RLD” as opposed to “generic MSD”. T

Re: [Lsr] draft-ietf-isis-mpls-elc-07

t might be required on a label stack, please make it. Then Uma’s suggestion might make sense. Les From: Acee Lindem (acee) Sent: Wednesday, August 28, 2019 1:34 PM To: Les Ginsberg (ginsberg) ; Uma Chunduri ; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-isis-mpls-elc-07 Hi Les, I think the

Re: [Lsr] draft-ietf-isis-mpls-elc-07

Hi Les, I think the question is whether there can be a single RLD depth MSD rather than a RLD solely for entropy label discovery. Thanks, Acee From: Lsr on behalf of "Les Ginsberg (ginsberg)" Date: Wednesday, August 28, 2019 at 4:29 PM To: Uma Chunduri , "lsr@ietf.org" Subject: Re: [Lsr]

Re: [Lsr] draft-ietf-isis-mpls-elc-07

I know we decided we needed different types of MSD but you’re questioning whether we really need different types of RLD. Forwarding implementors? Thanks, Acee From: Lsr on behalf of Uma Chunduri Date: Wednesday, August 28, 2019 at 2:38 PM To: "lsr@ietf.org" Subject: [Lsr]

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-ospf-xaf-te-06: (with DISCUSS)

Hi Roman, Can we clear the DISCUSS on Alvaro’s update? Thanks, Acee From: Alvaro Retana Date: Friday, August 16, 2019 at 10:32 AM To: Roman Danyliw Cc: Acee Lindem , "draft-ietf-ospf-xaf...@ietf.org" , "lsr-cha...@ietf.org" , "lsr@ietf.org" , The IESG Subject: Re: [Lsr] Roman Danyliw's

[Lsr] FW: [IANA #1150448] IANA Request for Early Allocation for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

FYI On 8/27/19, 1:59 AM, "Amanda Baber via RT" wrote: Hi all, We've completed the early allocations for draft-ietf-ospf-mpls-elc. However, per Acee, the descriptions have been updated, and per Alvaro, we've assigned the next available value in the OSPFv3 Prefix Options (8 bits)

Re: [Lsr] Roman Danyliw’s DISCUSS on draft-ietf-ospf-yang-26

Subject: RE: Roman Danyliw’s DISCUSS on draft-ietf-ospf-yang-26 Hi Acee! -28 addresses my discuss items and my ballot now reflects that. Thanks much for this iteration and updated text. Regards, Roman From: Acee Lindem (acee) [mailto:a...@cisco.com] Sent: Monday, August 26, 2019 11:43 AM To:

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-yang-26: (with DISCUSS and COMMENT)

Hi Ben, On 8/26/19, 11:11 AM, "Lsr on behalf of Benjamin Kaduk" wrote: Hi Acee, On Mon, Aug 26, 2019 at 03:02:18PM +0000, Acee Lindem (acee) wrote: > Hi Ben, > > On 8/22/19, 9:44 PM, "Benjamin Kaduk" wrote: > > On Fr

Re: [Lsr] Roman Danyliw’s DISCUSS on draft-ietf-ospf-yang-26

tf.org" , "lsr@ietf.org" , The IESG Subject: RE: Roman Danyliw’s DISCUSS on draft-ietf-ospf-yang-26 Hi Acee! Thanks for the explanation. More inline … From: Acee Lindem (acee) [mailto:a...@cisco.com] Sent: Wednesday, August 21, 2019 1:51 PM To: Alvaro Retana ; draft-ietf-ospf-y

[Lsr] IANA Early Allocation Request for "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

We have a request for IANA allocation for this draft from a vendor implementing the draft. Please provide early allocation for the code points. https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ Thanks, Acee ___ Lsr mailing list

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-yang-26: (with DISCUSS and COMMENT)

Hi Ben, On 8/22/19, 1:46 AM, "Benjamin Kaduk via Datatracker" wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-ospf-yang-26: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and

<    1   2   3   4   5   6   7   8   9   >