Speaking as WG chair:
Can someone present this at IETF 114? It seems like there more interest than
most of the other agenda requests.
Thanks,
Acee
From: Lsr on behalf of Tony Li
Date: Wednesday, June 29, 2022 at 12:58 PM
To: Ketan Talaulikar
Cc: "draft-pkaneria-lsr-multi-...@ietf.org"
,
Hi Dhruv,
Thanks for your support and comments. We’ll address these in the next revision.
Thanks,
Acee
From: Dhruv Dhody
Date: Friday, June 24, 2022 at 1:30 AM
To: Christian Hopps
Cc: "lsr@ietf.org" , "draft-ietf-lsr-ospf-terminol...@ietf.org"
, "lsr-...@ietf.org"
, "lsr-cha...@ietf.org"
This Errata should be summarily rejected as there is no such reference in RFC
6823. Perhaps, it was reported against the wrong RFC.
Thanks,
Acee (as WG Co-Chair)
On 6/16/22, 5:13 AM, "Lsr on behalf of RFC Errata System"
wrote:
The following errata report has been submitted for
Hi Robin,
Thanks for the WG update.
From: Lsr on behalf of Lizhenbin
Date: Wednesday, June 15, 2022 at 10:20 AM
To: Susan Hares , lsr
Cc: draft-ietf-lsr-ospfv3-srv6-extensions
Subject: Re: [Lsr] Status of draft-ietf-lsr-ospv3-srv6-extensions
Hi Sue,
Sorry for the late response. Thanks
promotion to standards track,
this one certainly has potential.
Thanks,
Acee
On 6/15/22, 7:56 AM, "tom petch" wrote:
From: John Scudder
Sent: 14 June 2022 21:49
Cc: John E Drake; Les Ginsberg (ginsberg); Tony Li; tom petch; Acee Lindem
(acee); lsr@ietf.org
Subjec
; -Original Message-
> From: Lsr On Behalf Of John E Drake
> Sent: Tuesday, June 14, 2022 11:23 AM
> To: Les Ginsberg (ginsberg) ; John
> Scudder
> Cc: Tony Li ; tom petch ; Acee
> Lindem (acee) ; lsr@ietf.org
> Subject: Re: [Lsr] Dynami
Speaking as WG member:
From: Lsr on behalf of Robert Raszuk
Date: Tuesday, June 14, 2022 at 9:27 AM
To: Christian Hopps
Cc: Gunter Van de Velde , lsr ,
"draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org"
,
draft-wang-lsr-prefix-unreachable-annoucement
Subject: Re: [Lsr] Thoughts about
If an experimental technology proves successful, it will be promoted to
standards track. Two notable examples are GRE and PIM.
BIER may be another that eventually become standards track.
Thanks,
Acee
On 6/14/22, 8:41 AM, "Christian Hopps" wrote:
> On Jun 13, 2022, at 14:29, Tony Li
draft are mature enough to
consider Standards track.
>
> Les
>
>
>> -----Original Message-
>> From: Lsr On Behalf Of Tony Li
>> Sent: Monday, June 13, 2022 10:12 AM
>> To: tom petch
>> Cc: Acee Lindem (acee) ; l
Initially, there was a lot interest and energy in reducing the flooding
overhead in dense drafts. Now, it seems the interest and energy has waned. IMO,
this draft contains some very valuable extensions to the IGPs. I discussed this
with the editors and one suggestion was to go ahead and publish
Hi Chris,
I'm not aware of any IPR.
Thanks,
Acee
On 6/5/22, 5:55 AM, "Christian Hopps" wrote:
Given the simplicity of this document and having received no objections or
edits prior to or during the adoption call we'll be moving it immediately to
WGLC...
This begins a 2 week WG Last
Hi Stewart -
Thanks for review. I agree we should update the reference and will update the
shepherd's report. I'm just so used to using a Cisco login to get IEEE
standards that I didn't know the free access even existed. But this document
is, in fact, readily available:
Hi Ketan,
One more thing, there is a pending RTG Directorate review so you can expect
that in the coming weeks.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Monday, May 23, 2022 at 11:00 AM
To: Ketan Talaulikar
Cc: "lsr@ietf.org" , "draft-ietf-ls
4
Thanks,
Ketan
On Sun, May 22, 2022 at 10:19 PM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
All,
The WG last call has completed and we have support for publication. Publication
will be requested for the next version of this document which contains the
minor comments from the W
All,
The WG last call has completed and we have support for publication. Publication
will be requested for the next version of this document which contains the
minor comments from the WG last call.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, May 5, 20
o routers but we don’t want the non-flex-algo routers to use the
prefix advertisements at all.
Thanks,
Acee
Aijun Wang
China Telecom
On May 16, 2022, at 23:41, Acee Lindem (acee)
wrote:
From: Aijun Wang
Date: Monday, May 16, 2022 at 11:35 AM
To: Acee Lindem , John Scudder
Cc: "Peter
ction to accomplish the aim.
Aijun Wang
China Telecom
On May 16, 2022, at 19:50, Acee Lindem (acee)
wrote:
Hi Aijun,
We need to support mixed deployments of routers that do and do not support flex
algorithm and in these deployments the default algorithm, i.e., algorithm 0,
computation must
On 5/16/22, 8:12 AM, "Peter Psenak" wrote:
Hi Acee,
On 16/05/2022 13:25, Acee Lindem (acee) wrote:
> Hi Peter,
>
> On 5/16/22, 6:48 AM, "Peter Psenak"
wrote:
>
> Hi Acee,
>
> thanks for yo
t in two code
points. The inconsistency will be emerged later when the additional sub-TLV is
added under this code point.
In conclusion, reusing the FAPM is the right direction to solve the mentioned
use case in the updated draft.
Aijun Wang
China Telecom
> On May 14, 2022, at 04:29, Acee Lindem
Hi Peter,
On 5/16/22, 6:48 AM, "Peter Psenak" wrote:
Hi Acee,
thanks for your comments, I have incorporated them all.
Please see one response inline:
On 13/05/2022 22:28, Acee Lindem (acee) wrote:
> Hi Peter,
>
> Thanks for addressing t
with non-ASCII
text.
Thanks,
Acee
Thoughts?
Thanks,
—John
On Sep 13, 2021, at 1:28 PM, Acee Lindem (acee)
mailto:acee=40cisco@dmarc.ietf.org>> wrote:
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
in the IANA registry.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, May 5, 2022 at 1:51 PM
To: "lsr@ietf.org"
Cc: "draft-ietf-lsr-ospf-l2bund...@ietf.org"
Subject: [Lsr] Working Group Last Call on "Advertising L2 Bundle Membe
if
necessary?
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, May 5, 2022 at 1:52 PM
To: "draft-ietf-lsr-ospf-l2bund...@ietf.org"
Cc: "lsr@ietf.org"
Subject: [Lsr] Working Group Last Call IPR Poll on "Advertising L2 Bundle
Member Li
Authors,
There are no IPR disclosures for this draft.
Are you aware of any IPR that applies to draft-ietf-lsr-ospf-l2bundles-03?
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 a Working Group Last Call for draft-ietf-lsr-ospf-l2bundles. While
there hasn’t been as much discussion as I would like on the draft, it is
filling a gap in OSPF corresponding to IS-IS Link Bundles (RFC 8668). Please
review and send your comments, support, or objection to this
I’m still missing IPR replies from Shraddha, Rajesh, and William.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, April 7, 2022 at 3:10 PM
To: "draft-ietf-lsr-ip-flexa...@ietf.org"
Cc: "lsr@ietf.org"
Subject: [Lsr] Working Group Last
The WG last call has completed. We will submit an updated version of the
document for publication with the terminology changes based on the discussion
amongst the authors, Ketan, Robert, Gyan, and others.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, Apr
pr 20, 2022 at 12:18 PM Ketan Talaulikar
mailto:ketant.i...@gmail.com>> wrote:
Hi Acee,
Thanks for your inputs and we'll update the draft accordingly.
Thanks,
Ketan
On Tue, Apr 19, 2022 at 6:54 PM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
Speaking as WG Member and Document S
Hi Matthew,
Thanks for your RTG directorate review!!! These can be included in the WG last
call comment revisions. I had suggested the exact same change for "to be
diverted".
Hi Co-authors,
Please include the nits below.
Thanks,
Acee
On 4/27/22, 11:46 AM, "Matthew Bocci via
I'm not aware of any IPR.
Thanks,
Acee
On 4/25/22, 9:51 AM, "Lsr on behalf of Christian Hopps" wrote:
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/
Please indicate your support or
ore
straight-forward.
Thanks,
Acee
Best Regards
Aijun Wang
China Telecom
From: Ketan Talaulikar
Sent: Wednesday, April 20, 2022 6:47 PM
To: Aijun Wang
Cc: Les Ginsberg (ginsberg) ; lsr
; draft-ietf-lsr-ospf-reverse-met...@ietf.org; Acee Lindem (acee)
Subject: Re: [Lsr] Working Group Last
normative language.
Thanks,
Acee
Apart from the above, I do not have any other concerns or comments on that
draft.
Thanks,
Ketan
On Sun, Apr 17, 2022 at 3:15 AM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
Speaking as WG member and document shepherd:
Hi Gyan,
Thanks for the e
2.1
removed.
Les
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee
Lindem (acee)
Sent: Thursday, April 7, 2022 12:18 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc:
draft-ietf-lsr-ospf-reverse-met...@ietf.org<mailto:draft-ietf-lsr-ospf-reverse-met...@ietf.org>
Subjec
SR. This is not true since the base IGP FlexAlgo spec explicitly
> opens it up for usage outside of the SR forwarding plane. We already
> have BIER and MLDP forwarding planes as users of the IGP FlexAlgo. My
> suggestion is to remove such assertions from the document. It is
> sufficient to j
ion? Each flex-algo data-plane/app can be
deployed independently.
On Fri, Apr 15, 2022 at 7:51 PM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
Gyan,
What is your point here? Is this a trick question?
Thanks,
Acee
From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Date: Friday, April 15
o/data-plane? I am wondering if we can improve this
> text to bring this out in a better way. Or altogether remove this if we
> agree to not allow sharing of algo
>
> between different data planes to keep things simple.
>
> Multiple application can use the same Flex-Algorithm v
14, 2022 at 8:01 AM Acee Lindem (acee)
mailto:40cisco@dmarc.ietf.org>> wrote:
While RFC 4001 really didn't need to extend the zone index to IPv4, the
conversation also pertains to IPv6 address types. At least RFC 4001 got it
right by not making the zone index part of the defaul
While RFC 4001 really didn't need to extend the zone index to IPv4, the
conversation also pertains to IPv6 address types. At least RFC 4001 got it
right by not making the zone index part of the default types and defining ipv4z
and ipv6z.
Thanks,
Acee
On 4/14/22, 10:04 AM, "Lsr on behalf of
Speaking as document shepherd and WG member:
I don’t have a problem with “MPLS SR and SRv6 data planes” but wouldn’t be
opposed to “MPLS SR and SRv6 logical data planes”.
Thanks,
Acee
From: Robert Raszuk
Date: Thursday, April 14, 2022 at 9:51 AM
To: John E Drake
Cc: "Peter Psenak (ppsenak)"
From: netmod on behalf of Andy Bierman
Date: Wednesday, April 13, 2022 at 12:43 PM
To: tom petch
Cc: "lsr@ietf.org" , "net...@ietf.org" , "Rob
Wilton (rwilton)"
Subject: Re: [netmod] [Lsr] I-D Action:
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
On Wed, Apr 13, 2022 at 2:22 AM tom
link local addresses do not exist or do not need to be
supported, then you may want to bring the news to other WGs.
/js
On Tue, Apr 12, 2022 at 02:54:16PM +0000, Acee Lindem (acee) wrote:
> That was a hypothetical example based on IPv6 Link Local addresses - not
one anyone ha
On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote:
> Joel,
>
> There are plenty of examples of where the ip-address types are used and a
zone is not accepted. Show me the examples where it is expected? I do have
reason to believe there aren't any significant usages of t
Joel,
There are plenty of examples of where the ip-address types are used and a zone
is not accepted. Show me the examples where it is expected? I do have reason to
believe there aren't any significant usages of the ip-address types where zone
is accepted. Show me the models
Acee
On
From: netmod on behalf of Andy Bierman
Date: Tuesday, April 12, 2022 at 4:54 AM
To: Martin Björklund
Cc: "lsr@ietf.org" , NetMod WG , Robert Wilton
Subject: Re: [netmod] [Lsr] I-D Action:
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
On Tue, Apr 12, 2022 at 12:26 AM Martin Björklund
Speaking as WG member inline.
From: netmod on behalf of Andy Bierman
Date: Monday, April 11, 2022 at 1:28 PM
To: "Rob Wilton (rwilton)"
Cc: "lsr@ietf.org" , "net...@ietf.org"
Subject: Re: [netmod] [Lsr] I-D Action:
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
On Mon, Apr 11, 2022 at
See inline.
On 4/11/22, 5:13 AM, "tom petch" wrote:
From: Lsr on behalf of Reshad Rahman
Sent: 10 April 2022 21:42
Inline.
On Wednesday, April 6, 2022, 06:04:42 PM EDT, Acee Lindem (acee)
wrote:
Hi Chris (as WG member),
On 4/5/22, 10:47 AM, "
Hi Andy,
My opinion remains the same that RFC 4001 got it right with types including the
zone specification being the exception rather than the default. I know that
when people think IP address, they think the dotted 4 octet without “%”
appended. I’d still like to know if there are
I hate when people selectively snip my Emails and respond out of context.
Please don't do that in the future! I'll reply to the more constructive thread.
Acee
On 4/8/22, 4:45 PM, "Lsr on behalf of Randy Presuhn" wrote:
Hi -
On 2022-04-08 12:25 PM, Acee Lindem (a
See inline.
On 4/8/22, 1:59 PM, "netmod on behalf of Randy Presuhn"
wrote:
Hi -
On 2022-04-08 5:11 AM, Christian Hopps wrote:
..
> Instead, Acee (I'm not sure I'd call him WG B :) is asserting that
> *nobody* actually wanted the current type, and it has been misused
Authors,
There are no IPR disclosures for this draft.
Are you aware of any IPR that applies to draft-ietf-lsr-ip-flexalgo-04?
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 a Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric.
While there hasn’t been as much discussion as I would like on the draft, it is
filling a gap in OSPF corresponding to IS-IS Reverse Metric (RFC 8500). Please
review and send your comments, support, or objection to
Authors,
The following IPR has been disclosed:
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-ip-flexalgo
Are you aware of any undisclosed IPR that applies to
draft-ietf-lsr-ip-flexalgo-04?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs
This begins a WG last call for draft-ietf-lsr-ip-flexalgo-04. The draft had a
lot of support and discussion initially and has been stable for some time.
Please review and send your comments, support, or objection to this list before
12 AM UTC on April 22nd, 2022.
Thanks,
Acee
Jürgen,
On 4/7/22, 12:08 PM, "Jürgen Schönwälder"
wrote:
On Thu, Apr 07, 2022 at 02:35:03PM +0000, Acee Lindem (acee) wrote:
>
> We already a large number of models that use the existing inet:ip-address
types whose implementations don't support the zone. Why
reasonably, use a different typedef in this model.
Point me to a usages where the zone is actually desired and supported?
Acee
Yours,
Joel
On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote:
> Hi Martin,
>
> On 4/7/22, 1:02 PM, "netmod on behalf of M
eps its import "revision-or-derived" extension, would also allow
> > such modules to indicate the dependency on the updated
revision/definition
> > of ietf-inet-types.yang.
> >
> > Of course, the description associated with the updated
> > ie
Kent,
On 4/7/22, 4:39 AM, "Kent Watsen" wrote:
Juergen et. al. ,
> What are our options?
>
> a) Do nothing and accept that types are called as they are.
> b) Change the types as suggested and accept that doing so breaks
> modules where zone indexes are meaningful.
Hi Chris (as WG member),
On 4/5/22, 10:47 AM, "Christian Hopps" wrote:
> On Apr 5, 2022, at 09:48, Acee Lindem (acee) wrote:
>
> [wg-member]
>
> The thing is that most of the existing RFCs use inet:ip-address rather
inet:ip-address-no-zone. It
Jürgen and netmod WG, +IESG,
It is not just the IETF models that are using the inet:ip-address for the
standard IPv4/IPv6 addresses without zones. Every vendor’s native models and
the OpenConfig models use the base types and expect the standard IP address
notation. If we don’t fix this, it is
On 4/5/22, 11:37 AM, "Lsr on behalf of Jürgen Schönwälder"
wrote:
On Tue, Apr 05, 2022 at 01:48:25PM +0000, Acee Lindem (acee) wrote:
> [wg-member]
>
> The thing is that most of the existing RFCs use inet:ip-address rather
inet:ip-address-no-zone.
Hi Chris,
On 4/5/22, 10:47 AM, "Christian Hopps" wrote:
> On Apr 5, 2022, at 09:48, Acee Lindem (acee) wrote:
>
> [wg-member]
>
> The thing is that most of the existing RFCs use inet:ip-address rather
inet:ip-address-no-zone. It would be
Hopps" wrote:
If they are new leaf values why not use the correct no-zone variant, what's
the harm in doing it right? It has a nice side effect of basically restricting
the base spec zone values to no-zone only. :)
Thanks,
Chris.
[wg member]
> On Apr 4, 2022, at 12:30
On 4/4/22, 11:55 AM, "tom petch" wrote:
From: Acee Lindem (acee)
Sent: 04 April 2022 15:58
Hi Tom, +Juergen, netmod WG,
I think the question you ought to be asking is whether the base IPv4 and
IPv6 address types should be modified to NOT include the zone an
Hi Tom, +Juergen, netmod WG,
I think the question you ought to be asking is whether the base IPv4 and IPv6
address types should be modified to NOT include the zone and the zone versions
should be added as a separate YANG type.
The RFC 6991 is under revision now:
I’ve posted the minutes for the LSR meeting minutes. Thanks to Yingzhen Qu for
taking them.
https://datatracker.ietf.org/meeting/113/materials/minutes-113-lsr-00
The transcript of the Jabber chat during the LSR meeting is appended to the
meeting minutes. There was some interesting discussion
I agree with Tony that these other PUB/SUB efforts aren’t directly applicable.
I don’t necessarily agree that YANG is evil though However, note that the
I2RS effort (where such a route monitoring capability was envisioned) was for
the most part unsuccessful.
Thanks,
Acee
From: Lsr on
ifferent metrics for
Flex-Algo 128 and 129.
Best Regards
Mengxiao Chen
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Aijun Wang
发送时间: 2022年3月23日 9:22
收件人: 'Acee Lindem (acee)' ;
draft-lin-lsr-flex-algo-met...@ietf.org
抄送: lsr@ietf.org
主题: Re: [Lsr] Question on "Advertisement of Dedicated Met
Speaking as WG member:
Hi Co-authors,
I’m read this draft and I really don’t see why you couldn’t just use the
algorithm-specific metric in section 8 and 9 and draft-ietf-lsir-flex-algo? It
seems to me that the use case is fairly obscure and there is nothing to prevent
usage of these metrics
Hi Chenxi,
Our agenda is more than full. I suggest you socialize the draft on the LSR
list. I’ll reserve my comments for that discussion but note that traffic
engineering on LAN networks is best effort and implying this level of
per-neighbor metric isn’t tenable. As a WG member, I’d hope you’d
to notice :-)
That was exactly what I was looking for. Is there implementation report
documented anywhere ? I checked LSR WG wiki page but not much content there ...
Best,
Robert.
On Tue, Mar 8, 2022 at 3:11 PM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
Hi Robert,
From: Robert R
d
prevent the router from being added to the OSPF topology.
So, the only gaps we have here are in the understanding of the OSPF protocol
and reading of the previous Email thread (hopefully, neither of those will
require standardization).
Thanks,
Acee
Thank you,
R.
On Tue, Mar 8, 2022 at 12:36 PM A
fill.
Thx,
R.
On Tue, Mar 8, 2022 at 4:02 AM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
Hi Aijun,
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Monday, March 7, 2022 at 9:41 PM
To: Acee Lindem mailto:a...@cisco.com>>, Robert Raszuk
mailto:rob...@
hem? All the machinery for passive monitoring exists, no
need to invent anything.
Thanks,
Acee
Should we unified such requirements in such way then?
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org On Behalf Of Acee Lindem
(acee)
Sent: Monday, March 7, 2022 11:57 PM
Speaking as WG member:
I was going to wait to comment on this due to more important tasks but it
appears the discussion is under way. This requirement surfaced about 25-30
years back. In fact, there was one SP (who will remain anonymous) that actually
had a OSPF monitoring function that kept
Hi Chris,
I'm currently a co-author and provided input on the encoding and moving the
encoding from the base LSAs/TLVs to the TE LSAs/TLVs given that the intended
use is, in fact, traffic engineering.
However, I do not support WG adoption unless the utility of advertising these
external
Agree with Alvaro... There is nothing that says we can't do this document now
and still redo the base documents with updated terminology and Errata
incorporated. The latter is likely to be a multi-year process while hopefully
the former can be done in a year given the right focus.
Thanks,
Acee
detected by BFD) may help reduce the frequency of adjacency flaps and
therefore reduce the associated routing churn.
Not sure if this is normative or informative, but it addresses my point.
Thx,
Robert.
On Thu, Feb 10, 2022 at 4:50 PM Acee Lindem (acee)
mailto:40cisco@dmarc.ietf.org>>
://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, January 27, 2022 at 12:09 PM
To: "lsr@ietf.org"
Cc: "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
Subject: [Lsr] Working Group Last Call
Hi Rajesh,
I’m missing a WG last call declaration from you.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, January 27, 2022 at 12:16 PM
To: "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
Cc: "lsr@ietf.org"
Subject: [Lsr] IPR Poll
Hi Robert,
I think that much of the additional functionality you are proposing is beyond
the scope of the draft and IGP BFD usage today. You could propose all these
additional capabilities (e.g., MTU testing and link quality determination
beyond what is already in BFD) in a separate draft.
Hi John,
This errata is valid.
Thanks,
Acee
On 2/5/22, 8:23 AM, "Lsr on behalf of RFC Errata System" wrote:
The following errata report has been submitted for RFC8665,
"OSPF Extensions for Segment Routing".
--
You may review the report
irtual links
and unnumbered interfaces? With virtual links, one would have to establish a
multi-hop BFD session, so it is slightly different from a BFD operational
standpoint. For e.g, capability to support single-hop BFD may not translate to
the capability to support multi-hop BFD..
Regar
Hi Ketan,
From: Ketan Talaulikar
Date: Thursday, February 3, 2022 at 12:41 PM
To: Acee Lindem
Cc: "Acee Lindem (acee)" , "lsr@ietf.org"
, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD
place that would lead one to
believe it is pre-node.
Thanks,
Acee
From: Ketan Talaulikar
Date: Thursday, February 3, 2022 at 10:31 AM
To: Acee Lindem
Cc: "Acee Lindem (acee)" , "lsr@ietf.org"
, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
Subject: Re: [Lsr] Wor
and an updated version is coming with some
updates based on that discussion. Remember that we don’t necessarily have to
incorporate every suggested change but simply need to conclude the discussion.
Thanks,
Acee
From: "Acee Lindem (acee)"
Date: Friday, January 28, 2022 at 7:24 AM
To: Acee Lin
Hi Robert,
From: Robert Raszuk
Date: Saturday, January 29, 2022 at 2:25 PM
To: Acee Lindem
Cc: Ketan Talaulikar , lsr ,
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
, Albert Fu
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
Speaking as Document Shepherd:
Hi Robert,
From: Robert Raszuk
Date: Saturday, January 29, 2022 at 11:15 AM
To: Ketan Talaulikar
Cc: lsr , "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
, Albert Fu
, Acee Lindem
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
adcast/NBMA network, then some clarification for the procedures
are needed.
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org On Behalf Of Ketan Talaulikar
Sent: Saturday, January 29, 2022 4:22 PM
To: Aijun Wang
Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu
; A
ets.
Thanks,
Acee
From: lsr-boun...@ietf.org On Behalf Of Aijun Wang
Sent: Friday, January 28, 2022 2:02 PM
To: 'Ketan Talaulikar'
Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; 'Acee Lindem
(acee)' ; 'Albert Fu'
Subject: Re: [Lsr] Working Group Last Call for "OSPF Str
Speaking as WG member:
I support publication of the document. As indicated by the Albert Fu, it has
been implemented by two vendors. I will provide WG Last Call comments when I
prepare the Shepherd’s report.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursda
Hi Albert,
I agree that the draft is ready have started the WG Last Call. It’s great that
we have two implementations.
Thanks,
Acee
From: "Albert Fu (BLOOMBERG/ 120 PARK)"
Reply-To: Albert Fu
Date: Thursday, January 20, 2022 at 9:40 AM
To: "lsr-cha...@ietf.org"
Cc: "ketant.i...@gmail.com" ,
Draft Authors,
Are you aware of any IPR that applies to
draft-ietf-ospf-bfd-strict-mode-04?
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 WG,
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 February 11th,
20222. Also, review comments are certainly welcome.
Thanks,
Acee
___
Lsr mailing list
Speaking as WG Chair and one who rarely wears a hat:
I agree with Chris. There are multiple solutions being proposed and, as one
would expect, the authors of each solution like their own.
Can we agree on the requirement is the topology Peter used as an example with
100 areas each with 1000
All,
I've captured the objection on multiple solutions in the shepherd's report. We
will move forward with this draft on the experimental track.
Thanks,
Acee
On 1/13/22, 2:02 PM, "Acee Lindem (acee)"
wrote:
All,
I think there is some confusion here (at least on my
nce the reachability detection is done in
the IGP.
Speaking as someone who doesn’t want to waste time on needless semantics
discussions,
Acee
Thx,
R.
On Thu, Jan 20, 2022 at 4:01 PM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
Hi Robert,
From: Lsr mailto:lsr-boun...@ietf.org>
Hi Robert,
From: Lsr on behalf of Robert Raszuk
Date: Thursday, January 20, 2022 at 4:59 AM
To: Aijun Wang
Cc: lsr , Tony Li
Subject: Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt
[WAJ] The exact description should be “It proposes to use IGP establishing the
out of
w does the “topology” relate to an IGP domain. Is it separate?
Thanks,
Acee
We will add some description to the draft to address your points.
Thank you.
Linda
From: Acee Lindem (acee)
Sent: Wednesday, January 19, 2022 10:09 AM
To: Linda Dunbar ; Robert Raszuk
; Aijun Wang ;
muthu.a...@gmail.com
Cc
bute-i to the Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Aggregated cost Advertisement in OSPF
Your suggestions and comments are greatly appreciated.
Linda Dunbar
From: Acee Lindem (acee)
Sent: Wednesday, January 19, 2022 7:18 AM
To: Linda Dunbar ; Robert Raszuk
; Aijun Wang
Cc: John E Drake ; Les Ginsberg (ginsberg)
uggestions are greatly appreciated.
Linda
From: Robert Raszuk
Sent: Monday, January 17, 2022 5:29 AM
To: Aijun Wang
Cc: Acee Lindem (acee) ; Linda Dunbar
; John E Drake
; Les Ginsberg (ginsberg)
; Gyan Mishra ; lsr
Subject: Re: [Lsr] Seeking feedback to the revised
draft-dunbar-lsr-5g-ed
101 - 200 of 830 matches
Mail list logo
