LSR WG,
This Errata is also an outcome of the Flex-Algorithm discussion - is there any
further comment?
Thanks,
Acee
On 7/5/21, 5:54 PM, "RFC Errata System" wrote:
The following errata report has been submitted for RFC8920,
"OSPF Application-Specific Link Attributes".
All,
This simply a refresh before expiration with an update of some references,
deletion of white space, and some
reformatting of tree diagrams/modules so they don't exceed the 72 character
limit.
Thanks,
Acee
On 4/29/21, 11:43 AM, "Lsr on behalf of internet-dra...@ietf.org"
wrote:
A
Congrats Xiaohu (aka Tiger), Bruno, Robert, Luis, and Luay,
Goods things come to those who wait!!!
Thanks,
Acee
On 4/27/21, 6:10 PM, "Lsr on behalf of rfc-edi...@rfc-editor.org"
wrote:
A new Request for Comments is now available in online RFC libraries.
RFC 9013
Hi Jenny,
From: Lsr on behalf of "Zengmin (A)"
Date: Sunday, April 25, 2021 at 2:45 AM
To: "lsr@ietf.org"
Subject: Re: [Lsr] some doubt about RFC5329 ( Traffic Engineering Extensions to
OSPF Version 3)
question3：
4. Link TLV --- " The Neighbor ID sub-TLV is mandatory for OSPFv3 Traffic
Speaking as co-author, I'm not aware of any IPR applying to the draft. I also
support WG adoption.
Thanks,
Acee
On 5/2/21, 4:47 AM, "Christian Hopps" wrote:
This begins a 2 week WG adoption call for the following draft:
in subsequent revisions with appropriate references
to TEAS documents.
Thanks,
Acee
From: Lsr on behalf of Jie Dong
Date: Friday, March 26, 2021 at 10:39 AM
To: Chongfeng Xie , "Acee Lindem (acee)"
, "lsr@ietf.org"
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-I
on the scalability and where using
MTs to support VTNs would make sense and where it wouldn’t.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Tuesday, March 2, 2021 at 6:28 PM
To: "lsr@ietf.org"
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topolo
,
"chongfeng.xie" , "Acee Lindem (acee)"
, "lsr@ietf.org"
Subject: Re: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT)
for Segment Routing based Virtual Transport Network” -
draft-xie-lsr-isis-sr-vtn-mt-03
Hi, Acee,
Thanks for your understanding about
aware SIDs, it can further provide VTNs with
guaranteed resources. We could add some text about this to the draft if you
think this is helpful.
Yes – that would be useful.
Thanks,
Acee
Best regards
Chongfeng
发件人： Acee Lindem \(acee\)<mailto:acee=40cisco@dmarc.ietf.org>
发送时间： 2021
Hi Rob,
On 4/5/21, 9:41 AM, "Robert Wilton via Datatracker" wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-prefix-originator-10: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included
at 8:58 AM
To: Acee Lindem , "chongfeng.xie" ,
Jie Dong , "Acee Lindem (acee)"
, "lsr@ietf.org"
Subject: Re: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT)
for Segment Routing based Virtual Transport Network” -
draft-xie-lsr-isis-sr-vtn-mt-03
Hi,
Thanks for your review and comments Bruno and Peter for quick resolution.
Acee
On 3/12/21, 9:20 AM, "bruno.decra...@orange.com"
wrote:
Hi Peter,
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, March 12, 2021 3:13 PM
>
> Hi Bruno,
>
> please see
-annoucement-05
On Mon, Mar 8, 2021 at 7:37 PM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
Speaking as a WG member:
Hi Gyan,
The first question is how do you know which prefixes within the summary range
to protect? Are these configured? Is this half-assed best-effort protection
Speaking as WG member:
Hi Les,
My opinion is there is no harm and some advantage in having IANA registries for
unique IGP protocol bit flag fields. For the existing fields that don’t have
registries, there is no burning requirement to go back and define an IANA
registry until such time as that
The minutes to the LSR meeting at IETF 110 are posted. Thanks to Yingzhen Qu
for compiling them!
https://datatracker.ietf.org/doc/minutes-110-lsr/
Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Speaking as WG member:
As long as we are revising, I'd suggest changing "ISIS" in the title and
several times in the text to "IS-IS" consistent with other IS-IS RFCs (at least
the newer ones).
Thanks,
Acee
On 3/3/21, 1:32 PM, "Donald Eastlake" wrote:
Hi,
I have a few comments.
Hi Xiaodong,
You need to reply explicitly to the IPR poll.
Thanks,
Acee
On 2/17/21, 10:31 AM, "Christian Hopps" wrote:
Hi LSR and TEAS,
This begins a joint WG last call for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
Please discuss any issues on
Authors,
Are you aware of any other IPR that applies to draft-xie-lsr-issi-sr-vtn-mt?
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
This information draft describes how MT could be used for VTN segmentation. The
authors have asked for WG adoption.
This begins a three week LSR Working Group Adoption Poll for “Using IS-IS
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” -
Speaking as WG member:
Hi Linda and Co-authors,
My first major comment is the confusion with the usage of multiple anycast
addresses for the same application. Why are you requiring multiple anycast
address? It would seem the load balancing over multiple servers can be done at
the data center
Speaking as a WG member:
Hi Gyan,
The first question is how do you know which prefixes within the summary range
to protect? Are these configured? Is this half-assed best-effort protection
where you protect prefixes within the range that you’ve installed recently?
Just how does this work? It
Hi Yali,
Speaking as WG member:
So this rather simplistic draft can be summarized as separate out the
non-routing info into different LSPs, tag the corresponding LSPs, and then
implementations can "do the right thing". As we already have RFC 8202 which
offers clean separation, I don't know
Gurusiddesh,
I’ll defer to the RFC authors on your question. However, please refrain from
referring to bits as being “unset”. They are set or clear.
Thanks,
Acee
From: Lsr on behalf of Gurusiddesh Nidasesi
Date: Monday, April 19, 2021 at 6:13 AM
To: "lsr@ietf.org"
Cc: Spencer Giacalone ,
ate use range in that registry. Any idea
if it’s being made use of? Hard to imagine.
On Apr 19, 2021, at 9:46 AM, Acee Lindem (acee) wrote:
Hi John,
The authors have requested early IANA allocation for the subject draft to
facilitate implementation. The suggested values are:
This specificatio
Hi John,
The authors have requested early IANA allocation for the subject draft to
facilitate implementation. The suggested values are:
This specification updates Link Local Signaling TLV Identifiers registry:
https://www.iana.org/assignments/ospf-lls-tlvs/ospf-lls-tlvs.xhtml#ospf-lls-tlvs-1
Hi John, IANA,
The authors have requested early IANA allocation for the subject draft to
facilitate implementation.
The following sub-TLV is added to the OSPFv2 Extended Link TLV sub-TLVs
registry under the OSPFv2 Parameters IANA registry:
Value: Suggested Value - 24
Name: L2 Bundle
This draft also meets the RFC 7120 section 2 requirements and is a target for
WG last call. The function has been implemented in IS-IS (RFC 8668) and the
OSPF functionality is analogous.
Thanks,
Acee
From: Acee Lindem
Date: Monday, April 19, 2021 at 10:01 AM
To: John Scudder , IANA
Cc:
Hi Les,
As stated in the guidance, it would be better for the IANA registry to be
created by the document that creates the field. If there is a reasonable
possibly of extension, we don't see any reason not to create a registry. It's
not like IANA registries are a scarce commodity.
Thanks,
Hi Adrian,
Thanks Much - I think these are all good comments and would greatly improve
both the completeness and readability of the draft.
Hi Authors,
This is really a good review and I believe all the comments should be
incorporated. While many of these are sins of omission that will take
Thanks Peter - we will have a second WG Last Call on the new version of the
draft.
Acee
On 2/19/21, 7:08 AM, "Lsr on behalf of Peter Psenak" wrote:
Hi,
these are larger, but important change and we would like the WG to
review them. Changes are mostly OSPF specific, except the
IS-IS IANA Registry Experts,
The authors of “IGP Flexible Algorithms (Flex-Algorithm) in IP Networks” have
requested code point allocation for the IS-IS code points in the draft. Please
evaluate the request and, if accepted, assign values from the respective
registries.
Thanks,
Acee
specific node would be
applicable to anything but that link and node for the flex algorithm
application.
Thanks,
Acee
Thanks,
Acee
Ron
Juniper Business Use Only
From: Acee Lindem (acee)
Ron
Juniper Business Use Only
From: Acee Lindem (acee)
Sent: Friday, August 13, 2021 10:22 AM
To: Ron Bonica ; lsr@ietf.org
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
[External Email. Be cautious of content]
Speaking as a WG member:
Hi Ron,
My ratio
it would be a mistake to bifurcate the IGP
standards with yet another way of encoding link attributes for different
applications.
Thanks,
Acee
From: Lsr on behalf of Ron Bonica
Date: Thursday, August 12, 2021 at 3:46 PM
To: "Acee Lindem (acee)" , "lsr@ietf.org"
Subject: Re:
The WG Adoption call has ended and there is sufficient support for WG adoption.
Please republish the drafts as:
draft-ietf-lsr-isis-srv6-yang-00.txt
draft-ietf-lsr-ospf-srv6-yang-00.txt
Note that the IS-IS draft name should also include "lsr-".
Thanks,
Chris and Acee
On 7/22/21,
or ISIS, we can put them under “Inter-AS Reachability TLV”, as defined
in RFC5316.
Comparing with other proposals, the above solutions may be more easy to
implement and deployment, and does not influence the core SPF computation.
Best Regards
Aijun Wang
China Telecom
From: Acee Lindem (acee)
Se
We still need IPR declarations from Kamran Raza and Dan Ye.
Thanks,
Chris and Acee
On 7/22/21, 6:50 AM, "Christian Hopps" wrote:
Hi Folks,
This begins a 3 week WG Adoption Call for the following related YANG drafts:
https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/
on the issues found during the
telechat.
>
> Thanks,
> Yaron
>
>
> On 8/19/21, 20:55, "Acee Lindem (acee)" wrote:
>
> Hi Yaron,
>
> Thanks for the review. Can you update the status of the SECDIR
review?
&
I've scheduled a Meetcho session for this meeting as well.
https://meetings.conf.meetecho.com/interim/?short=e10d1782-56ea-4d19-969d-e02a3e265a91
Thanks,
Acee
On 8/16/21, 11:13 AM, "Lsr on behalf of IESG Secretary" wrote:
The Link State Routing (lsr) WG will hold
a virtual interim
nce.
Aijun Wang
China Telecom
On Jul 31, 2021, at 06:45, Aijun Wang wrote:
Hi, Acee:
Thanks for your comments.
Please see the replies inline.
Aijun Wang
China Telecom
On Jul 31, 2021, at 01:00, Acee Lindem (acee) wrote:
Hi Gyan,
See brief inlines.
From: Gyan Mishra
Date: Thursday, July
You may have noticed that a lot of inter-dependent LSR and IDR RFCs where
published in the last couple days. Congrats to all the Authors!!!
New LSR RFCs include:
RFC 9084 - OSPF Prefix Originator Extensions
RFC 9088 - Signaling Entropy Label Capability and Entropy Readable Label
using IS-IS Gen App (RFC 6823) and OSPF
Transport Instance to advertise this information. If this is where you are
going, I don’t believe you have a strong enough use case to justify
specification, let alone the development and deployment.
Thanks,
Acee
Aijun Wang
China Telecom
On Aug 15, 202
Hi Qin,
Can you publish a revision so that Yaron assure it satisfies his comments?
Thanks,
Acee
On 8/12/21, 9:21 PM, "Qin Wu" wrote:
Thanks Acee and Tom for good suggestion, we will take them into account.
-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...
The LSR WG last call has ended and I will request publication once the SECDIR
comments are satified.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Wednesday, July 21, 2021 at 12:46 PM
To: "lsr@ietf.org"
Cc: "draft-ietf-lsr-pce-discovery-security-su
v-06.
Thanks!
-Qin
-邮件原件-----
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2021年8月17日 4:33
收件人: Qin Wu ; tom petch ;
Yaron Sheffer ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Sec
Hi Yaron,
Thanks Yaron - I know for RTG DIR we can update our reviews as closed with our
datatracker login.
Thanks,
Acee
On 8/19/21, 4:44 PM, "Yaron Sheffer" wrote:
Hi Acee,
I honestly don't know how to do it, and if I even can unless you send a new
review request.
Copying
Hi Peter,
I had too long of a context switch on flex algo See inline.
On 9/12/21, 2:15 PM, "Lsr on behalf of Peter Psenak" wrote:
Hi Acee,
On 11/09/2021 16:59, Acee Lindem (acee) wrote:
> Hi Peter,
>
> On 9/10/21, 1:46 AM, "Lsr on behalf
Hi Linda, Tony,
From: Linda Dunbar
Date: Wednesday, September 15, 2021 at 3:45 PM
To: Tony Li , "Peter Psenak (ppsenak)"
Cc: "Acee Lindem (acee)" , Acee Lindem
, Bruno Decraene , "lsr@ietf.org"
Subject: RE: [Lsr] draft-ietf-lsr-flex-algo
Tony,
Answers are ins
Hi Robert,
From: Robert Raszuk
Date: Thursday, September 16, 2021 at 4:23 PM
To: Acee Lindem
Cc: Peter Psenak , Linda Dunbar
, Tony Li , "lsr@ietf.org"
, Bruno Decraene , "Acee Lindem
(acee)"
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
Acee,
Wide communities actually
Hi Robert,
From: Robert Raszuk
Date: Thursday, September 16, 2021 at 5:34 AM
To: Peter Psenak
Cc: Linda Dunbar , Tony Li ,
"lsr@ietf.org" , Bruno Decraene , Acee
Lindem , "Acee Lindem (acee)"
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
I believe flex-algo with addition
Hi Rajesh,
This is the extended community type and RFC 6565 really should have had some
references for this - It took me a good 15-20 minutes to recall all the
details. The first octet specifies the extended community type of domain ID as
defined in
Removing John as he hasn't followed the IETF for decades.
I believe the intention of the text is to reference Figure 9. However, the
terminology is confusing. I would remove the reference to "dashed". See
suggested corrections to line 3 and 6 of the paragraph below.
Corrected Text
Hi Peter,
On 9/10/21, 1:46 AM, "Lsr on behalf of Peter Psenak" wrote:
Linda,
On 09/09/2021 22:17, Linda Dunbar wrote:
> Peter and Tony,
>
> Thank you very much for the explanation.
>
> Is it necessary to register with IANA on individual Flex-Algo value (a
value
cee,
Can you be more specific on what cause “backward not compatible” by introducing
the new Sub TLV to carry the additional metrics about the Edge Router?
Especially the newly introduced sub-TLV is only carried by the LSA distributed
among the routers in the special purposed routing domain (5G LDN).
org On Behalf Of Les Ginsberg
(ginsberg)
Sent: Wednesday, July 14, 2021 1:36 PM
To: Linda Dunbar ; Acee Lindem (acee)
; Yingzhen Qu ;
lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: [Lsr] IP layer metrics collected by Edge routers -
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presenta
, where is the right place?
Linda
From: Acee Lindem (acee)
Sent: Tuesday, July 13, 2021 2:24 PM
To: Linda Dunbar ; Yingzhen Qu
; lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: IP layer metrics collected by Edge routers -
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot req
for public Internet.
Answers to your questions are inserted below:
Linda
From: Acee Lindem (acee)
Sent: Monday, July 12, 2021 7:06 PM
To: Linda Dunbar ; Yingzhen Qu
; lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: IP layer metrics collected by Edge routers -
draft-dunbar-lsr-5g-edge-comput
Speaking as working member:
Hi Tony,
You've made it abundantly clear that you don't think like the ASLA encoding.
However, we have standardized the ASLA encoding in the LSR working group - this
is a done deal. You are free to propose an alternative but you this should not
be done after the
The meeting minutes have been uploaded. Thanks to Yingzhen Qu for taking them.
There were some definitely some bursts of discussion where congestion control
would have come in handy. The Meetecho chat from the meeting is also appended
but no attempt has been made at editing or even complete
Agree with Les.
Thanks,
Acee
On 8/9/21, 11:36 AM, "Les Ginsberg (ginsberg)" wrote:
Yaron/Qin -
For IS-IS security please also see RFC 5310.
For OSPF security please see RFC 5709.
Regarding the debate about MUST vs SHOULD, as I see it advertisement of
this information is an
Speaking as a WG Member:
In reviewing RFC 8919 and RFC 8920, it is clear that the ASLA mechanism was
to be used for new link attributes and applications. While the documents do not
mandate that there never could be a new way to advertise link attributes, this
was clearly the intent. Indeed,
Speaking as WG member:
Authors,
I think this draft is still flawed. Regarding the terminology, I don’t think it
should refer to passive interfaces at all since they aren’t referenced in
protocol documents. Rather, you should use stub-link consistently – including
the title. However, I don’t
eachable-annoucement
Hi Acee
Answers in-line
On Thu, Jul 29, 2021 at 7:02 PM Acee Lindem (acee)
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as WG member:
Authors,
I have comments and questions on the draft – many of them that I have raised
before.
1. If you use the standard ad
Speaking as WG chair:
We had a protracted discussion of the usage of link attributes for multiple
applications. The outcome was RFC 8919 and RFC 9820. If you browse the ospf and
isis WG archives for the years 2015-2018, you’ll see there was lots of
discussion. You can also view the IETF
I'd also recommend changing, "key names" to "key-ids or key-chain names" since
this is what is actually being advertised.
Thanks,
Acee
On 8/10/21, 11:53 AM, "tom petch" wrote:
From: Lsr on behalf of Yaron Sheffer
Sent: 10 August 2021 14:57
So let me suggest:
An
Hi Peter,
See inline.
On 10/13/21, 4:42 AM, "Peter Psenak"
wrote:
Hi Acee,
On 12/10/2021 21:05, Acee Lindem (acee) wrote:
> Speaking as WG Chairs:
>
> The authors of “Prefix Unreachable Announcement” have requested an
> adoption.
e are BFD limited…
Thanks,
Acee
Best,
R.
On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee)
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Peter,
See inline.
On 10/13/21, 4:42 AM, "Peter Psenak"
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Acee,
On 12/10/
are you worried about? Scaling?
In any case, we both agree that flooding this unreachability information to
everyone in the IGP domain is possibly not the best way to solve the problem.
Thanks,
Acee
From: Lsr on behalf of Robert Raszuk
Date: Tuesday, October 12, 2021 at 3:52 PM
To: "Acee L
Speaking as WG Chairs:
The authors of “Prefix Unreachable Announcement” have requested an adoption.
The crux of the draft is to signal unreachability of a prefix across OSPF or
IS-IS areas when area summarization is employed and prefix is summarised. We
also have “IS-IS and OSPF Extension for
e credit for raising awareness of the
problem space and it would be good to have them working with us on a single IGP
solution.
But PUA is not an alternative that I can support.
Les
> -Original Message-----
> From: Lsr On Behalf Of Acee Lindem (acee)
> Se
1 PM, "Lsr on behalf of Acee Lindem (acee)"
wrote:
Speaking as a mere WG member...
Assuming that there are enough remote PEs that need this unreachability
information and we want to use the IGPs for this, here is what I don't like
about PUA (Les has taken away much of my t
we are not in full agreement.
Les
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Greg
Mirsky
Sent: Wednesday, October 13, 2021 1:45 PM
To: Les Ginsberg (ginsberg)
mailto:40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak
mailto:40cisco...
Speaking as WG chair:
Agree totally with Chris here.
Thanks,
Acee
On 10/14/21, 5:26 AM, "Christian Hopps" wrote:
> On Oct 14, 2021, at 1:25 AM, Les Ginsberg (ginsberg)
wrote:
>
>
> The rest of your argument seems to be that we should move forward w the
PUA solution
> Equally if I send an e-mall with that abbreviation it goes into a black
hole with no MDN nothirng
>
> Tom Petch
>
> ps perhaps this is the considered opinion of the ESP on the I-D:-)
>
> ________
> From: Lsr on
Hi Robert,
From: Lsr on behalf of Robert Raszuk
Date: Friday, October 15, 2021 at 3:17 PM
To: Enke Chen
Cc: lsr , Tony Li
Subject: Re: [Lsr] Prefix Unreachable Announcement and IS-IS and OSPF Extension
for Event Notification
Hi Enke,
Yes each summarization/aggregation results in loss of
Hi Robert,
From: Robert Raszuk
Date: Tuesday, October 12, 2021 at 4:27 PM
To: Acee Lindem
Cc: "Acee Lindem (acee)" , "lsr@ietf.org"
Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF
Extension for Event Notification"
Hi,
>
Here is the Updated Agenda:
Here the New Agenda:
1. Draft Consensus Update
2. Team Les – Congestion Control
* Updates to solution (if any)
* Further Testing Results
3. Team Bruno – Congestion Control and Flow Control
* Updates to solution (if any)
*
Reminder that there will be an LSR Virtual Interim tomorrow on IS-IS Flooding
Optimizations. It will take place from 14:00 – 16:30 UTC tomorrow (September
29th, 2021). That’s 10 AM – 12:30 PM EDT and 7 AM – 9:30 AM PDT.
Here is the MeetEcho Link:
I’ve uploaded the minutes from yesterday’s meeting. Thanks much to Yingzhen Qu
for capturing a very fast-moving and spirited discussion!!!
https://datatracker.ietf.org/meeting/interim-2021-lsr-01/materials/minutes-interim-2021-lsr-01-202109291000-00
Thanks,
Acee
Speaking as WG Chair:
I believe this discussion has gone off track and the details of the BGP
alternatives need to be discussed on the IDR list. For the purposes of the LSR
discussion, Robert believes that this is a problem that needs to be solved but
that it could be better solved using BGP
sions. IANA monitors the temporary
allocations and sends email to the appropriate Designated Experts in advance of
the expiration date asking us if the extension should be granted.
Les
From: Huaimo Chen
Sent: Monday, November 15, 2021 7:25 AM
To: Acee Lindem (acee) ; Christian Hopps ;
Hannes Gr
Speaking as WG member:
I support WG adoption. My inclination is that this should be experimental track
and this feel this will allow for faster publication.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Monday, November 22, 2021 at 9:12 AM
To: "lsr@ietf.org&
Speaking as a WG member:
I support publication of this experimental extension to IS-IS.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Monday, November 22, 2021 at 2:48 PM
To: "lsr@ietf.org"
Subject: [Lsr] WG Last Call fo "IS-IS Flood Reflection&quo
Speaking as a contributor, I’m not aware of any undisclosed IPR.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Monday, November 22, 2021 at 9:14 AM
To: "draft-decraeneginsberg-lsr-isis-fast-flood...@ietf.org"
Cc: "lsr@ietf.org"
Subject:
The IETF 112 LSR Meeting Minutes have been uploaded. Thanks to Yingzhen Qu for
taking them!!!
https://datatracker.ietf.org/meeting/112/materials/minutes-112-lsr-00
The IETF 112 LSR Meeting MeetEcho recording is available here:
Hi Rob,
Seems it would be better to get modeling suggestions earlier in the cycle than
IESG telechat.
Thanks,
Acee
On 11/29/21, 6:05 AM, "Robert Wilton via Datatracker" wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-yang-isis-reverse-metric-04: No
We indicated the intent to adopt of
draft-decraeneginsberg-lsr-isis-fast-flooding-00 as an LSR WG document at the
IETF 112 LSR WG meeting.
We are now confirming WG consensus on this action. Please indicate your support
or objection on this list by 12:00 AM UTC on December 7th, 2021.
Another
Draft Authors and Contributors,
Are you aware of any IPR that applies to
draft-decraeneginsberg-lsr-isis-fast-flooding-00?
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
This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05. Please
post your support or objection to this list by 12:00 AM UTC on Dec 14th , 2021.
Also please post your comments on the draft. I’m allowing as extra week as I
like to get some additional reviews – although my comments
Authors, Contributors,
Are you aware of any IPR that applies to
draft-ietf-lsr-isis-flood-reflection-05?
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
The IETF is already applying these standards to new documents.
https://www.ietf.org/archive/id/draft-knodel-terminology-07.txt
At some point, I'd expect that someone with the time and energy will produce a
single document that updates all the existing documents using the updated
terminology.
nks,
Acee
Mike
Enterprise Network Solutions Architecture & Design
Research Triangle Park, NC USA
From: "Acee Lindem (acee)"
To: "Mik
Hi Alvaro,
On 11/16/21, 4:46 PM, "Alvaro Retana" wrote:
On November 16, 2021 at 4:10:16 PM, Acee Lindem wrote:
Hi!
> The IETF is already applying these standards to new documents.
The better reference to what the IETF is doing is this one:
: Aijun Wang
Cc: Les Ginsberg (ginsberg) ;
lsr@ietf.org; Christian Hopps ; Tony Przygienda
; Acee Lindem (acee)
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes
With MT separate control plane common data plane or Multi Instance separate
control
loopback FEC binding bgp next hop attribute is the job of the IGP
to build the RIB/FIB and MPLS LFIB which is all based on the underlay IGP
prefixes for hop by hop forwarding.
Kind Regards
Gyan
On Wed, Nov 17, 2021 at 9:23 PM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
The fai
Hi LSR WG,
NomCom is accepting feedback on nominees for
IAB, IESG Area Directors, IETF Trust and LLC Board. NomCom is also accepting
feedback on other topics (more on this below).
You can see the list of nominees for the 2021 nomination cycle at
https://datatracker.ietf.org/nomcom/2021/feedback/
start a WG
adoption poll at the IETF 112 LSR meeting.
Please read as well as the other drafts on the IETF 112 agenda -
https://datatracker.ietf.org/meeting/112/session/lsr
Thanks,
Acee
On 10/22/21, 12:38 PM, "Lsr on behalf of Acee Lindem (acee)"
wrote:
Thanks Bruno, Les, To
Thanks Bruno, Les, Tony Li, and Guillaume Solignac for your work on the merged
draft. Also thanks to Tony Przygienda and Peter Psenak who participated in the
merged draft discussions.
I plan to review it this weekend and would ask other WG members to read as
well.
Thanks,
Acee
On
Hi Linda,
On 11/3/21, 8:43 AM, "Lsr on behalf of Peter Psenak" wrote:
Hi Linda,
I went through your document and here are my comments:
1. the section 1, 2, and 3 can probably be summarized in a single
paragraph stating the problem you are trying to solve. The 5G details
Hi Les,
From: "Les Ginsberg (ginsberg)"
Date: Tuesday, December 7, 2021 at 5:10 PM
To: "Acee Lindem (acee)" , Acee Lindem
, "lsr@ietf.org"
Subject: RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
-draft-ietf-lsr-isis-flood-reflection-05
Let me try t
501 - 600 of 830 matches
Mail list logo
