Hi Uma,
There was a discussion on this topic. I think this was agreed during Chicago's
IETF if I remember correctly.
The outcome of the discussion was that if an implementation is able to read N
labels, this does not mean that it is actually able to hash based on these N
labels. So we needed
I’m not aware of any IPR
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, August 30, 2019 21:10
To: draft-ietf-ospf-mpls-...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Poll for "Signaling Entropy Label Capability and Entropy Readable
Label-stack Depth Using OSPF" -
I’m not aware of any IPR
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, August 30, 2019 21:11
To: draft-ietf-isis-mpls-...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Poll for "Signaling Entropy Label Capability and Entropy Readable
Label Depth Using IS-IS" -
I'm not aware of any IPR related to this document.
-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org]
Sent: Monday, July 29, 2019 19:22
To: lsr@ietf.org
Cc: Christian Hopps; lsr-cha...@ietf.org; lsr-...@ietf.org;
draft-ietf-isis-yang-isis-...@ietf.org
Subject: WGLC:
Les,
Can’t we use from a transmitter point of view, the lack of ACKs from the
receiver as a signal that the transmitter should slow down ?
I agree that depending on the exact bottleneck/issue, the IS-IS stack of the
receiver may not be aware that something bad is happening and can’t provide
Hi Les,
I agree that flooding is a global thing and not a local mechanism if we
consider that the ultimate goal is to get the LSDB in-sync as fast as we can on
all the nodes.
I just want to highlight three things:
- Link delay (due to transmission link distance) is already affecting
Hi Alvaro,
Thanks for your comments. We are working on updating the document accordingly.
Please find some replies inline that may require more discussion.
I have stripped the comments that will be fixed in the next revision.
Brgds,
From: Alvaro Retana [mailto:aretana.i...@gmail.com]
Sent:
Support
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, June 12, 2019 14:05
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps;
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Subject: [Lsr] WG Adoption Call:
Hi Xufeng,
Good catch, I think there is a mistake here, the expected behavior is the one
described in the draft. We should not use a default value for the level-x
leaves.
Will fix it in the next release as part of the AD review.
Brgds,
Stephane
From: Lsr [mailto:lsr-boun...@ietf.org] On
Hi Tom,
Thanks for your feedback.
Pls find some comments inline
Stephane
-Original Message-
From: tom petch [mailto:ie...@btconnect.com]
Sent: Thursday, June 06, 2019 18:59
To: LITKOWSKI Stephane OBS/OINIS
Cc: lsr@ietf.org
Subject: Re: I-D Action: draft-ietf-isis-yang-isis-cfg-35.txt
Hi,
On one hand, I'm a bit worried about having too many tiny modules (finding the
right module name to get the right feature, managing prefixes...). The good
thing I see is that we could mandate in each LSR draft the YANG management part
so both are published at the same time. While YANG is
I’m not aware of any IPR
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Saturday, January 12, 2019 23:21
To: draft-ietf-isis-yang-isis-...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call for "YANG Data Model for IS-IS protocol" -
draft-ietf-isis-yang-isis-cfg-29
Authors,
Are you aware of
Ok, so if we are silent about "must support at least", I think the only thing
to do is to have 'type string "1.."' to avoid empty string as I don't see any
requirement to have a minimum of x characters.
-Original Message-
From: Juergen Schoenwaelder
Hi Juergen,
There is something that I'm missing (sorry for that). How defining a minimum
length helps to deal with rogue input ? I see a rogue input more being a too
long string. Too short can happen if a specific leaf really requires a minimum
length string, but I don't think that we have
Hi Tom,
Regarding the length enforcement for operational state leaves that are using
string, do we need to always do it as a best practice ? There are plenty of
strings with no enforcement today like the "non-best-reason" that you have
pointed.
Brgds,
-Original Message-
From: tom
Hi Tom,
Thanks for your comments.
I wish you an happy new year !
Please find inline comments.
Brgds,
-Original Message-
From: tom petch [mailto:ie...@btconnect.com]
Sent: Wednesday, January 02, 2019 12:17
To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
Cc:
Acee and co-authors,
The last version of the model has a compilation failed status in the YANG
catalog.
https://yangcatalog.org/results/ietf-ospf@2018-11-27_ietf.html
Could you check what’s going on ?
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of
stephane.litkow...@orange.com
Sent:
Hi Acee,
I’m fine with that.
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, December 07, 2018 18:03
To: LITKOWSKI Stephane OBS/OINIS; lsr@ietf.org; draft-ietf-ospf-y...@ietf.org
Subject: Re: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Hi Stephane,
I’ve added
Hi Tom,
I think that having a different router-id configured per protocol is a matter
of deployment. I don't think that we can impose anything in this area. There
are use cases where it is good to have separate router-ids per protocol or
instances of a protocol. For instance, when a router is
Hi Acee,
In IS-IS some of the defaults we are using a coming from the ISO spec and some
from vendor implementations (common used values). At the beginning we had no
default in IS-IS, and during a review, there was a request to add defaults. I
cannot remember who did this request.
From: Acee
Hi Acee,
For the default values, some examples where I was expecting defaults:
hello-interval, dead-interval, retransmit-interval, transmit-delay, passive,
priority, cost…
Another comment, in the last version of the IS-IS model, I have catched up all
the existing IS-IS extensions in the LSDB
Hi Tom,
Thanks for your comments. I will fix them asap.
Regarding:
" Line length is within the RFC limit but the effect is to spread many of the
description clauses over multiple lines with indentation of 56 characters, not
user friendly e.g.
description
Hi,
Here are some comments I have on the model:
· The model should use the LSR WG as point of contact and no more the
OSPF WG
· In the feature multi-topology: s/-Topolgy/-Topology
· In the packet-type typedef:
s/database-descripton/database-description.
· In
As mentioned, you could not be aware of all the constraints that we have and
BGP 3107 is not an option.
Note that this kind of redistribution can even happen within a single AS. We
had some OSPF domain prefixes leaked in the ISIS L2 in the past in a single AS.
Nothing prevents this design to
We can’t for some internal design/security reasons.
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of ???(??)
Sent: Tuesday, November 20, 2018 09:10
To: spring; Lsr; lsr@ietf.org
Cc: spr...@ietf.org
Subject: Re: [Lsr] [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Why not
Hi all,
The use case is without TE. And this is how network designs are working today,
and I do not see any valid reason to complexify and change the existing designs
by introducing controllers or BGP-LS.
We have to accommodate with what is deployed today and the proposed change is
quite
Hi WG,
Some discussions occurred on the mailing list on how to encode the entropy
label capability for SR but we hadn't found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have
participated to this discussion.
Following this
Hi,
As defined in draft-ietf-mpls-spring-entropy-label, advertising an ERLD means
that the node is defacto ELC (so advertising ELC separately is not necessary):
" The Entropy Readable Label Depth (ERLD) is defined as the number of
labels a router can both:
a. Read in an MPLS packet
I’m not aware of non-disclosed IPR.
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Uma Chunduri
Sent: Monday, June 11, 2018 21:18
To: lsr@ietf.org
Subject: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16
(Shepherd write-up)
Dear All,
Are you aware of any IPR that applies
29 matches
Mail list logo
