Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

ces that don’t need to be advertised as stub, they can easily be excluded from being added into IGP. Kind Regards Gyan On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) mailto:40cisco@dmarc.ietf.org>> wrote: Hi Aijun, From: Aijun Wang mailto:wangai...@tsinghua.org.cn>> Date:

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Or possibly the prospect of Flex Algo flavors made you hungry ;^0. Acee On 10/11/20, 1:39 PM, "Lsr on behalf of Jeff Tantsura" wrote: Thanks Ron, indeed! Autocorrect works in mysterious ways ;-) Regards, Jeff > On Oct 11, 2020, at 09:41, Ron Bonica wrote: > >

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Saturday, October 10, 2020 3:48 AM To: Aijun Wang ; Peter Psenak (ppsenak) ; 'Aijun Wang' Cc: lsr@ietf.org Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt S

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

t Hi, Acee: Sorry for the previous pruned mail. Let's reply you again along your original question. Please see inline.[WAJ] -Original Message- From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Wednesday, September 30, 2020 7:47 PM To

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

Hi Ketan, From: "Ketan Talaulikar (ketant)" Date: Monday, October 5, 2020 at 1:29 AM To: Gyan Mishra , "Les Ginsberg (ginsberg)" Cc: "lsr@ietf.org" , "draft-ketant-lsr-ospf-l2bundles@ietf.org" , Christian Hopps , "lsr-cha...@ietf.org" Subject: RE: [Lsr] WG adoption call for

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

Speaking as WG member: I support WG adoption of this document. It is needed for IS-IS parity and there are already other non-WG documents referencing it. Thanks, Acee On 10/2/20, 8:05 AM, "Christian Hopps" wrote: This begins a 2 week WG adoption call for the following draft:

[Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt

Authors, The following IPR has been disclosed (excerpted from https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo): Date ID Statement 2018-08-08 3248 Cisco's Statement about IPR related to draft-ietf-lsr-flex-algo 2019-12-05

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Speaking as WG member... I agree that an independent calculation is required for IP Flex Algorithm and SR Flex Algorithm and this should be documented. However, it doesn't seem to me a normal use case would be to deploy them in the same IGP area. Thanks, Acee On 10/1/20, 4:07 AM, "Lsr on

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

The WG last call has ended. All comments have been addressed or concluded. There was considerable discussion regarding the requirement that alternate link metrics come from Application-Specific Link Attributes (ASLAs) and whether to allow them from TE advertisements as well. The consensus was

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

the nodes or controller know the boundaries of the network. Aijun Wang China Telecom > On Sep 30, 2020, at 19:47, Acee Lindem (acee) wrote: > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

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

This version addresses Tom Petch's comments. Thanks, Acee On 9/30/20, 11:08 AM, "Lsr on behalf of internet-dra...@ietf.org" wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF.

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

Hi Tom, See inline . I've addressed your comments in 05. On 9/30/20, 6:14 AM, "tom petch" wrote: From: Acee Lindem (acee) Sent: 29 September 2020 22:44 Hi Tom, We can add the references. See ACEE>. Yes please - it will make it easier for me to rev

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

--Original Message- From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Tuesday, September 29, 2020 9:16 PM To: Peter Psenak ; Aijun Wang ; 'Aijun Wang' Cc: lsr@ietf.org Subject: Re: [Lsr] FW: New Version Notification for draf

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

Hi Tom, We can add the references. See ACEE>. On 8/13/20, 6:03 AM, "Lsr on behalf of tom petch" wrote: From: Lsr on behalf of internet-dra...@ietf.org Sent: 13 August 2020 05:37 I said before that it was tough to review because of a lack of references in the YANG module and

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

Speaking as WG member: Hi Aijun, Peter, I agree with Peter - one of the main motivations for having areas is to abstract the topology within the area. Now you're trying to supplant this - one topological detail at a time with ill-conceived IGP features. Thanks, Acee On 9/29/20, 5:15 AM,

Re: [Lsr] RFC 8918 on Invalid TLV Handling in IS-IS

Authors, Thanks for the swift work on this document. Acee On 9/24/20, 6:19 PM, "Lsr on behalf of rfc-edi...@rfc-editor.org" wrote: A new Request for Comments is now available in online RFC libraries. RFC 8918 Title: Invalid TLV Handling in IS-IS

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

H Joel, Can you reference the specific section in the IS-IS SRv6 draft you are commenting on? I seem to remember this discussion but it was at least a month back, if not more. Thanks, Acee On 9/23/20, 6:31 PM, "Lsr on behalf of Joel Halpern" wrote: The announcement prompted me to

Re: [Lsr] some doubt about RFC 5185 (Multi Area Adjacency)

Hi Meicong, From: Lsr on behalf of meicong Date: Thursday, September 24, 2020 at 2:23 AM To: "lsr@ietf.org" Cc: Huzhibo , "Jiangyu (China)" Subject: [Lsr] some doubt about RFC 5185 (Multi Area Adjacency) Hi ALL, About rfc5185 OSPF Multi-Area Adjacency section 2.7 Advertising Multi-Area

Re: [Lsr] I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt

It looks like some unfortunate tab settings at least for the OSPF model... Note that pyang can be used for formatting. pyang -f yang --yang-line-length 68 On 9/15/20, 11:47 AM, "Lsr on behalf of tom petch" wrote: The formatting of this I-D seems to have gone wrong making it hard to

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

. Please republish the draft as draft-ietf-lsr-isis-ttz-00.txt with experimental status. Acee and Chris From: Lsr on behalf of "Acee Lindem (acee)" Date: Tuesday, August 18, 2020 at 10:17 AM To: "lsr@ietf.org" Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-T

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

To: Aijun Wang Cc: Gyan Mishra ; Robert Raszuk ; Huzhibo ; Aijun Wang ; Peter Psenak ; lsr ; Acee Lindem (acee) ; Xiaoyaqun Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt I read the draft since the longish thread triggered my interest. As

[Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

Authors, The IETF IPRs declarations submitted for draft-chen-isis-ttz are specified here: https://datatracker.ietf.org/ipr/4029/ Are you aware of any other IPR that applies to draft-chen-isis-ttz? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669

[Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Based on the discussions in the last meeting and on the mailing list regarding draft-chen-isis-ttz-11, the chairs feel that there are enough differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it independently on the experimental track. These

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi Tony, Bruno, Les, From: Lsr on behalf of Tony Li Date: Tuesday, August 4, 2020 at 11:26 AM To: Bruno Decraene Cc: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02 Hi Bruno, [Bruno] Agreed so far. Do we agree that

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

From: Lsr on behalf of "Les Ginsberg (ginsberg)" Date: Monday, August 3, 2020 at 12:32 PM To: Bruno Decraene , Tony Li Cc: "lsr@ietf.org" Subject: Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt Bruno – Inline. From: bruno.decra...@orange.com Sent: Monday,

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

On 7/30/20, 1:31 PM, "Lsr on behalf of Acee Lindem (acee)" wrote: On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak" wrote: On 30/07/2020 18:03, Acee Lindem (acee) wrote: > So, how do we define a reachable route - is it any route subsumed by

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak" wrote: On 30/07/2020 18:03, Acee Lindem (acee) wrote: > So, how do we define a reachable route - is it any route subsumed by the summary LSA that we knew about in the past that becomes unreachable? When the PUA is w

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

. Thanks, Acee thanks Zhibo -- 胡志波 Hu Zhibo Mobile: +86-18618192287 Email: huzh...@huawei.com<mailto:huzh...@huawei.com> 发件人：Acee Lindem (acee) 收件人：Peter Psenak ;Robert Raszuk 抄 送：Aijun Wang ;Xiaoyaqun ;Huzhibo ;Aijun Wang ;lsr 时 间：2

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

So, how do we define a reachable route - is it any route subsumed by the summary LSA that we knew about in the past that becomes unreachable? When the PUA is withdrawn, how do we know whether it is because of expiration of the interval or the route becoming reachable again? This is a slippery

Re: [Lsr] "IGP Extensions for Segment Routing Service Segment" -draft-lz-lsr-igp-sr-service-segments-02

Thanks Hannes – this is exactly what I was suggesting rather than advertising the BGP-LS information in the IGPs. Acee From: Hannes Gredler Date: Wednesday, July 29, 2020 at 3:14 AM To: "liu.ya...@zte.com.cn" Cc: Acee Lindem , "zzhang_i...@hotmail.com" , "lsr@ietf.org" Subject: Re: [Lsr]

[Lsr] "IGP Extensions for Segment Routing Service Segment" - draft-lz-lsr-igp-sr-service-segments-02

Speaking as WG member: It seems the sole purpose of this draft is to get service segment information from nodes in the IGP domain to the IGP node that has a BGP session with the controller. You don’t need to put this information into the IGP in order to do this. Simply configure BGP sessions

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

.@ietf.org] On Behalf Of Robert Raszuk Sent: Tuesday, July 28, 2020 11:18 AM To: Acee Lindem (acee) Cc: Aijun Wang ; Zhibo Hu ; Yaqun Xiao ; lsr@ietf.org Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt Hello Acee, I would like to question your

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

omatically establish connections between ABRs. Thanks Zhibo Hu -Original Message- From: Acee Lindem (acee) [mailto:a...@cisco.com] Sent: Tuesday, July 28, 2020 1:51 AM To: Aijun Wang ; lsr@ietf.org Cc: Huzhibo ; Xiaoyaqun Subject: Re: [Lsr] N

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Please see the below inline. If I missed your comments, please correct me. Best Regards Aijun Wang China Telecom -Original Message- From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Tuesday, July 28, 2020 1:51 AM To: Aijun Wang ; lsr@ietf.org

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Speaking as an LSR Working Group member: Asking the WG precisely how to advertise prefix unreachability is the wrong question - it is analogous to asking whether to use a car or truck to drive off the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex and unnecessary

Re: [Lsr] Request WG adoption of TTZ

Speaking as WG member… See inline. From: Lsr on behalf of Uma Chunduri Date: Wednesday, July 15, 2020 at 12:52 PM To: Henk Smit Cc: "lsr@ietf.org" , Huaimo Chen Subject: Re: [Lsr] Request WG adoption of TTZ On Wed, Jul 15, 2020 at 5:22 AM Henk Smit mailto:henk.i...@xs4all.nl>> wrote:

Re: [Lsr] Request WG adoption of TTZ

ow is IS-IS TTZ even applicable to solving any problem in SDWAN? Thanks, Acee Linda -Original Message- From: Acee Lindem (acee) Sent: Tuesday, July 14, 2020 12:32 PM To: Linda Dunbar ; Christian Hopps Cc: LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf

Re: [Lsr] Request WG adoption of TTZ

BGP and RR with IS-IS TTZ for SDWAN Fabric setup. However, that is probably a topic that would be better addressed in the RTG WG. Thanks, Acee Linda -Original Message- From: Acee Lindem (acee) Sent: Tuesday, July 14, 2020 11:59 AM To: Linda Dunbar ; Chris

Re: [Lsr] Request WG adoption of TTZ

Linda, So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed this? __ Acee On 7/14/20, 12:52 PM, "Linda Dunbar" wrote: Christian, The SDWAN use case is about grouping a set of nodes in geographically different locations to be one TTZ zone being treated as

Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

Hi Les, Roman, On 7/14/20, 7:15 AM, "Roman Danyliw" wrote: Hi Les and Acee! > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: Monday, July 13, 2020 11:43 PM > To: Acee Lindem (acee) ; Roman Danyliw ; > The IESG

Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" wrote: Acee - Inline. > -Original Message- > From: Acee Lindem (acee) > Sent: Monday, July 13, 2020 9:04 AM > To: Les Ginsberg (ginsberg) ; Roman Danyliw > ; The IESG

Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

Hi Les, On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)" wrote: Roman - Thanx for the review. Inline. > -Original Message- > From: Lsr On Behalf Of Roman Danyliw via > Datatracker > Sent: Monday, July 13, 2020 7:40 AM > To: The IESG > Cc:

Re: [Lsr] Request WG adoption of TTZ

answers/explanations are inline below with prefix [HC]. Best Regards, Huaimo ________ From: Acee Lindem (acee) Sent: Tuesday, July 7, 2020 4:33 PM To: Huaimo Chen ; Christian Hopps Cc: lsr@ietf.org ; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ S

Re: [Lsr] Request WG adoption of TTZ

ween IS-IS TTZ and IS-IS Area Proxy are similar to the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy. Best Regards, Huaimo ________ From: Acee Lindem (acee) Sent: Tuesday, July 7, 2020 3:41 PM To: Huaimo Chen ; Christian Hopps Cc: lsr@ietf.org ; lsr-cha...@i

Re: [Lsr] Request WG adoption of TTZ

Speaking as WG member: Hi Huaimo, Independent of the major issue with Area Proxy differentiation, I have a couple other issues that I didn’t want to include in the same Email thread. 1. You can’t describe IS-IS protocol details and then just include OSPF encodings and expect the readers

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

; > Thanks, > Ketan > > -Original Message- > From: Amanda Baber via RT > Sent: 04 July 2020 07:53 > To: Acee Lindem (acee) > Cc: Peter Psenak (ppsenak) ; mraj...@juniper.net; > lsr@ietf.org; Ketan Talaulikar (ketant) ; > gunter.van_de

Re: [Lsr] Request WG adoption of TTZ

Speaking as WG member: I agree with Chris – when the IS-IS TTZ draft adopted the approach of having the area/zone leader originate a single LSP abstracting the zone/area last Oct, the main differentiation between the two approaches is the zone/area terminology. The other substantive difference

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

t: 02 July 2020 13:11 To: Acee Lindem (acee) ; iana-prot-pa...@iana.org Cc: lsr@ietf.org; Ketan Talaulikar (ketant) ; gunter.van_de_ve...@nokia.com; alvaro.ret...@futurewei.com Subject: Re: [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

Hi Amanda, On 7/1/20, 5:10 PM, "Amanda Baber via RT" wrote: Hi Acee, Alvaro, all, Alvaro: can you approve the request for early registration of the B-bit in the LLS Type 1 Extended Options and Flags registry at https://www.iana.org/assignments/ospf-lls-tlvs? Acee, Ketan: the

Re: [Lsr] IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

Hi Ketan, IANA, Alvaro, I don't see any problem with early allocation of this LLS bit and TLV - pretty straight forward. It would make sense to put the respective registries in the IANA section (included below for info). Open Shortest Path First (OSPF) Link Local Signalling (LLS) -

Re: [Lsr] draft-ietf-lsr-flex-algo

Speaking as WG chair: I'm delighted to see discussion on a draft that isn't in WG last call. Speaking as WG member: Maybe I'm missing something but do we really think we’re going to run out of non-flexible algorithms with 128? I just don't see it happening in my lifetime. Thanks, Acee

Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-invalid-tlv-02

Hi Ron, Thanks for the review. Acee On 6/26/20, 1:36 PM, "Ron Bonica via Datatracker" wrote: Reviewer: Ron Bonica Review result: Ready This draft is well tought out and ready for publication ___ Lsr mailing list Lsr@ietf.org

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

f which can take on one enumerated value – but there need not be a default. It is simply required to have a value. A few more comments inline. From: BRUNGARD, DEBORAH A Sent: Wednesday, June 17, 2020 1:07 PM To: Les Ginsberg (ginsberg) ; The IESG Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ie

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

Speaking as WG member: I support WG adoption of this draft on the experimental track. I think it is better for the WG to move forward and get some data points on these competing solutions than to be gridlocked. Thanks, Acee On 6/10/20, 3:28 PM, "Christian Hopps" wrote: This begins a 2

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

be specified as off. Otherwise as Bruno noted, this puts a huge burden on the operators and it then is an update. Thanks, Deborah Sent from my iPhone On Jun 12, 2020, at 9:05 PM, Acee Lindem (acee) wrote: Hi Deborah, Point of process… From: Deborah Brungard Date: Friday, June 12, 202

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

es which is under the purview of the LSR WG. Thanks, Acee Thanks, Deborah From: Les Ginsberg (ginsberg) Sent: Thursday, June 11, 2020 11:05 AM To: BRUNGARD, DEBORAH A ; The IESG Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) ; aretana.i...@g

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

Thanks Sarah – as a co-author, please state your awareness of IPR. Acee From: Sarah Chen Date: Thursday, June 11, 2020 at 2:34 PM To: Robert Raszuk Cc: Christian Hopps , "lsr@ietf.org" , "lsr-...@ietf.org" , "lsr-cha...@ietf.org" Subject: Re: [Lsr] WG adoption call for

[Lsr] FW: Nomcom 2020-2021 Second Call For Volunteers

FYI – Please consider volunteering for NOMCOM. Thanks, Acee Begin forwarded message: From: NomCom Chair 2020 Date: June 10, 2020 at 1:55:21 PM CDT To: IETF Announcement List Cc: "i...@ietf.org" Subject: Nomcom 2020-2021 Second Call For Volunteers This is the second sending of the call for

Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)

