Huaimo -
I am not going to comment on the history issues - though I understand why that
is of significance to you.
Otherwise, I don't think you are appreciating the key point many of us are
making - which is that we do not need to introduce a new concept "zone" (subset
of an area).
It is
+1
I think Henk has spoken eloquently here - as have others before him.
Abstracting an area may be useful - the WG has yet to fully decide on that.
But nothing so far has demonstrated that we need to go even further and
abstract a subset of an area.
Les
> -Original Message-
>
Rob -
Thanx for the review.
Responses inline.
> -Original Message-
> From: Robert Wilton via Datatracker
> Sent: Tuesday, July 14, 2020 2:25 AM
> To: The IESG
> Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org;
> Christian Hopps ;
ssues
and allow for non-disruptive introduction of the new functionality
into an existing network."
Let me know if this resolves the concerns.
Les
> -Original Message-
> From: Acee Lindem (acee)
> Sent: Monday, July 13, 2020 9:38 AM
> To: Les Ginsberg (gin
age-
> From: Benjamin Kaduk
> Sent: Monday, July 13, 2020 4:24 PM
> To: Les Ginsberg (ginsberg)
> Cc: The IESG ; draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; Christian Hopps ;
> aretana.i...@gmail.com
> Subject: Re: Benjamin Kaduk's Ye
Ben -
Thanx for your review.
Responses inline.
> -Original Message-
> From: Benjamin Kaduk via Datatracker
> Sent: Monday, July 13, 2020 2:11 PM
> To: The IESG
> Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org;
> Christian Hopps ;
Leif -
Thanx for your review.
Les
> -Original Message-
> From: Leif Johansson via Datatracker
> Sent: Monday, July 13, 2020 1:55 PM
> To: sec...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org;
> draft-ietf-lsr-isis-invalid-tlv@ietf.org
> Subject: Secdir last call review of
Acee -
Inline.
> -Original Message-
> From: Acee Lindem (acee)
> Sent: Monday, July 13, 2020 9:04 AM
> To: Les Ginsberg (ginsberg) ; Roman Danyliw
> ; The IESG
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft-
> ietf-lsr-isis-inva
Roman -
Thanx for the review.
Inline.
> -Original Message-
> From: Lsr On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Monday, July 13, 2020 7:40 AM
> To: The IESG
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft-
> ietf-lsr-isis-invalid-...@ietf.org;
Murray -
Thanx for your review - and for catching the editorial issue.
We will address that in the next revision.
Les
> -Original Message-
> From: Murray Kucherawy via Datatracker
> Sent: Monday, July 13, 2020 12:21 AM
> To: The IESG
> Cc: draft-ietf-lsr-isis-invalid-...@ietf.org;
Codepoints
Registry)
From: Lsr On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, July 08, 2020 11:19 AM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-ietf-lsr-isis-area-proxy-01.txt
Tony –
Inline.
From: Tony Li mailto:tony1ath...@gmail.com
Martin -
Thanx for your review.
Responses inline.
> -Original Message-
> From: Martin Duke via Datatracker
> Sent: Saturday, July 11, 2020 9:08 AM
> To: The IESG
> Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org;
> Christian Hopps ;
Tony –
Inline.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, July 08, 2020 11:12 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-ietf-lsr-isis-area-proxy-01.txt
Hi Les,
Again, the subTLVs of the area proxy TLV
Tony –
Inline.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, July 08, 2020 8:29 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-ietf-lsr-isis-area-proxy-01.txt
Hi Les,
The new definitions in the latest version
Tony –
The new definitions in the latest version in the draft are very close to what
we discussed in the earlier thread – so this looks pretty good to me.
I still have some concerns regarding the Area Segment SID.
You propose to advertise this in two places:
1)As a sub-TLV of the new Area
...
Les
From: Huaimo Chen
Sent: Tuesday, July 07, 2020 12:42 PM
To: Les Ginsberg (ginsberg) ; Christian Hopps
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ
Hi Les,
> I think what you are highlighting is that w TTZ an operator could apply the
> so
should be focusing on things other than the flexibility of zones over areas..
Les
From: Huaimo Chen
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ
Hi Les,
Thank you
Huaimo -
In regards to merging/splitting areas, IS-IS base protocol provides a way to do
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was
first introduced).
So if the major difference/advantage between area-proxy and ttz is the ability
to use zones to handle area
Tony –
Inline.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Monday, June 29, 2020 2:37 PM
To: Les Ginsberg (ginsberg)
Cc: Hannes Gredler ;
draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Comments on Requested Codepoints for
draft-li-lsr-isis-area-proxy
On Behalf Of tony...@tony.li
Sent: Monday, June 29, 2020 12:52 PM
To: Hannes Gredler
Cc: Les Ginsberg (ginsberg) ;
draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Comments on Requested Codepoints for
draft-li-lsr-isis-area-proxy
Hi,
The authors have conferred and we
Alvaro -
Thanx.
V2 of the draft has been posted. I believe it addresses all of your comments.
Les
> -Original Message-
> From: Alvaro Retana
> Sent: Monday, June 22, 2020 3:05 PM
> To: Les Ginsberg (ginsberg) ; draft-ietf-lsr-isis-invalid-
> t...@ietf.org
> Cc: l
I support WG adoption of
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection .
(I also support the WG adoption of
https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ )
I believe the problem space addressed by these two drafts warrants attention.
I am not
I support the WG adoption of
https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ .
(I also support WG adoption of
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection )
I believe the problem space addressed by these two drafts warrants attention.
I am not yet
of the Designated Experts I wanted to share my concerns sooner rather than
later.
A few more responses inline.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Saturday, June 20, 2020 5:13 PM
To: Les Ginsberg (ginsberg)
Cc: draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: Comments
as something attempting to address a similar problem. It isn’t easy.
Les
From: Tony Li On Behalf Of tony...@tony.li
Sent: Saturday, June 20, 2020 1:41 PM
To: Les Ginsberg (ginsberg)
Cc: draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: Comments on Requested Codepoints
(NOTE: Comments below are mine alone - wearing both my WG member hat and my
Designated Expert for IS-IS Registries Hat. They do not represent support for
or against the draft itself.)
draft-li-lsr-isis-area-proxy-06 currently proposes the use of one new sub-TLV
of Router Capabilities TLV
Alvaro -
I will publish an update once we have converged on all your comments.
Responses inline.
> -Original Message-
> From: Alvaro Retana
> Sent: Thursday, June 18, 2020 1:05 PM
> To: draft-ietf-lsr-isis-invalid-...@ietf.org
> Cc: Christian Hopps ; lsr-cha...@ietf.org;
John -
Yes - I like "Application-Specific" better. This matches the term we use
throughout the documents.
Thanx.
Les
From: John E Drake
Sent: Thursday, June 18, 2020 1:37 PM
To: Yingzhen Qu ; Les Ginsberg (ginsberg)
; Les Ginsberg (ginsberg)
; BRUNGARD, DEBORAH A ;
The IES
11:29 PM
To: Les Ginsberg (ginsberg) ; BRUNGARD,
DEBORAH A ; The IESG
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee)
; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14:
(with DISCUSS and COMMENT)
Hi
: Wednesday, June 17, 2020 1:07 PM
To: Les Ginsberg (ginsberg) ; The IESG
Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee
Lindem (acee) ; aretana.i...@gmail.com
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with
DISCUSS and COMMENT)
Les-
To shortcut
draft-ietf-isis-te-app-17 has been posted with this change.
Les
> -Original Message-
> From: Scott O. Bradner
> Sent: Wednesday, June 17, 2020 8:53 AM
> To: Les Ginsberg (ginsberg)
> Cc: Rob Wilton (rwilton) ; Peter Psenak
> ; Benjamin Kaduk
> ; lsr@ietf.org; o
gt; Sent: Wednesday, June 17, 2020 5:09 AM
> To: Peter Psenak ; Les Ginsberg
> (ginsberg)
> Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops-
> d...@ietf.org; last-c...@ietf.org; Scott O. Bradner
> Subject: RE: [Last-Call] Opsdir telechat review of
> dra
Ben -
Inline.
> -Original Message-
> From: Benjamin Kaduk
> Sent: Tuesday, June 16, 2020 7:22 PM
> To: Les Ginsberg (ginsberg)
> Cc: Scott Bradner ; ops-...@ietf.org; draft-ietf-ospf-te-
> link-attr-reuse@ietf.org; lsr@ietf.org; last-c...@ietf.org
> Subject
; From: Benjamin Kaduk
> Sent: Saturday, June 13, 2020 12:03 PM
> To: Les Ginsberg (ginsberg)
> Cc: The IESG ; draft-ietf-isis-te-...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) ;
> aretana.i...@gmail.com
> Subject: Re: Benjamin Kaduk's Discuss on d
t; reuse-14
>
> inline
>
> > On Jun 14, 2020, at 6:50 PM, Les Ginsberg (ginsberg)
> wrote:
> >
> > Scott -
> >
> >
> >
> > Inline.
> >
> >
> >
> > > -----Original Message-
> >
> > > From: Scott O. Brad
Scott -
Inline.
> -Original Message-
> From: Scott O. Bradner
> Sent: Sunday, June 14, 2020 3:16 PM
> To: Les Ginsberg (ginsberg)
> Cc: ops-...@ietf.org; Benjamin Kaduk ; draft-ietf-ospf-te-
> link-attr-reuse@ietf.org; last-c...@ietf.org; lsr@ietf.org
&g
Scott -
Allow me to inject myself here. As editor of the companion IS-IS document
(draft-ietf-isis-te-app) I have received similar comments - for example from
Ben (copied on this thread).
I continue to be at a loss as to why you believe we have to say something about
User Defined Applications
Deborah –
Inline.
From: BRUNGARD, DEBORAH A
Sent: Friday, June 12, 2020 4:16 PM
To: Les Ginsberg (ginsberg) ; The IESG
Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee
Lindem (acee) ; aretana.i...@gmail.com
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis
Ben -
Inline.
> -Original Message-
> From: Benjamin Kaduk
> Sent: Friday, June 12, 2020 9:15 PM
> To: Les Ginsberg (ginsberg)
> Cc: The IESG ; draft-ietf-isis-te-...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) ;
> aretana.i...@gmail.com
&g
ining, to allow for compact encoding. It's
not actually necessary to be strictly sequential in order to minimize the
number of octets transmitted."
LES: I understand this concern. How about if we change policy to "Expert
Review"?
Les
> -Original Message-
> Fr
Ben -
Sorry - there was a typo - correct specification number is ISO 10589.
It is freely available here:
https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
Les
> -Original Message-
> From: Benjamin Kaduk
> Sent: Thursday, June 11, 2020 1:01 PM
> To:
or Section 7.5 there really isn’t anything else to say beyond what RFC 7370
says.
Les
> -Original Message-
> From: Murray S. Kucherawy
> Sent: Thursday, June 11, 2020 11:05 AM
> To: Les Ginsberg (ginsberg)
> Cc: lsr@ietf.org; Martin Duke ; Rob Wilton
> (rwilto
Folks -
This update to the draft addresses comments from the following IESG reviewers:
Murray Kucherawy
Martin Duke
Rob Wilton
Roman Danyliw
Deborah Brungard
Benjamin Kaduk
It also includes grammatical corrections related to the use of "which/that".
A special thank you to Acee Lindem for his
Benjamin -
Thanx for your review.
Responses inline.
> -Original Message-
> From: Benjamin Kaduk via Datatracker
> Sent: Thursday, June 11, 2020 12:42 AM
> To: The IESG
> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee
> Lindem (acee) ;
Deborah -
Thanx for your review.
Responses inline.
> -Original Message-
> From: Deborah Brungard via Datatracker
> Sent: Wednesday, June 10, 2020 3:17 PM
> To: The IESG
> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee
> Lindem (acee) ;
Roman -
Thanx for the review.
Responses inline.
> -Original Message-
> From: Roman Danyliw via Datatracker
> Sent: Wednesday, June 10, 2020 3:05 PM
> To: The IESG
> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee
> Lindem (acee) ;
Rob -
Thanx for your review.
Inline.
> -Original Message-
> From: Robert Wilton via Datatracker
> Sent: Wednesday, June 10, 2020 8:38 AM
> To: The IESG
> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee
> Lindem (acee) ; aretana.i...@gmail.com; Acee Lindem
>
Martin -
From: Martin Duke
Sent: Tuesday, June 09, 2020 2:35 PM
To: Les Ginsberg (ginsberg)
Cc: The IESG ; lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee
Lindem (acee) ; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Martin Duke's No Objection on draft-ietf-isis-te-app-14
Martin -
> -Original Message-
> From: Martin Duke
> Sent: Tuesday, June 09, 2020 9:02 AM
> To: Les Ginsberg (ginsberg)
> Cc: The IESG ; lsr-cha...@ietf.org; aretana.i...@gmail.com;
> Acee Lindem (acee) ; draft-ietf-isis-te-...@ietf.org;
> lsr@ietf.org
> Subject:
Martin -
Thanx for your review.
A new version will be published soon - pending resolution of comments from
another review - that addresses issues you have raised - subject to my
responses inline.
> -Original Message-
> From: Lsr On Behalf Of Martin Duke via Datatracker
> Sent: Monday,
Murray -
Thanx for the review.
Responses inline.
I'll post a new version once we have closed on all your comments.
> -Original Message-
> From: Murray Kucherawy via Datatracker
> Sent: Monday, June 08, 2020 12:30 PM
> To: The IESG
> Cc: draft-ietf-isis-te-...@ietf.org;
Eric -
Thanx for your review.
Please see inline.
> -Original Message-
> From: Éric Vyncke via Datatracker
> Sent: Monday, June 08, 2020 6:06 AM
> To: The IESG
> Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee
> Lindem (acee) ;
Jouni -
Just to let you know that V14 of the draft was posted today and it includes all
of the corrections you requested.
Thanx again for your review.
Les
> -Original Message-
> From: Les Ginsberg (ginsberg)
> Sent: Friday, May 29, 2020 8:02 AM
> To: Jouni Ko
2020 9:33 AM
> To: Les Ginsberg (ginsberg)
> Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org;
> rtg-
> d...@ietf.org
> Subject: RE: Rtgdir last call review of draft-ietf-isis-te-app-13
>
> Les,
>
> Thanks for your answers.
> Comments inl
Folks -
Replying to the WG list on this as we believe this is of interest to the entire
WG.
The designated experts (Chris, Hannes, and myself) have discussed the request
for early codepoint allocations for draft-li-lsr-isis-area-proxy-04.
Ordinarily such requests are routine. Our task is only
Folks -
This is a refresh on this draft.
Les
-Original Message-
From: internet-dra...@ietf.org
Sent: Wednesday, June 03, 2020 6:56 AM
To: Les Ginsberg (ginsberg) ; Stefano Previdi
; Mach Chen (Guoyi) ; Mach Chen
; Xiaodong Duan
Subject: New Version Notification for draft-chen
Jouni -
Thanx for the review.
I have addressed the editorial issues you raised - though I will wait for
additional comments from other reviewers before publishing a new version.
Les
> -Original Message-
> From: Jouni Korhonen via Datatracker
> Sent: Friday, May 29, 2020 6:11 AM
>
FYI -
This versions corrects the codepoint registration policy for the new "IGP
Algorithm Type For Computing Flooding Topology".
Les
> -Original Message-
> From: Lsr On Behalf Of internet-dra...@ietf.org
> Sent: Wednesday, May 27, 2020 10:35 AM
> To: i-d-annou...@ietf.org
> Cc:
Tony/Gyan -
Please find my replies inline.
From: Lsr On Behalf Of tony...@tony.li
Sent: Wednesday, May 20, 2020 8:48 AM
To: Gyan Mishra
Cc: lsr@ietf.org; Huaimo Chen ; Acee Lindem (acee)
Subject: Re: [Lsr] Flooding Topology Computation Algorithm -
draft-cc-lsr-flooding-reduction-08 Working
Kyle –
Inline.
From: Kyle Rose
Sent: Thursday, May 21, 2020 6:09 AM
To: Les Ginsberg (ginsberg)
Cc: tsv-...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org;
last-c...@ietf.org
Subject: Re: Tsvart last call review of draft-ietf-isis-te-app-13
On Thu, May 21, 2020 at 2:28 AM Les
Kyle -
Thanx for the review.
Responses inline.
> -Original Message-
> From: Kyle Rose via Datatracker
> Sent: Wednesday, May 20, 2020 4:15 PM
> To: tsv-...@ietf.org
> Cc: draft-ietf-isis-te-app@ietf.org; lsr@ietf.org; last-c...@ietf.org
> Subject: Tsvart last call review of
Warren –
The problem I have with your suggestion is that we do not know whether the
destination protocol for redistribution even supports the signaling.
I am very supportive of Acee’s characterization of redistribution as outside
the scope of specification.
I think we can say what happens
Elwyn’s comment was:
I was trying to understand
why a router that satisfies the previous condition so that it is
legitimate for it to announce ELC with any IP address prefix might wish
to only announce it with some prefixes and not others.
The answer to that is clearly stated in the draft
cur if all nodes supported a consistent flooding rate.
Do not read anything else into this.
Les
> -Original Message-
> From: Joel M. Halpern
> Sent: Wednesday, May 06, 2020 11:19 AM
> To: Les Ginsberg (ginsberg)
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Flooding across
faster flooding
2)Disable fast flooding
3)Redesign your network
Les
> -Original Message-
> From: bruno.decra...@orange.com
> Sent: Wednesday, May 06, 2020 10:10 AM
> To: Christian Hopps
> Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
> Subject: RE: [Lsr] Floodin
no.decra...@orange.com
> Cc: Christian Hopps ; Les Ginsberg (ginsberg)
> ; lsr@ietf.org
> Subject: Re: [Lsr] Flooding across a network
>
> Bruno persistence has made me realize something fundamental here.
>
> The minute the LSP originator changes the LSP and floods it you have
with consistent flooding rates - but
they will be an order of magnitude shorter (a few seconds vs 50 seconds in the
example).
Les
From: Lsr On Behalf Of bruno.decra...@orange.com
Sent: Wednesday, May 06, 2020 7:33 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flooding
: Wednesday, May 06, 2020 6:21 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: RE: Flooding across a network
Les,
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, May 6, 2020 1:35 AM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org<mailto:lsr@ietf.org>
Subje
2020 8:28 AM
> To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> Subject: Flooding across a network
>
> Les,
>
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg
> (ginsberg)
> > Sent: Monday, May 4, 2020 4:39 PM
> [...]
> > when only s
Henk -
Thanx for your thoughtful posts.
I have read your later posts on this thread as well - but decided to reply to
this one.
Top posting for better readability.
There is broad agreement that faster flooding is desirable.
There are now two proposals as to how to address the issue - neither of
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed
Les,
After nearly 2 months, can we expect an answer from your side?
More specifically, the below question
[Bruno] _Assuming_ that the parameters are static, the parameters proposed in
draft
acknowledgements.
Les
From: bruno.decra...@orange.com
Sent: Wednesday, February 26, 2020 11:03 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed
Les,
Please see inline[Bruno]
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les
Folks -
A new version of this draft has been uploaded.
Comments welcomed.
Les
-Original Message-
From: internet-dra...@ietf.org
Sent: Friday, April 17, 2020 12:49 PM
To: Tony Przygienda ; Acee Lindem (acee) ;
Peter Psenak (ppsenak) ; Les Ginsberg (ginsberg)
Subject: New Version
This discussion is interesting, but please do not ignore the considerable
feedback from multiple folks indicating that this advertisement does not belong
in the IGP at all (regardless of scope).
My opinion on that has not changed.
Thanx.
Les
From: Lsr On Behalf Of Tianran Zhou
Sent:
; To: Robert Raszuk
> Cc: Christian Hopps ; Les Ginsberg (ginsberg)
> ; wangyali ; Acee Lindem
> (acee) ; lsr@ietf.org; Tianran Zhou
>
> Subject: Re: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02
>
> We have defined a perfectly acceptabl
at
you need is most likely more attractive - but I will leave that for you to
decide.
Using IGP Router Capabilities here is wrong in my view.
Les
> -Original Message-
> From: wangyali
> Sent: Wednesday, April 01, 2020 8:12 PM
> To: Acee Lindem (acee) ; Les Ginsberg (gin
age-
> From: Tianran Zhou
> Sent: Tuesday, March 31, 2020 7:53 PM
> To: Christian Hopps
> Cc: wangyali ; Les Ginsberg (ginsberg)
> ; lsr@ietf.org
> Subject: RE: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02
>
> Hi Chris,
> Thanks for
Jie -
Once again, inline.
> -Original Message-
> From: Dongjie (Jimmy)
> Sent: Tuesday, March 31, 2020 8:38 AM
> To: Les Ginsberg (ginsberg) ; Peter Psenak
> ; xie...@chinatelecom.cn; lsr
>
> Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Ro
Jie -
Inline.
> -Original Message-
> From: Dongjie (Jimmy)
> Sent: Monday, March 30, 2020 3:04 AM
> To: Les Ginsberg (ginsberg) ; Peter Psenak
> ; xie...@chinatelecom.cn; lsr
>
> Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
> V
ch 29, 2020 9:57 PM
> To: Les Ginsberg (ginsberg) ; Peter Psenak
> ; xie...@chinatelecom.cn; lsr
>
> Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
> Virtual Transport Network
>
> Hi Les,
>
> Many thanks for providing the history about
ghbor Descriptor".
Les
> -Original Message-
> From: Lsr On Behalf Of Aijun Wang
> Sent: Sunday, March 29, 2020 3:46 AM
> To: Peter Psenak
> Cc: peng.sha...@zte.com.cn; Dongjie (Jimmy) ;
> xie...@chinatelecom.cn; Les Ginsberg (ginsberg)
> ; lsr@ietf.org; Tony Pr
Descriptor” – which includes the system-id/pseudo-node ID of the neighbor and
(in the case of parallel links to the same neighbor) link endpoint identifiers.
Les
From: Tony Przygienda
Sent: Saturday, March 28, 2020 5:56 PM
To: Les Ginsberg (ginsberg)
Cc: peng.sha...@zte.com.cn; xie
Tony –
There are a few misunderstandings in your post.
Let me try to correct them.
RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of TLVs
22,23,141,222,223.
Conceptually, it could have been defined as a sub-TLV, but because of the
limited length of a TLV in IS-IS (255
Peng –
Thanx for calling attention to your relatively new draft.
The new sub-TLV you propose in
https://tools.ietf.org/html/draft-peng-lsr-flex-algo-l2bundles-00#section-5.1
is unnecessary.
You seem to have misunderstood RFC 8668 and believe that it does not allow
advertising link attributes
Jie -
The registry clearly indicates the set of specifications - and does so on a per
sub-TLV basis - though not on a per column basis.
The registry is authoritative.
There is a bit of history here.
Prior to RFC7370 there wasn't a single registry for all the related TLVs. This
became awkward
Trying to avoid piling on...but Peter is certainly correct that there is
nothing in this draft that is normative.
This may provide useful context for the protocol extensions defined in
https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/. As such the
content would be better
Alvaro -
Following some offline discussion with you, V12 of the draft has been posted to
address your additional comments.
Some responses inline. Look for "Les3".
> -Original Message-
> From: Alvaro Retana
> Sent: Thursday, March 05, 2020 8:54 AM
> To: Les Gins
Chris -
>
> Do you think we should get rid of the "used in" columns in the IS-IS TLV and
> sub-TLV registries? The documents that define those TLVs and sub-TLVs
> already indicate which PDUs and TLVs they go in, so why do we need that
> info in the registry?
>
[Les:] The difference for me is
Chris/Acee -
I strongly agree with Peter.
There is no point in creating a protocol specific registry for behavior values
which are protocol agnostic.
This only adds duplication (which is NOT the same as redundancy ).
What I find unfortunate is that the table in Section 10 of
Yali -
What is missing for me is an explanation of why IFIT Capability information is
something that is appropriate to be sent using IGP Router Capability
advertisements.
Generally speaking, we prefer to restrict IGP advertisements to information
which is of direct use to the protocol.
Alvaro -
Thanx for the continued review.
V11 of the draft has been posted to address your additional comments.
More inline.
> -Original Message-
> From: Alvaro Retana
> Sent: Tuesday, February 25, 2020 4:42 AM
> To: Les Ginsberg (ginsberg) ; draft-ietf-isis-te-
> a..
...@orange.com
Sent: Wednesday, February 26, 2020 10:34 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: RE: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
Les,
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 6:49 PM
Przygienda
Sent: Wednesday, February 19, 2020 11:25 AM
To: Les Ginsberg (ginsberg)
Cc: Peter Psenak (ppsenak) ; Tony Li
; lsr@ietf.org; tony...@tony.li
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
Having worked for last couple of years on implementation of flooding speeds
you intend but have yet to state.
Inline.
> -Original Message-
> From: Tony Li On Behalf Of tony...@tony.li
> Sent: Wednesday, February 19, 2020 11:29 AM
> To: Les Ginsberg (ginsberg)
> Cc: Peter Psenak (ppsenak) ; lsr@ietf.org
> Subject: Re: [Lsr] Flow Control Discuss
of improvements, deployment has to be done
carefully. I suppose this argues for more discussion of deployment
considerations.
Added to the list…
Les
From: Robert Raszuk
Sent: Wednesday, February 19, 2020 10:55 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flow Control
concerning.
Les
> -Original Message-
> From: Peter Psenak
> Sent: Wednesday, February 19, 2020 2:49 AM
> To: Tony Li
> Cc: Les Ginsberg (ginsberg) ; tony...@tony.li;
> lsr@ietf.org
> Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
> To
as a bottleneck.
If your concern is that we need to emphasize the importance of sending timely
ACKs, I think we could look at text that makes that point.
Les
From: Lsr On Behalf Of Robert Raszuk
Sent: Wednesday, February 19, 2020 1:07 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject
if you wrote up the details of the RX side
solution.
Thanx.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Tuesday, February 18, 2020 10:43 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
Les,
Then the LSP transmitter
Tony -
From: Tony Li On Behalf Of tony...@tony.li
Sent: Tuesday, February 18, 2020 10:16 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
The TX side flow control is purely based on performance on each interface
–
there are no implementation requirements imposed or implied as regards the
receiver.
Les
From: Tony Li
Sent: Tuesday, February 18, 2020 7:10 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
https://datatracker.ietf.org/doc/draft
501 - 600 of 814 matches
Mail list logo
