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
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 recei
Hi,
Thanks for your comment.
Pls find some inline replies
Brgds,
Stephane
From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of ???(??)
Sent: Thursday, July 05, 2018 05:34
To: m...@ietf.org
Cc: lsr@ietf.org; p...@ietf.org
Subject: [mpls] Comments on draft-ietf-mpls-spring-entropy-label
Hi all
[Xiaohu] Yes there is no need for them to advertise the ELC. However, there is
a need for them to advertise the capability of reading the maximum label stack
depth and performing EL-based load-balancing, if I understood it correctly.
IMHO, it seems better that the ELC and the ERLD are defined as
Hi,
Hi Les, Bruno,
[Bruno] I also raised the case of redistribution of IP prefix/SID between IGP
domains. Possibly one using OSPF and one using IS-IS. This case needs to be
also covered.
[Les:] If a prefix is leaked between protocols then you lose the identification
of the source. Which mean
Hi Ebben,
Thanks for your review, I'm currently fixing the draft and the model to address
your comments.
-Original Message-
From: Ebben Aries [mailto:e...@juniper.net]
Sent: Tuesday, October 23, 2018 02:46
To: yang-doct...@ietf.org
Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ie
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 discussion
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 simple
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 directl
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 com
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 t
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 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 d
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 L
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 p
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
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: Mo
Hi Tom,
The IS-IS extension for the Interface Switching Capability descriptor is
defined in RFC5307 and this is what the model describes. And the
neighbor-gmpls-extensions grouping contains all the extensions defined in
RFC5307.
What could make sense regarding RFC7074, would be to modify the de
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: draft-ie
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 pet
Hi Tom,
Please find inline answers.
-Original Message-
From: tom petch [mailto:ie...@btconnect.com]
Sent: Tuesday, January 08, 2019 18:45
To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
Subject: Re: [Lsr]
Hi Tom,
If you agree, I will set a length restriction on each string (ops and cfg). It
looks clearer for me rather than setting it in the description.
For the references, I'm working on it.
Brgds,
-Original Message-
From: tom petch [mailto:ie...@btconnect.com]
Sent: Wednesday, Januar
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 such
Regarding "prefix" and "alternate", these should not be using a string. I have
fixed this to respectively inet:ip-prefix and inet:ip-address.
-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: Wednesday, January 09, 2019 14:09
To: LITKOWSK
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 [mailto:j.schoenwael...@jacobs-univer
Hi Andy,
What I’m still not catching is the difference you make between having a
description statement telling :” A server MUST accept a string up to 64
characters in length” and a type string with length “0..64” ?
There is probably something that I’m missing here.
Brgds,
From: Andy Bierman [m
So, would the nicer solution being to create a very short draft to implement
this admin string for IETF YANG models ?
-Original Message-
From: tom petch [mailto:ie...@btconnect.com]
Sent: Friday, January 11, 2019 13:39
To: Andy Bierman; Acee Lindem (acee)
Cc: LITKOWSKI Stephane OBS/OINIS
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 an
Hi Yinghzen,
I have published the -31 which should fix the nits.
However the weird spacing is introduced by XML2RFC and is not coming from my
source file.
From: Yingzhen Qu [mailto:yingzhen...@huawei.com]
Sent: Friday, January 18, 2019 23:35
To: lsr@ietf.org; draft-ietf-isis-yang-isis-...@ietf.
Hi Tom,
This is plaintext. You can see it in the XML source of the draft, there is no
link in the YANG module.
Is your concern coming from the "[" "]" characters ? Just a copy/paste from the
text version of the boilerplate, but there is no link behind.
-Original Message-
From: Lsr [mai
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 ea
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
S
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 Beha
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: d
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: Tues
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
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
fee
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: draf
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" - draft-ietf-isis-mpls-elc-0
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" - draft-ietf-ospf-mpls-
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 so
41 matches
Mail list logo