Hi Peter, Murray, On 6/9/20, 6:53 AM, "Peter Psenak" wrote: Hi Murray, thanks for your comments, please see inline: On 08/06/2020 08:00, Murray Kucherawy via Datatracker wrote: > Murray Kucherawy has entered the following ballot position for >

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda, One more point... On 6/9/20, 4:52 AM, "Peter Psenak" wrote: Linda, On 09/06/2020 02:37, Linda Dunbar wrote: > Peter, > > Thank you very much for adding the extra text to explain. > > But SR is supposed to be transparent to all intermediate nodes. Does

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

be set independent of the WG document name so we have freedom here. Thanks, Acee From: Lsr on behalf of "Acee Lindem (acee)" Date: Friday, May 15, 2020 at 3:40 PM To: "lsr@ietf.org" Subject: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduct

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

ts. My answers/explanations are inline below. Best Regards, Huaimo From: Lsr on behalf of Acee Lindem (acee) Sent: Friday, June 5, 2020 12:52 PM To: lsr@ietf.org Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

. Thanks, Acee From: Lsr on behalf of "Acee Lindem (acee)" Date: Friday, May 15, 2020 at 3:40 PM To: "lsr@ietf.org" Subject: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call This begins a 3 week (due to holida

Re: [Lsr] Query on OSPFv2 Extended Link TLV

Hi Jazeel, From: Lsr on behalf of JAZEEL MOHAMMED Date: Friday, June 5, 2020 at 7:41 AM To: "lsr@ietf.org" Subject: [Lsr] Query on OSPFv2 Extended Link TLV Hi LSR WG, I am finding it hard to understand the below statement under section "3.1. OSPFv2 Extended Link TLV" in RFC7684.. " If

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Hi Yali, On 6/5/20, 4:52 AM, "Lsr on behalf of wangyali" wrote: Hi Peter, Please see inline . Thanks, Yali -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Friday, June 5, 2020 3:56 PM To: wangyali ; lsr@ietf.org Subject: Re:

[Lsr] WG Document Adoption Call

Note that it is appropriate for draft authors to request a WG adoption call. However, the actual adoption call needs to be done by the WG chairs and that is when support/objection is requested. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll

I’ve received IPR responses from all the authors but Dean Cheng. Please respond. Thanks, Acee From: Lsr on behalf of "Acee Lindem (acee)" Date: Friday, May 15, 2020 at 3:48 PM To: "draft-cc-lsr-flooding-reduct...@ietf.org" Cc: "lsr@ietf.org" Subject: [Lsr]

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Speaking as WG chair: It seems were getting a number of questions and comments on these ELC signaling documents as they go to the RFC Queue. I'd like to encourage review and discussion of LSR documents earlier in the WG process. One way to facilitate this would be for the authors to solicit

[Lsr] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

Hi IANA, Martin, We’ve discussed this draft and are going forward with the early allocation request. While there is some overlap with other LSR WG proposals, there is no reason to block all the drafts given that it very unlikely that we will have a combined draft any time soon. Thanks, Acee

Re: [Lsr] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Scott, On 5/27/20, 11:17 AM, "Scott Bradner via Datatracker" wrote: Reviewer: Scott Bradner Review result: Not Ready This is an OPS-DIR review of OSPF Link Traffic Engineering Attribute Reuse (draft-ietf-ospf-te-link-attr-reuse) This ID describes application-specific

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

Hi Peter, Thanks - hopefully this will more than satisfy Ben's discuss. Acee On 5/26/20, 10:25 AM, "Peter Psenak" wrote: Hi Acee, updated the text based on your comments. thanks, Peter On 26/05/2020 16:07, Acee Lindem (acee) wrote:

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

Hi Peter, On 5/26/20, 8:22 AM, "Peter Psenak" wrote: Hi Acee, have you looked at the texts that I suggested in my response to Alvaro earlier today? I found it - let me reply to that Email. Thanks, Acee Please see inline: On 26/05/2020 13:49, Acee Lindem (a

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

Hi Alvaro, See inline. On 5/22/20, 10:59 AM, "Alvaro Retana" wrote: On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: Peter: Hi! > With respect to Alvaro's clarification, your answer for (1) makes sense; > thanks! I think Alvaro has offered to help work out what

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

h make use of the dynamic flooding infra in https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/ Thanks, Acee Kind regards Gyan On Thu, May 21, 2020 at 4:07 PM Acee Lindem (acee) mailto:a...@cisco.com>> wrote: Speaking as WG Co-chair: Hi Gyan, I guess you’ve joined this discussio

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

__ From: Gyan Mishra mailto:hayabusa...@gmail.com>> Sent: Thursday, May 21, 2020 10:36 AM To: Huaimo Chen mailto:huaimo.c...@futurewei.com>> Cc: Acee Lindem (acee) mailto:40cisco@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

H Rob, On 5/19/20, 5:59 AM, "Robert Wilton via Datatracker" wrote: Robert Wilton has entered the following ballot position for draft-ietf-ospf-mpls-elc-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

Hi Rob, On 5/19/20, 6:00 AM, "Robert Wilton via Datatracker" wrote: Robert Wilton has entered the following ballot position for draft-ietf-isis-mpls-elc-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To

[Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll

Authors, Are you aware of any IPR that applies to draft-cc-lsr-flooding-reduction-08.txt. 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

[Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

This begins a 3 week (due to holidays) WG adoption call for the “Flooding Topology Computation Algorithm” draft. Please issue your support or objection to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your convenience.

Re: [Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

Hi Warren, From: Warren Kumari Date: Friday, May 15, 2020 at 1:25 PM To: "Peter Psenak (ppsenak)" Cc: The IESG , "draft-ietf-ospf-mpls-...@ietf.org" , "lsr-cha...@ietf.org" , "lsr@ietf.org" , Acee Lindem , Alvaro Retana Subject: Re: Warren Kumari's No Objection on

Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

ehalf Of Alvaro Retana Sent: Thursday, May 14, 2020 12:46 PM To: Acee Lindem (acee) ; Peter Psenak (ppsenak) ; Elwyn Davies ; gen-...@ietf.org Cc: lsr@ietf.org; last-c...@ietf.org; draft-ietf-ospf-mpls-elc@ietf.org Subject: Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

r ELC MSD or advertisement of the OSPF capability is not supported. Although I might not have worded it as such, that was clear to me from the text. Feel free to recommend alternate text if you feel it is necessary. Thanks, Acee Thanks! Alvaro. On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) (

Re: [Lsr] Éric Vyncke's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

Thank you -éric -Original Message- From: Peter Psenak Date: Monday, 11 May 2020 at 19:14 To: Eric Vyncke , The IESG Cc: "draft-ietf-isis-mpls-...@ietf.org" , "lsr-cha...@ietf.org" , "lsr@ietf.org" , "Acee Lindem (acee)&

Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi Elwyn, On 5/11/20, 2:10 PM, "Elwyn Davies" wrote: Hi, Peter. In the light of some of your responses here, I would just like to clarify that one of the reasons for gen-art reviews is to try and make extremely complicated technical documents more accessible for those who

[Lsr] Minutes for LSR Interim Meeting #2 Posted

I’ve posted the minutes for the LSR Interim #2 meeting held on April 29th, 2020. Thanks much to Yingzhen Qu for taking them. One addition is that Yingzhen included the WebEx Chat and Jabber Chat logs as well. This is an interesting dynamic.

Re: [Lsr] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13

Hi Peter, Dhruv, On 5/6/20, 12:00 PM, "Peter Psenak" wrote: Hi Dhruv, please see inline: On 06/05/2020 17:40, Dhruv Dhody wrote: > Hi Peter, > > Thanks for your reply, snipping to points that need further discussion... > >> What about: >> >> Segment

[Lsr] FW: Reminder: Survey on planning for possible online IETF meetings

Esteemed LSR WG members, Virtual IETF meeting survey link below – please take the survey if you intend on participating in future virtual IETF meetings. Thanks, Acee From: WGChairs on behalf of Alissa Cooper Date: Tuesday, May 5, 2020 at 7:49 AM To: IETF WG Chairs Subject: Fwd: Reminder:

Re: [Lsr] Genart last call review of draft-ietf-isis-mpls-elc-11

pls-elc-11 HI Acee, On 4/24/20 3:38 PM, Acee Lindem (acee) wrote: Hi Mohit, Speaking as document shepherd. See inline. On 4/24/20, 3:39 AM, "Mohit Sethi via Datatracker" <mailto:nore...@ietf.org> wrote: Reviewer: Mohit Sethi Review result: Ready with Nits

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

Hi Yali, See [Acee]. On 4/28/20, 6:10 AM, "wangyali" wrote: Hi Acee, Please see inline [Yali]. Thanks. -Original Message- From: Acee Lindem (acee) [mailto:a...@cisco.com] Sent: Monday, April 27, 2020 8:27 PM To: wangyali ; lsr@ietf.org S

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hi Bruno, From: Lsr on behalf of Bruno Decraene Date: Monday, April 27, 2020 at 8:15 AM To: Robert Raszuk Cc: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" , Tony Przygienda Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed Robert, From: Robert Raszuk

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

Hi Yali, On 4/26/20, 10:34 PM, "Lsr on behalf of wangyali" wrote: Dear authors, It's valuable work. After reading I have a clarifying question. As you defined a Container unknown-tlv and Grouping unknown-sub-tlv in each OSPFv3 Extended LSAs defined in [RFC8362], are these used

Re: [Lsr] Genart last call review of draft-ietf-isis-mpls-elc-11

Hi Mohit, Speaking as document shepherd. See inline. On 4/24/20, 3:39 AM, "Mohit Sethi via Datatracker" wrote: Reviewer: Mohit Sethi Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Speaking as WG member: In the past, we developed protocol encodings that afforded future extendibility. I don't see the problem with the including the SID structure sub-sub-TLV and would support progression. Thanks, Acee On 4/10/20, 2:45 AM, "Lsr on behalf of Derek Yeung" wrote: Hi,

Re: [Lsr] RFC 8770 on Host Router Support for OSPFv2

Padma, Keyur, Manish, and Serpil - Congrats on publications... We are completing much of the existing work prior to the merge of the OSPF and IS-IS WGs into LSR. Thanks, Acee On 4/9/20, 1:23 PM, "Lsr on behalf of rfc-edi...@rfc-editor.org" wrote: A new Request for Comments is now

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

ot; Subject: Re: [Lsr] I,Scope of FIT Capability: a node or a link? Hi Acee, Tracing is of course useful. Here we also consider to combine the traffic engineering and monitoring. So the transit nodes are visible. For the loose TE, the intermediate SR nodes construct the segment monito

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

cker.ietf.org/doc/draft-qin-idr-sr-policy-ifit/ we propose to use bgp enabled sr-policy for IFIT auto deployment. It’s reasonable to incorporate both traffic engineering and monitoring. Thanks, Tianran 发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 发送时间: 2020年4月7日 2:54 收件人: Jeff Tantsura ; L

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

many candidate SR policies but only the best-path is active. You’d need to update all the candidate policies in order to assure your iFIT tracing is enabled on the corresponding SR path. Why would you want to put this in BGP? Acee Thanks, Tianran 发件人: Acee Lindem (acee) [mailto:a...@cisco.

Re: [Lsr] LSR Virtual Interim Minutes

And, for those of you running of things to quarantine watch on your favorite streaming service, here is the recording: https://ietf.webex.com/webappng/sites/ietf/recording/play/015369b6eda543b9a123ac3de1b45203 If I seem a bit flustered in the recording, it was because it took me until the

[Lsr] LSR Virtual Interim Minutes

I have uploaded the minutes from the virtual interim meeting. Thanks much to Yingzhen Qu for taking them. https://datatracker.ietf.org/meeting/interim-2020-lsr-01/materials/minutes-interim-2020-lsr-01-202004020900 Also, some of you missed signing the blue-sheet. Please send me your name

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Speaking as WG member – It seems that additional IFIT-specific information is required to make this useful and the IGPs are certainly not the case. Additionally, the point was made that an IFIT specific information channel would anyway be required to provision the telemetry generation. Thanks,

<    1   2   3   4   5   6   7   8   9   >