e protocol.
Les
From: Lsr On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, February 18, 2020 6:25 PM
To: lsr@ietf.org
Subject: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
Two recent drafts advocate for the use of faster LSP flooding speeds in IS-IS:
https://datatracker.ietf.org
Two recent drafts advocate for the use of faster LSP flooding speeds in IS-IS:
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/
There is strong agreement on two key points:
1)Modern networks require
Alvaro -
Thanx for your patience.
We have published V10 of the draft addressing your comments.
Note that the authors of the IS-IS and OSPF drafts are "synchronizing" as there
is a lot of similarity in your comments regarding the two drafts. We have
decided to close all issues with you for the
Chris –
Regarding
Section 3.3 of RFC 8402 has similar text: "Within an anycast group, all routers
in an SR domain MUST advertise the same prefix with the same SID value." T
The text in RFC 8402 is SR MPLS specific. As an SRv6 SID is an IPv6 address
there is no possibility of such an
ocator.
It is a mistake to think that these flags are associated with a SID.
Does this help?
Les
From: Lsr On Behalf Of Chris Bowers
Sent: Friday, January 31, 2020 12:11 PM
To: Peter Psenak (ppsenak) ; Les Ginsberg (ginsberg)
Cc: lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ; Acee
Chris –
I will let the authors of isis-srv6-extensions reply to the bulk of your
suggestion.
But as an author of RFC 7794, I do have some concerns.
Please see inline.
From: Lsr On Behalf Of Chris Bowers
Sent: Wednesday, January 29, 2020 8:25 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian
2020 9:19 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem (acee)
Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
Les,
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, January 24, 2020 5:39 PM
To: DECRAEN
I support adopting this draft.
Les
> -Original Message-
> From: Lsr On Behalf Of Christian Hopps
> Sent: Thursday, January 23, 2020 12:25 PM
> To: lsr@ietf.org
> Cc: draft-li-lsr-ospfv3-srv6-extensi...@ietf.org; lsr-...@ietf.org; Christian
> Hopps ; Acee Lindem (acee)
> Subject:
I support progressing this draft.
Les
> -Original Message-
> From: Lsr On Behalf Of Christian Hopps
> Sent: Tuesday, January 21, 2020 4:15 PM
> To: lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem
> (acee)
> Subject: [Lsr] WG Last Call
Bruno -
Regarding
§8.2
"System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined in
[ISO10589]. »
The field seems of fixed length (6 octets) while the encoded System ID seems to
be of a variable length. If so, wouldn't it be useful to indicate how a System
ID of a length
depending on which of the other
sub-TLVs are present/not present i.e., it is the only way of preserving the ID
of the originator of the advertisement when the prefix is leaked into another
level.
Les
From: Xiejingrong (Jingrong)
Sent: Thursday, January 16, 2020 2:58 AM
To: Les Ginsberg (ginsberg
Alvaro -
A few pointed questions as we work on the revisions.
>
> (A) Deployment Considerations
>
> This document contains what I would characterize as a "distributed"
> Deployment Considerations section through §5, §6 and §7. There is a
> lot of content, but I still made some comments
Folks -
Just a refresh as the draft was about to expire.
Les
> -Original Message-
> From: Lsr On Behalf Of internet-dra...@ietf.org
> Sent: Wednesday, January 15, 2020 7:45 AM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action:
that identifies an interface type isn’t
sufficient to do anything useful IMO.
Les
From: Acee Lindem (acee)
Sent: Monday, January 13, 2020 8:03 AM
To: tony...@tony.li; Aijun Wang
Cc: Les Ginsberg (ginsberg) ; Robert Raszuk
; lsr@ietf.org
Subject: Re: [Lsr] Methods to label the passive interfaces
Alvaro -
Happy New Year to you!
Thanx for the extensive review of this draft and
draft-ietf-ospf-te-link-attr-reuse-10.
It is clear that you spent a good deal of time on this and covered a lot of
ground - much appreciated.
We are working on addressing your comments - but it will take us a
to be some larger consensus before Option #2 could be considered.
Does this seem like a fair summary of options?
Les
> -Original Message-
> From: Philip Christian
> Sent: Wednesday, January 08, 2020 11:08 AM
> To: tony...@tony.li
> Cc: lsr@ietf.org; Les Ginsberg (gi
.
If you are talking specifically about IIH PDUs, note that IIHs are never sent
on passive interfaces.
But it is hard to comment on an idea that you have yet to publish.
Les
From: Aijun Wang
Sent: Monday, January 06, 2020 12:14 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: 答复: [Lsr
the intent
of this draft.
Thanx.
Les
From: Aijun Wang
Sent: Sunday, January 05, 2020 7:20 PM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
; lsr@ietf.org
Cc: lsr-...@ietf.org; 'Antoni Przygienda'
Subject: 答复: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv
Hi, Les:
The questions
Aijun -
Regarding the number of levels, Tony responded to a similar comment several
months ago - please see
https://mailarchive.ietf.org/arch/msg/lsr/dKJBcU59TNuY3rxgjd6iXIq6sYg
> It seems not necessary to have 8 levels of hierarchies. 3 or at most 4 levels
> of hierarchies should be enough.
Aijun –
Please read Section 3.2 of the draft which discusses these issues.
Thanx.
Les
From: Aijun Wang
Sent: Sunday, January 05, 2020 6:04 PM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
; lsr@ietf.org
Cc: lsr-...@ietf.org; 'Antoni Przygienda'
Subject: 答复: [Lsr] 答复: WG Last Call draft
Aijun -
Since advertising some sort of capability would also be unusable until all
routers were upgraded to understand the new capability advertisement this does
not help.
The consequences of enabling a form of authentication which is not supported by
all nodes is an inconsistent LSPDB
As co-author, I obviously support moving the draft forward.
The impetus for writing the draft was a real world interoperability problem -
so there should be no debate about whether the draft is needed.
All parties involved in the problem have actively participated in writing the
draft - so I
I support adoption of this draft.
Although many implementations have added strict mode support based only on
local configuration, given that the adjacency state machine is altered it
seems long overdue that protocol extensions be defined so there is more robust
interoperability.
Les
>
I support adoption of this draft.
Similar functionality in IS-IS (RFC 8500) has proven useful.
Les
> -Original Message-
> From: Lsr On Behalf Of Christian Hopps
> Sent: Friday, December 13, 2019 3:28 AM
> To: lsr@ietf.org
> Cc: draft-ketant-lsr-ospf-reverse-met...@ietf.org;
I support adoption of this necessary work.
Les
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Monday, November 25, 2019 4:27 AM
To: lsr@ietf.org
Cc: Christian Hopps
Subject: [Lsr] "YANG Module for IS-IS Reverse Metric" -
draft-hopps-lsr-yang-isis-reverse-metric-02
This begins a two week
Qin -
Thanx for addressing my comments - and for the update regarding PCE WG position.
The new version looks good to me.
Les
> -Original Message-
> From: Lsr On Behalf Of Qin Wu
> Sent: Thursday, October 31, 2019 11:26 PM
> To: lsr@ietf.org
> Subject: Re: [Lsr] I-D Action:
Folks -
We noticed an inconsistency between this draft and
draft-ietf-ospf-te-link-attr-reuse.
The OSPF draft treated both Maximum Reservable Link Bandwidth and Unreserved
Bandwidth as RSVP specific attributes. The IS-IS draft only mentioned
Unreserved Bandwidth in this regard.
That
Folks -
As indicated during the presentation in Montreal, the authors feel this draft
is complete - and as there have been no recent comments we formally request the
start of WG last call on this draft.
WG chairs - please start the WG last call or let us know why you feel this is
not yet
Bruno -
Thanx for your detailed review.
V7 of the draft has been posted in response to your comments.
Responses inline.
> -Original Message-
> From: Lsr On Behalf Of Bruno Decraene via
> Datatracker
> Sent: Monday, September 30, 2019 10:19 AM
> To: rtg-...@ietf.org
> Cc:
Qin -
Apologies for the tardy response. I was on vacation when you sent the update -
and it has taken me a while to catch up.
I would agree with Adrian that the new version is a significant improvement -
but there are still two points of concern for me.
1)Although you now mention the
Ben -
You are making me work.
I posted V9 with a couple of additional changes.
Responses inline.
> -Original Message-
> From: Benjamin Kaduk
> Sent: Thursday, September 19, 2019 3:53 PM
> To: Les Ginsberg (ginsberg)
> Cc: The IESG ; draft-ietf-lsr-isis-rfc5306..
Ben -
Thanx for the detailed review.
I have posted V8 of the draft in response to your comments.
More inline.
> -Original Message-
> From: Benjamin Kaduk via Datatracker
> Sent: Wednesday, September 18, 2019 11:57 PM
> To: The IESG
> Cc: draft-ietf-lsr-isis-rfc5306...@ietf.org; Uma
Roman -
Thanx for the review.
I have uploaded V7 of the draft to address your comments.
Responses inline.
> -Original Message-
> From: Roman Danyliw via Datatracker
> Sent: Wednesday, September 18, 2019 7:45 AM
> To: The IESG
> Cc: draft-ietf-lsr-isis-rfc5306...@ietf.org; Uma Chunduri
Martin -
Thanx for reviewing.
Inline.
> -Original Message-
> From: Martin Vigoureux via Datatracker
> Sent: Tuesday, September 17, 2019 1:18 AM
> To: The IESG
> Cc: draft-ietf-lsr-isis-rfc5306...@ietf.org; Uma Chunduri
> ; aretana.i...@gmail.com; lsr-cha...@ietf.org;
>
Barry -
Thanx for the thoughtful review.
I have uploaded V6 of the document to address some (but not all) of your points.
More inline.
> -Original Message-
> From: Barry Leiba via Datatracker
> Sent: Friday, September 13, 2019 10:06 AM
> To: The IESG
> Cc:
I support moving forward with these drafts.
There are clearly use cases for this functionality and the solution has been
vetted with providers who intend to deploy this.
Les
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Friday, August 30, 2019 12:44 PM
To: lsr@ietf.org
Cc: m...@ietf.org;
I support moving forward with these drafts.
There are clearly use cases for this functionality and the solution has been
vetted with providers who intend to deploy this.
Les
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Friday, August 30, 2019 12:42 PM
To: lsr@ietf.org
Cc: m...@ietf.org;
Uma -
Please read
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-12#section-4
In short, we do not assume that EL Load Balancing can be performed for generic
MSD.
Thanx.
Les
From: Lsr On Behalf Of Uma Chunduri
Sent: Wednesday, August 28, 2019 11:38 AM
To: lsr@ietf.org
: Friday, August 23, 2019 12:01 PM
To: Alvaro Retana ; Les Ginsberg (ginsberg)
; IANA
Cc: lsr@ietf.org; draft-ietf-isis-mpls-...@ietf.org
Subject: Re: [Lsr] IANA Early Allocation Request for "Signaling Entropy Label
Capability and Entropy Readable Label Depth Using IS-IS" -
draft-ietf
Huaimo –
Thanx for your support.
A few additional comments on top of Tony’s remarks.
Inline.
From: Lsr On Behalf Of tony...@tony.li
Sent: Monday, August 19, 2019 8:37 AM
To: Huaimo Chen
Cc: lsr@ietf.org; Acee Lindem (acee)
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical
Russ -
Thanx for the careful review.
I have uploaded V5 of the draft which addresses your comments subject to my
responses inline.
> -Original Message-
> From: Russ Housley via Datatracker
> Sent: Thursday, August 15, 2019 2:38 PM
> To: gen-...@ietf.org
> Cc:
To expand on this a bit, the point of the draft extensions is to add additional
levels of hierarchy and use existing mechanisms (leaking, summarization) to
have traffic flow up/down the hierarchy.
The intent is NOT to bypass the hierarchy.
People can use multiple instances and redistribution to
Alvaro -
From: Alvaro Retana
Sent: Tuesday, August 13, 2019 7:56 AM
To: Les Ginsberg (ginsberg) ;
draft-ietf-lsr-isis-rfc5306...@ietf.org
Cc: Uma Chunduri ; lsr@ietf.org; lsr-cha...@ietf.org
Subject: RE: [Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis-02
On August 10, 2019 at 6:44:49 PM, Les
Current name: lsr-isis-hierarchical-isis
(which has too many “isis” in it as well)
Proposed name: lsr-isis-extended-hierarchy
Les
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 13, 2019 7:58 AM
To: Robert Raszuk ; Tony Li
Cc: lsr@ietf.org
Subject: Re: [Lsr] LSR Working
I am not aware of any relevant IPR.
Les
From: Acee Lindem (acee)
Sent: Monday, August 12, 2019 7:36 AM
To: Tony Li ; Les Ginsberg (ginsberg) ;
Paul Wells (pauwells)
Cc: lsr@ietf.org
Subject: IPR Poll for "Hierarchical IS-IS" -
draft-li-lsr-isis-hierarchical-isis-01
Authors,
Are
Alvaro –
Thanx for the meticulous review.
As many of your comments are regarding content which is unchanged, I have one
question for you: Where were you in 2004 when RFC 3847 was first published?
I agree with most of your comments – will prepare a new version to address them
late next week
Greg –
I have a very different opinion.
Dampening should always be done at the lowest layer possible.
In most cases this argues for interface layer, but there are cases (switches in
the path to the directly connected neighbor) where interface dampening doesn’t
always tell you what you need to
Tony -
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, July 24, 2019 3:37 PM
To: Les Ginsberg (ginsberg)
Cc: stephane.litkow...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding
Les,
If you disagree please take things bullet-by-bullet:
* LSP
to the operator (so they can address the limitation)
3)Do what we can to limit the overload on the slow node/link
Hope this helps.
Les
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, July 24, 2019 12:04 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow
Henk -
Welcome to the discussion.
Inline.
> -Original Message-
> From: henk.i...@xs4all.nl
> Sent: Wednesday, July 24, 2019 5:34 AM
> To: Les Ginsberg (ginsberg)
> Cc: stephane.litkow...@orange.com; Tony Li ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic flow co
More inline…
From: Tony Li On Behalf Of tony...@tony.li
Sent: Tuesday, July 23, 2019 10:56 PM
To: Les Ginsberg (ginsberg)
Cc: stephane.litkow...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding
Les,
There is something to be said for simply “flooding fast
Tony –
Inline.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Tuesday, July 23, 2019 10:39 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding
Les,
I also think we all agree on the goal - which is to flood significantly faster
than many
...@orange.com
Sent: Tuesday, July 23, 2019 9:50 PM
To: Les Ginsberg (ginsberg) ; Tony Li ;
lsr@ietf.org
Subject: RE: [Lsr] Dynamic flow control for flooding
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
eive queue isn't going to help
network convergence.
That's all I am saying.
Les
> -Original Message-
> From: David Lamparter
> Sent: Tuesday, July 23, 2019 2:14 PM
> To: Les Ginsberg (ginsberg)
> Cc: Tony Li ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic flow cont
Tony –
As usual, you cover a lot of territory – and even after a couple of readings I
am not sure I got everything.
Still, I dare to reply.
Inline.
From: Tony Przygienda
Sent: Tuesday, July 23, 2019 1:56 PM
To: Les Ginsberg (ginsberg)
Cc: Tony Li ; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow
Tony –
Thanx for picking up the discussion.
Thanx also for doing the math to show that bandwidth is not a concern. I think
most/all of us knew that – but it is good to put that small question behind us.
I also think we all agree on the goal - which is to flood significantly faster
than many
I am firmly on the side of Acee on this one – and I think more attention needs
to be paid to his initial answer: “B-F-D”.
The implications of this are that we do not expect control plane to have finer
granularity than seconds – which is why routing protocol hold times are
expressed in seconds
r@ietf.org; Les Ginsberg (ginsberg)
> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-
> 01.txt
>
> Authors - can you respond to Les' comments?
> Thanks,
> Acee
>
> On 6/3/19, 2:22 AM, "Lsr on behalf of Les Ginsberg (ginsberg)" boun..
Support as co-author.
I am not aware of any relevant IPR.
Les
> -Original Message-
> From: Christian Hopps
> Sent: Wednesday, June 12, 2019 5:05 AM
> To: lsr@ietf.org
> Cc: Christian Hopps ; lsr-cha...@ietf.org; lsr-
> a...@ietf.org; draft-ginsberg-lsr-isis-invalid-...@ietf.org
>
In regards to system-ids reserved for documentation, I am not aware that this
exists.
Note that the most common practice used in assigning system-ids is to use the
MAC address of some interface associated with the router.
Therefore I don’t think Tom's example in regards to IP addresses
that
support.
It is equivalent to the work that was done for the Router Capability TLV in RFC
7981.
Les
-Original Message-
From: internet-dra...@ietf.org
Sent: Thursday, June 06, 2019 8:13 AM
To: Mach Chen ; Mach Chen (Guoyi) ;
Stefano Previdi ; Xiaodong Duan
; Les Ginsberg
With this new version we welcome Huaimo Chen as a co-author.
Les
> -Original Message-
> From: Lsr On Behalf Of internet-dra...@ietf.org
> Sent: Tuesday, June 04, 2019 4:39 PM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action:
Qin -
Thanx for the prompt response.
Responses inline.
> -Original Message-
> From: Qin Wu
> Sent: Monday, June 03, 2019 5:09 AM
> To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-
> 01.txt
>
“additionally” has been retained in the Abstract. It
follows the original wording in RFC 5306. As each paragraph describes an
“additional” capability the multiple use of the term is appropriate.
Les
From: Uma Chunduri
Sent: Thursday, May 30, 2019 4:28 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
To: Acee Lindem (acee)
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01
Hi Acee,
On Wed, May 29, 2019 at 7:06 AM Acee Lindem (acee)
mailto:a...@cisco.com>> wrote:
Hi Les, Uma,
Excuse the top-post but Outlook doesn’t do well with inline re
Uma –
Hopefully we are making progress this time.
Replies inline. Look for [Les2:]
From: Uma Chunduri
Sent: Wednesday, May 29, 2019 6:56 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01
Les,
Replies in-line [Uma1]:
On Tue, May 28, 2019
Aijun -
Please look at
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-02#section-6.4
which defines how to disable dynamic flooding w/o resigning as Area Leader.
Note that having deployed dynamic flooding in a network which functions poorly
in its absence, disabling dynamic
Uma -
From: Uma Chunduri
Sent: Tuesday, May 28, 2019 5:09 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01
Les,
[Les:] The timers (T1, T2, T3) are NOT relevant to PR/PA.
PR is sent BEFORE a router does a restart to alert the neighbors
Aijun -
What is missing in this discussion is a definition of the problem to be solved.
Current draft relies on event driven updates to LSPs - the same mechanism that
has been used for 30 years to detect all manner of changes in the network.
Before defining a "solution" (let alone voting for
Huaimo -
It is highly undesirable that there only be one Area Leader sub-TLV
advertisement. The latest version of the draft (V2) highlights this. Please see
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-02#section-6.8.10
You have also not responded to Tony's point that we do not
Folks -
The latest revision includes:
1)Revision to the encoding of the OSPF Router ID TLVs to allow multiple IDs of
the same "connection type" to be included in the same TLV.
This optimization was suggested by Huaimo Chen (thanx!!)
2)Some clarifications as to how Dynamic Flooding can be
Uma –
Inline.
From: Lsr On Behalf Of Uma Chunduri
Sent: Friday, May 24, 2019 10:49 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01
As asked by chairs I was trying to write the shepherd report on this doc.
Have few quick questions on this work:
1.
Observation: The new
And…BTW…there is already a draft defining the necessary BGP-LS extensions:
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-app-specific-attr/
Les
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Friday, May 24, 2019 5:55 AM
To: Robert Raszuk
Cc: lsr@ietf.org;
19 1:52 PM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: LEEF bit behavior) RE: [Lsr] I-D Action:
draft-ietf-lsr-dynamic-flooding-01.txt
Hi Les,
Thank you very much for adding the LEEF bit into the draft based on the FT
bit for a link. The bit advertised by one end node of the link
Sent: Tuesday, May 21, 2019 11:18 PM
To: Les Ginsberg (ginsberg)
Cc: Huaimo Chen ; Tony Li ;
lsr@ietf.org
Subject: Re: [Lsr] Migration between normal flooding and flooding reduction
One may observe that the draft implicitly also supports already option A too.
If leader advertises full topology
of this
issue. Please see
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-01#section-6.8.3 .
Thanx.
Les
From: Huaimo Chen
Sent: Monday, May 20, 2019 1:56 PM
To: Les Ginsberg (ginsberg) ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: Flooding Negotiation bit
Hi Les
Folks -
Major changes in this version include:
1)Added support for LANs as part of the flooding tropology
2)Added support for advertising what links are enabled for flooding at each
node. This is based on a proposal in draft-cc-lsr-flooding-reduction (the FT
bit) but we have defined it to be
Huaimo –
I, like Tony, am wondering what problem you are trying to solve.
Note that updated LSPs/LSAs which are received on an interface which the
receiving node believes is NOT part of the flooding topology are NEVER
discarded. They are processed and flooded on those interfaces which the
Adam -
V25 of the draft has been published addressing your comments.
Les
> -Original Message-
> From: Les Ginsberg (ginsberg)
> Sent: Tuesday, May 14, 2019 10:23 PM
> To: Adam Roach ; The IESG
> Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org; Christia
Huaimo –
It seems to me from your description that you are trying to deal with the
startup case where a node reboots, has a large number of neighbors which need
to be formed, and if this is done all simultaneously there will be a lot of
redundant flooding between the new node and each of its
Barry -
Thanx for the review.
Response inline.
> -Original Message-
> From: Barry Leiba via Datatracker
> Sent: Wednesday, May 15, 2019 9:30 PM
> To: The IESG
> Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org; Christian Hopps
> ; Uma Chunduri ;
> aretana.i...@gmail.com;
Roman -
Thanx for the review.
Responses inline.
> -Original Message-
> From: Lsr On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Wednesday, May 15, 2019 12:18 PM
> To: The IESG
> Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org; Christian Hopps
> ; uma.chund...@huawei.com;
Gyan -
I grant that UHP may not be widely used in deployments - but as it is a
supported option when using MPLS we saw no reason to eliminate support for it
in the signaling.
Being able to support it does not require folks to deploy it of course.
Les
> -Original Message-
> From:
Adam -
Thanx for the review.
Responses inline.
> -Original Message-
> From: Adam Roach via Datatracker
> Sent: Tuesday, May 14, 2019 10:03 PM
> To: The IESG
> Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org; Christian Hopps
> ; Uma Chunduri ;
> aretana.i...@gmail.com;
Gyan -
The paragraph you cut and pasted is providing a short overview of Segment
Routing, which can be used on two different data planes - IPv6 and MPLS.
The introduction goes on to say:
"This draft describes the necessary IS-IS extensions that need to be
introduced for Segment Routing
Mirja -
Inline.
> -Original Message-
> From: Mirja Kuehlewind
> Sent: Tuesday, May 14, 2019 9:35 AM
> To: Les Ginsberg (ginsberg)
> Cc: The IESG ; draft-ietf-isis-segment-routing-
> extensi...@ietf.org; Christian Hopps ; Uma Chunduri
> ; aretana.i...@gmail.com
Mirja -
Thanx for the review.
Responses inline.
> -Original Message-
> From: Mirja Kühlewind via Datatracker
> Sent: Tuesday, May 14, 2019 4:58 AM
> To: The IESG
> Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org; Christian Hopps
> ; Uma Chunduri ;
> aretana.i...@gmail.com;
Support.
Les
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 09, 2019 6:50 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support
Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt
We been holding off WG adoption
Erik -
Thanx for the detailed review.
I have published V24 of the draft which addresses all of your comments (and a
few pending AD review comments from Alvaro).
Some exceptions noted below.
> -Original Message-
> From: Erik Kline via Datatracker
> Sent: Wednesday, April 17, 2019 7:20
(Resending w corrected address for rtg-dir)
Russ -
Thanx for the review - and the kind words.
Les
> -Original Message-
> From: 7ri...@gmail.com <7ri...@gmail.com>
> Sent: Sunday, April 14, 2019 6:56 PM
> To: rtg-...@ietf.org
> Cc: rtg-...@ietfr.org;
>
Russ -
Thanx for the review - and the kind words.
Les
> -Original Message-
> From: 7ri...@gmail.com <7ri...@gmail.com>
> Sent: Sunday, April 14, 2019 6:56 PM
> To: rtg-...@ietf.org
> Cc: rtg-...@ietfr.org;
> draft-ietf-isis-segment-routing-extensions@ietf.org;
> lsr@ietf.org
>
Olivier –
As Jeff has indicated in his reply, the use cases and issues around these
protocol extensions have been discussed extensively on the WG lists (including
of course the now subsumed OSPS/IS-IS WG lists) and were the subject of many
presentations at many IETFs. The history of these
+1 to what Peter has stated.
Olivier -
We are aware that link attribute management/application has challenges - which
is why we are careful to allow sharing of attributes when appropriate.
But to state that there is no problem and that things can be addressed with
existing IGP functionality if
I am not aware of any relevant IPR.
Les
From: Acee Lindem (acee)
Sent: Thursday, April 11, 2019 9:10 AM
To: draft-ietf-ospf-te-link-attr-re...@ietf.org
Cc: lsr@ietf.org; Ketan Talaulikar (ketant) ; Hannes Gredler
; Acee Lindem (acee)
Subject: IPR Poll for "OSPF Link Traffic Engineering
then incorporate it in the
Dynamic Flooding draft.
Please continue the thread w Tony.
Thanx.
Les
> -Original Message-
> From: Huaimo Chen
> Sent: Tuesday, April 09, 2019 8:47 AM
> To: Les Ginsberg (ginsberg) ; tony...@tony.li;
> lsr@ietf.org
> Subject: RE: [Lsr
Tony -
Here is my take.
Regarding Issue #2 below, we had a healthy thread on this since Prague and I
believe have consensus that we WILL support LANs in the encoding of the
flooding topology (centralized mode). Authors need to agree on changes to the
draft which we will take offline and then
Alvaro –
Responses inline.
From: Alvaro Retana
Sent: Wednesday, April 03, 2019 2:22 PM
To: Les Ginsberg (ginsberg) ;
draft-ietf-isis-segment-routing-extensi...@ietf.org
Cc: lsr-cha...@ietf.org; lsr@ietf.org; Uma Chunduri
Subject: RE: AD Review of draft-ietf-isis-segment-routing-extensions-22
ess that is a real world deployment case I would not consider the extension
worth the trouble.
Les
From: Robert Raszuk
Sent: Wednesday, April 03, 2019 11:17 AM
To: Les Ginsberg (ginsberg)
Cc: Robert Raszuk ; lsr@ietf.org
Subject: Re: [Lsr] LANs in IGPs
Well imagine I am building DMZ with
If you want a way to more easily enable P2P mode by default – speak to your
favorite vendor. That is a feature – not a protocol extension.
Completely disagree. To detect how many IGP peers are on the interface and to
do the switchover gracefully between 2 vs N or N vs 2 protocol extension is
Bruno -
V3 of the draft has been posted.
Hopefully it addresses your remaining comment.
Les
From: bruno.decra...@orange.com
Sent: Tuesday, April 02, 2019 6:59 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org;
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana
Subject: RE: draft
601 - 700 of 814 matches
Mail list logo
