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
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
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
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
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
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:
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
;
> 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
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
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
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
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
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]
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
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-
.
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
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
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
>
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
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
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
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:
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
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
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
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
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
.@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
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
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
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
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]
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
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
.
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
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
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
Speaking as WG member:
I agree with Les. While you might get some flooding reduction out of this, it
wouldn’t be hard to better with a flooding next-neighbor algorithm that was
more well-thought (e.g., RFC 5614). Here are my concerns:
1. It seems that while it is a distributed algorithm,
Hi Alex,
Multi-Area interface disambiguation is required to support the OSPF MIB as
specified in RFC 4750. The table indexing doesn’t include the area. For example:
-- OSPF Interface Table
ospfIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF OspfIfEntry
MAX-ACCESS not-accessible
On Behalf Of Acee Lindem (acee)
Sent: Friday, November 20, 2020 6:17 AM
To: lsr@ietf.org
Subject: [Lsr] IETF I09 LSR Meeting Minutes
I have uploaded the minutes for the meeting on Monday morning. Thanks much to
Yingzhen Qu for taking them. Please send me any additions or corrections to
Arul Mozhi Perumal
Date: Wednesday, December 9, 2020 at 8:51 AM
To: Acee Lindem
Cc: "Acee Lindem (acee)" , "lsr@ietf.org"
, Tulasi Rami Reddy N
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
Hi Acee,
We aren't generating any trap today for the subn
Date: Wednesday, December 9, 2020 at 8:18 AM
To: "Acee Lindem (acee)"
Cc: "lsr@ietf.org" , Tulasi Rami Reddy N
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
Hi Acee,
This is a configuration error, right? Wouldn't ospfIfConfigError trap
Hi Tulasi,
You definitely shouldn’t generate the netMaskMismatch trap as this is for mask
mismatch detection on hello packets. You could generate the ospfIfRxBadPacket
but many do not for this case.
Thanks,
Acee
From: Lsr on behalf of Tulasi Rami Reddy N
Date: Wednesday, December 9, 2020 at
Speaking as LSR Co-Chair:
Hi Gyan,
This is more a discussion for the 6MAN WG. Here is the charter for the LSR WG:
https://datatracker.ietf.org/wg/lsr/about/
No need to cross-post to the LSR list…
Thanks,
Acee
From: Lsr on behalf of Gyan Mishra
Date: Monday, November 30, 2020 at 3:22 PM
To:
:21 PM
To: "Acee Lindem (acee)" , Alexander Okonnikov
, "Peter Psenak (ppsenak)"
Cc: "lsr@ietf.org"
Subject: Re: [Lsr] Link Data value for Multi-area links
The oddnes is that the architecture decision in RFC5185 to select
remote-ip-address instead of local
As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric
augmentation is ready for publication. This begins a two week last call for the
subject draft. Please indicate your support or objection on this list prior to
12:00 AM UTC on December 15th, 2020. Also, review comments
Speaking as a WG member, I support publication of the draft.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Monday, November 30, 2020 at 1:15 PM
To: "lsr@ietf.org"
Subject: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse
Metric&qu
This IP Flex Algorithm draft generated quite a bit of discussion on use cases
and deployment prior to IETF 109 and there was generally support for WG
adoption. This begins a two week WG adoption call. Please indicate your support
or objection to WG adoption on this list prior to 12:00 AM UTC on
Chris,
Are you aware of any IPR that applies to
draft-ietf-lsr-yang-isis-reverse-metric-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 respond
to this
ow what is it exactly that you are proposing?
Thanks,
Ketan
From: Aijun Wang
Sent: 04 December 2020 12:31
To: Ketan Talaulikar (ketant) ; 'Acee Lindem (acee)'
; 'Alexander Okonnikov'
; 'Van De Velde, Gunter (Nokia - BE/Antwerp)'
Cc: lsr@ietf.org; Peter Psenak (ppsenak)
Subject: RE: [Lsr] Link Data
osed to router default flow or session based
load balancing.
Any feedback related in this context is much appreciated.
Kind Regards
Gyan
On Mon, Nov 30, 2020 at 3:39 PM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
Speaking as LSR Co-Chair:
Hi Gyan,
This is more a discussion for the 6MA
Speaking as WG member:
I have read this draft and support adoption.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Tuesday, December 1, 2020 at 4:13 PM
To: lsr
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm)
In IP Networks"
Agreed. There is a boiler plate for Security Considerations that all YANG
models should start with.
Thanks,
Acee
On 12/10/20, 12:18 PM, "Lsr on behalf of tom petch" wrote:
From: Lsr on behalf of Michael Richardson via
Datatracker
Sent: 07 December 2020 02:49
Reviewer: Michael
Hi Lada,
Thanks for your prompt and thorough review.
Hi Chris,
Please address the comments.
Thanks,
Acee
On 12/16/20, 7:13 AM, "Ladislav Lhotka via Datatracker"
wrote:
Reviewer: Ladislav Lhotka
Review result: Ready with Issues
General comments
- YANG module
Hey Eric,
The Routing Directorate review is marked completed (giving that the comments
were Nits):
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/reviewrequest/13840/
We are assuming that you are happy with Peter's responses to your comments.
Thanks again for your review.
Thanks,
, please publish
as draft-ietf-lsr-isis-rfc5316bis-00.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Friday, October 23, 2020 at 10:43 AM
To: "lsr@ietf.org"
Subject: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS
MPLS and GMPLS
@cisco.com]
> Sent: Saturday, November 7, 2020 1:56 AM
> To: Aijun Wang
> Cc: Aijun Wang ; Acee Lindem (acee)
; lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for
draft-wang-lsr-passive-interface-attribute-04.txt
>
> Aijun,
>
> On 05/11
NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC Board,
and IETF Trust. We need more input from the community both on specific nominees
and on over-arching topics regarding what the community wants from these
specific groups and wants from its leadership in general. We need
Telecom
On Nov 11, 2020, at 02:01, Acee Lindem (acee) wrote:
Aijun,
Speaking as WG member:
At least for OSPF, passive interfaces are not standardized in RFC 2328 or RFC
5340. Hence, this purely a vendor concept.
Additionally, it is a property, albeit a vendor property, of a link and not a
pref
When the PUA use cases were presented today in the LSR meeting, I made the
comment that the RIB interactions for each use case would be different and
needed to be specified.
Thanks,
Acee
From: Robert Raszuk
Date: Monday, November 16, 2020 at 3:25 AM
To: Aijun Wang
Cc: Jeff Tantsura , lsr ,
Speaking as WG member…
With respect to the use cases in section 3:
3.1 Inter-Area Node Failure Scenario – With respect to this use case, the
node in question is actually unreachable. In this case, the ABRs will normally
install a reject route for the advertised summary and will send an ICMP
I have uploaded the minutes for the meeting on Monday morning. Thanks much to
Yingzhen Qu for taking them. Please send me any additions or corrections to me.
https://datatracker.ietf.org/doc/minutes-109-lsr/
Presenters and draft authors, please note that if more discussion is need on
your
hed differences.
The usage of such information, or the inferences method, may be different in
different scenario. I think the standardization work should defines the
fundamental common parts.
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org On Behalf Of Acee Lindem
(acee)
Sent: Friday, Novembe
aro Retana
Subject: RE: Early Allocation for IS-IS TTZ
FYI –
This has been approved by the DEs and IANA has updated the registry.
Les
From: Lsr On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, November 18, 2020 1:45 PM
To: Acee Lindem (acee) ; Huaimo Chen
; Christian Hopps ; Han
Speaking as WG Co-Chair:
From: Aijun Wang
Date: Wednesday, November 18, 2020 at 3:05 AM
To: Robert Raszuk , Jeff Tantsura
Cc: 'Gyan Mishra' , Acee Lindem , 'lsr'
, "'Acee Lindem (acee)'"
Subject: RE: [Lsr] Prefix Unreachable Announcement Use Cases
Hi, Robert:
The trigger and p
Date: Tuesday, November 17, 2020 at 4:02 AM
To: Robert Raszuk
Cc: lsr , Jeff Tantsura , Aijun Wang
, "Acee Lindem (acee)"
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk
mailto:rob...@raszuk.net>> wrote:
R
Speaking as WG member and longtime steward of the IGPs:
Hi Aijun,
My opinion is that we should not overload the base IGP topology advertisements
with everyone's favorite obscure use case. Hence, I think it would be a big
mistake to add this stub link TLV to the base LSAs.
Rather, exactly
From: Aijun Wang
Date: Tuesday, November 17, 2020 at 9:27 PM
To: Acee Lindem
Cc: 'lsr'
Subject: RE: [Lsr] New Version Notification for
draft-wang-lsr-passive-interface-attribute-06.txt
Hi, Acee:
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Acee Lindem
(acee)
Sent
We have a pretty full schedule and we add you as optional. I took a look at the
draft and it is all over the place right now with standardization requested for
one solution but 3 separate solutions partially specified. It could benefit
from some WG mailing list discussion prior to a 10 minute
Hi Aijun,
You still didn't answer the question as to why you didn't rework this draft for
passive interface to be an interface attribute rather than a prefix attribute?
Thanks,
Acee
On 10/1/20, 6:13 AM, "Acee Lindem (acee)" wrote:
Hi Aijun,
You didn't answer my question
62 in the same draft? Or
define a new AF type for the same extension to RFC7684?
Your guidance is greatly appreciated.
Thank you very much.
Linda Dunbar
From: Acee Lindem (acee)
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar ; Yingzhen Qu
; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re:
The WG Last Call and associated reviews have completed. Publication will be
requested for the -03 and the next step is AD review.
Thanks,
Acee
On 1/5/21, 5:29 AM, "Lsr on behalf of internet-dra...@ietf.org"
wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
Speaking as co-author:
I am not aware of any IPR on the draft.
Thanks,
Acee
On 1/5/21, 4:17 AM, "Christian Hopps" wrote:
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-admin-tags/
Please indicate your support
Hi Shraddha,
Thanks for your review. I agree with your comments and will incorporate these
in the -01 version.
Thanks,
Acee
From: Shraddha Hegde
Date: Wednesday, January 20, 2021 at 6:40 AM
To: Jeff Tantsura , "lsr@ietf.org" ,
Christian Hopps
Cc: "lsr-cha...@ietf.org"
Subject: RE: [Lsr] WG
Speaking as document shepherd:
Hi Tom, Chris,
I agree that the example prefix should match the module prefix. Given that
ietf-isis-reverse-metric is a module specifically for this functionality and
not a general building block, I'm less concerned about the length of the
prefix. If it were a
After the first successful WG last call, the authors discovered that some
re-work was needed for OSPF AS External route calculation – specifically with
respect to the Flex Algorithm ASBR metrics and calculation. This was fixed and
there were clarifications in the IANA section (see versions -14
Hi Joel,
At first I wondered where this document should reside and then decided that LSR
is probably as good as any other place.
Can you guys check whether it is mostly in line with
https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it should
be referenced?
Thanks,
Acee
I agree with Ketan.
Thanks,
Acee
From: Lsr on behalf of "Ketan Talaulikar (ketant)"
Date: Thursday, June 10, 2021 at 11:10 AM
To: Gyan Mishra
Cc: "lsr@ietf.org" , Christian Hopps ,
"peng.sha...@zte.com.cn"
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
SID
Speaking as WG contributor:
From: Lsr on behalf of "Les Ginsberg (ginsberg)"
Date: Friday, May 7, 2021 at 12:53 PM
To: "Ketan Talaulikar (ketant)" , Alvaro
Retana , "Peter Psenak (ppsenak)" ,
"lsr@ietf.org"
Cc: Christian Hopps ,
"draft-ietf-lsr-isis-srv6-extensi...@ietf.org"
, Gunter Van
pdates”. Is that right? It
was a little confusing given the reply chain.
(I’ve already given my opinion but said I’m not going to go to the mat over it.)
—John
On May 17, 2021, at 8:21 AM, Acee Lindem (acee)
wrote:
That we be my preference as well. We’ve had several discussions on what
con
Hi Peter,
On 5/17/21, 9:07 AM, "Peter Psenak" wrote:
Hi Acee,
On 17/05/2021 14:56, Acee Lindem (acee) wrote:
> Hi John,
>
> Yes – I think “updates” should be removed. Registries are created
> explicitly for the purpose of tracking extensi
That we be my preference as well. We’ve had several discussions on what
constitutes “update” and I believe that the consensus was that a document isn’t
“updated” unless the current behavior is changed. If we’ve done our jobs,
protocols are designed to be extended and these extensions shouldn’t
I agree. This is probably similar to the situation of
https://datatracker.ietf.org/doc/rfc8950/ where implementations did it
differently than the specification.
Thanks,
Acee
On 5/10/21, 2:34 PM, "John Scudder" wrote:
Hi All,
I took a look at the list thread Ketan references at the
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
Please indicate your support or objection by May 27th, 2021.
Authors, please respond to the list indicating whether you are
Hi Tom,
I would agree with your assessment. However, I'd also put this draft in the
"wisdom to know the difference" category. I won't speak for the rest of the WG
but fixing it isn't a priority for me.
Thanks,
Acee
On 5/18/21, 5:46 AM, "Lsr on behalf of tom petch" wrote:
Looking at
Speaking as WG member:
I agree with Tony.
Furthermore, the extensions in the draft provide mechanisms to constraint
bandwidth beyond your concern that bandwidth be used as a cumulative metric. I
support WG adoption.
Thanks,
Acee
From: Tony Li on behalf of Tony Li
Date: Thursday, May 20,
Hi Rob,
On 5/20/21, 5:11 AM, "Robert Wilton via Datatracker" wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included
Hi Tony, Aijun,
From: Tony Li on behalf of Tony Li
Date: Friday, May 21, 2021 at 11:29 AM
To: Aijun Wang
Cc: Acee Lindem , lsr ,
"draft-hegde-lsr-flex-algo-bw-...@ietf.org"
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" -
Hi Greg,
Additionally, in a vacuum light will only travel 300 meters in a microsecond.
So, in a nanosecond, that is less than a foot. What transmission technology and
application do you anticipate that will require this this precision?
Thanks,
Acee
From: Tony Li on behalf of Tony Li
Date:
Authors,
There is a lot of interest in the document and sufficient support for WG
adoption. Please republish as draft-ietf-lsr-flex-algo-bw-con-00.txt.
Of course, the current discussion of some of the finer points can continue.
Thanks,
Chris and Acee
From: Acee Lindem
Date: Wednesday, May
I have received IPR declarations from Shraddha, Peter, and Tony. I still need
them from Bruno, William, and Rajesh.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Wednesday, May 12, 2021 at 6:15 PM
To: "lsr@ietf.org"
Cc: "draft-hegde-lsr-flex-algo-b
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
I am not aware of any IPR that applies to this draft.
Thanks,
Rajesh
Juniper Business Use Only
From: Acee Lindem (acee)
Sent: Thursday, May 13, 2021 2:39 AM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
On 5/23/21, 9:12 PM, "Christian Hopps" wrote:
"Acee Lindem (acee)" writes:
> Hi Greg,
>
>
>
> Additionally, in a vacuum light will only travel 300 meters in a
> microsecond. So, in a nanosecond, that is less than a fo
Speaking as a WG member:
I think the argument for delays < 1 usec is very weak and haven’t heard any
compelling arguments.
Thanks,
Acee
From: Lsr on behalf of Anoop Ghanwani
Date: Tuesday, May 25, 2021 at 6:08 PM
To: Tony Li
Cc: lsr , "gregory.mir...@ztetx.com"
Subject: Re: [Lsr] LSR WG
elay which I mentioned in my other email and
queueing delay which I forgot to mention.
I think it might be a good idea if the draft mentioned what delay(s) "SHOULD"
be used.
On Mon, May 24, 2021 at 4:10 AM Acee Lindem (acee)
mailto:40cisco@dmarc.ietf.org>> wrote:
On 5/23/
Speaking as WG member:
Hi Linda,
Even if you’ve added some IS-IS encodings, the draft still suffers from the
fundamental problem of the previous draft. If you can’t rely on the A-ERs to
consistently calculate an aggregated metric, how can you rely on all the
routers in the IGP routing domain
zation. An A-ER only needs to advertise the
App-Metrics for the ANYCAST addresses that match with the configured ACLs.
Note that routes are based on IP prefixes and not applications while the draft
uses these two interchangeably.
Thanks,
Acee
Any other concerns?
Thank you
Linda Dunbar
Fro
niper Business Use Only
>
> *From:*Les Ginsberg (ginsberg)
> *Sent:* Thursday, June 24, 2021 10:56 AM
> *To:* Acee Lindem (acee) ; lsr@ietf.org
> *Cc:* lsr-...@ietf.org; Christian Hopps ;
> draft-ietf-lsr-flex-algo@ietf.org
> *Subject:* RE: Sec
The second WG last call has ended. There is considerable support for
publication and a few minor comments. The most significant comments resulted in
an errata to RFC 8919. I will work on the shepherd’s writeup and will request
publication of the updated revision.
Thanks,
Acee
From: Acee
LSR WG,
This Errata is an outcome of the Flex-Algorithm discussion - is there any
further comment?
Thanks,
Acee
On 7/5/21, 5:48 PM, "RFC Errata System" wrote:
The following errata report has been submitted for RFC8919,
"IS-IS Application-Specific Link Attributes".
401 - 500 of 830 matches
Mail list logo
