Les
From: Tony Przygienda
Sent: Wednesday, December 8, 2021 5:27 AM
To: Les Ginsberg (ginsberg)
Cc: Tony Li ; lsr@ietf.org; Acee Lindem (acee)
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS
Les, all sounds to me unfortunately like a gripe (and a late one @ that now
that things
And I meant to add that IS-IS already fully supports using L1 for transit –
these solutions just make it work better.
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, December 9, 2021 at 4:59 PM
To: "Les Ginsberg (ginsberg)" , Tony Przygienda
Cc: &quo
r_sha...@comcast.com" ,
"yiu_...@comcast.com"
Subject: Re: [Lsr] IPR Poll for "IS-IS Flood Reflection"
-draft-ietf-lsr-isis-flood-reflection-05 (WG Last Call Iteration) (Correct
Email Address)
I don’t know of any IPR on this one.
/r
From: "Acee Lindem (acee)"
;Acee Lindem (acee)"
Date: Monday, November 22, 2021 at 9:12 AM
To: "lsr@ietf.org"
Subject: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" -
draft-decraeneginsberg-lsr-isis-fast-flooding-00
We indicated the intent to adopt of
draft-decraeneginsberg-lsr-isis-fast-flo
Hi Les,
From: Lsr on behalf of "Les Ginsberg (ginsberg)"
Date: Tuesday, December 7, 2021 at 1:17 PM
To: "Acee Lindem (acee)" , "lsr@ietf.org"
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection"
-draft-ietf-lsr-isis-flood-reflectio
Cc: "lsr@ietf.org"
Subject: Re: IPR Poll for "IS-IS Fast Flooding" -
draft-decraeneginsberg-lsr-isis-fast-flooding-00
Not aware of any undisclosed IPR
From: "Marek Karasek (mkarasek)"
Date: Tuesday, 30 November 2021 at 17:24
To: "Acee Lindem (acee)"
I’m missing IPR declarations from Russ, Yui, and Alankar.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Monday, November 22, 2021 at 2:52 PM
To: "draft-ietf-lsr-isis-flood-reflect...@ietf.org"
Cc: "lsr@ietf.org"
Subject: [Lsr] IPR Poll for &q
I’m missing IPR declarations from Russ, Yui, and Alankar.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Monday, November 22, 2021 at 2:52 PM
To: "draft-ietf-lsr-isis-flood-reflect...@ietf.org"
Cc: "lsr@ietf.org"
Subject: [Lsr] IPR Poll for &q
Hi Alankar,
Please reply to this IPR poll now that we have your correct contact information.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Monday, November 22, 2021 at 2:52 PM
To: "draft-ietf-lsr-isis-flood-reflect...@ietf.org"
Cc: "lsr@ietf.org&
ly be solved by “sending alarm and declare misconfiguration).
Then, why it is ready to WG Last Call?
Aijun Wang
China Telecom
On Dec 8, 2021, at 06:28, Acee Lindem (acee)
wrote:
Hi Les,
From: "Les Ginsberg (ginsberg)"
Date: Tuesday, December 7, 2021 at 5:10 PM
To: "Acee
Speaking as WG Co-Chair:
While not mandatory for advancement, I’d really like for some the long-time
IS-IS contributors to review the draft. You know who you are…
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Monday, November 22, 2021 at 2:48 PM
To: "lsr@iet
Speaking as WG member:
I agree with Les. The Generic Metric MUST be advertised as an ASLA for usage in
Flex Algorithm. Additionally, it may be advertised as a sub-TLV in IS-IS link
TLVs. However, the latter encoding really shouldn't be used for new
applications (at least that is my reading of
This begins a 3-week WG Last Call, ending on August 4th, 2021, for
draft-ietf-lsr-pce-discovery-security-support. Please indicate your support or
objection to this list before the end of the WG last call. The longer WG last
call is to account for IETF week.
The following IPR has been filed for
draft-ietf-lsr-pce-discovery-security-support:
https://datatracker.ietf.org/ipr/3351/
Are you aware of any other IPR that applies to
draft-ietf-lsr-pce-discovery-security-support?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see
Note that all draft authors must explicitly respond to the IPR poll…
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Wednesday, July 21, 2021 at 12:38 PM
To: "draft-ietf-lsr-pce-discovery-security-supp...@ietf.org"
Cc: "lsr@ietf.org"
Subjec
this document is
published the capability bits and sub-TLVs are not longer “new”.
See full set of editorial comments in attached RFC diff.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Wednesday, July 21, 2021 at 12:46 PM
To: "lsr@ietf.org"
Cc: "dra
Speaking as WG member:
Hi Tony,
Thank you for starting this discussion. I’ve reviewed the draft and have a few
comments and questions.
1. I think the concept of a flood reflection cluster should be defined
earlier in the document
as opposed to being introduced in the TLV description. It
I support LSR WG adoption of both drafts.
As an author of draft-hu-lsr-ospf-srv6-yang, I'm not aware of any IPR.
Thanks,
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:
ee
Just some questions … as this seemed something new to me and the spec does not
provide any pointers.
Thanks,
Ketan
From: Acee Lindem (acee)
Sent: 23 July 2021 18:52
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Cc: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; p...@ietf.org
Sub
ing TLS that updates RFC5440 but nothing that introduces TCP-AO?. In
any case, these are aspects for PCE WG so I will leave those to the experts
there.
Thanks,
Ketan
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: 21 July 2021 22:16
To: lsr@ietf.org
Cc: draft-ietf-lsr-pce-discovery-security-supp
,
141, 222, and 223
Juniper Business Use Only
-Original Message-
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Tuesday, July 20, 2021 1:21 PM
To: Les Ginsberg (ginsberg) ; Shraddha
Hegde ; gregory.mir...@ztetx.com;
ppsenak=40cisco@dmarc.ietf.org;
I'm not aware of any IPR.
Thanks,
Acee
On 1/4/22, 2:04 AM, "Christian Hopps" wrote:
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
Please indicate your support or objections by
Speaking as WG member:
From a 10,000 foot view, flex algorithm is the right place to introduce new
metrics as it assures uniform treatment of these metrics within the IGP domain
(only routers understanding the metrics are included in the SPT).
What is being debated here is the issue of whether
Furthermore, I can't understand why there is so much reluctance to provide
technical review and comment on the draft.
Thanks,
Acee
On 1/13/22, 10:06 AM, "Lsr on behalf of Acee Lindem (acee)"
wrote:
Hi Chris,
Actually, we have progressed multiple experimental OSPF MANET d
we have
stable references to talk about ...
thanks
-- tony
On Mon, Jan 10, 2022 at 6:05 PM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
I'll defer to Tony but my understanding is that there could be suboptimal paths
if there are both Level-1 and Level-2 paths but not loops.
Thanks,
Acee
On
acker.ietf.org/doc/draft-ietf-lsr-isis-ttz/
> - but as that draft continues to promote its primary usage as a
> means of more easily changing area boundaries (merging/splitting)
> I have not discussed it here. However, if the authors of that
> draft cl
Hi Aijun, Linda,
Independent of the ongoing debate on whether advertising the server metrics in
the IGPs…
Now that the draft is simplified to use a single aggregated metric, why not
make the draft informational and use the base IGP metrics? This avoid the
burden of adding a new flex algorithm.
.
Thank you.
Linda
From: Acee Lindem (acee)
Sent: Saturday, January 15, 2022 5:30 AM
To: Aijun Wang ; John E Drake
Cc: Les Ginsberg (ginsberg) ; Linda Dunbar
; Gyan Mishra ; Robert
Raszuk ; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised
draft-dunbar-lsr-5g-edge-comp
m, current flood reflection draft hasn’t, the operator must design the
topology/link metric carefully to avoid the possible loop.
Aijun Wang
China Telecom
> On Jan 11, 2022, at 00:10, Acee Lindem (acee)
wrote:
>
> Speaking as a WG member, these documents are all &quo
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
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
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...@
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
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
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
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
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
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
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
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:
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/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
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
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
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" -
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 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
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
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
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
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" ,
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 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 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
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.
://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
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>>
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
The way I read this is that other applications could use the generic IGP pulse
mechanism as opposed to other applications using the route unreachable signals
conveyed using the IGP pulse mechanism.
Thanks,
Acee
From: Lsr on behalf of Robert Raszuk
Date: Thursday, January 6, 2022 at 6:54 AM
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
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
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)
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
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>
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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, "
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
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)"
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
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
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
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
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
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
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
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
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
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
601 - 700 of 830 matches
Mail list logo
