Les, all
> From: Les Ginsberg (ginsberg)
>
> Chris -
>
>
> However, that is the missing piece, so it works if we also add a capability
> bit. If we have the capability bit you now know which routers are processing
> the container TLV and which aren't. That should be enough info to route
Hi authors,
Please find below some questions.
1. Assuming ABR1 advertises IP1 with metric 10 while ABR2 advertises IP1
with MAX metric. Is this prefix reachable or unreachable (or both)?
2. Assuming ABR1 advertises a summary address but ABR2 does not. If ABR2
advertises IP1 with MAX
Hi all,
We have updated the document with the following changes:
- text highlighting that the DIS plays a special role in flooding. Hence
consider increasing the LAN priority for nodes supporting faster flooding.
- a new section on LSP pacing, inspired (read copy pasted) from RFC 9002
section 7
Hi all,
This is just a refresh.
Regards,
--Bruno
Orange Restricted
-Original Message-
From: Lsr On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, January 10, 2023 4:18 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action:
I support progression of this document. It clarifies RFC8919 and as such
improves interoperability.
(I've already reviewed and commented on the doc)
Thanks,
Regards,
--Bruno
Orange Restricted
-Original Message-
From: Lsr On Behalf Of Christian Hopps
Sent: Wednesday, December 7, 2022
Hi Tony,
> Comments or questions?
Thanks for the update
Just looking at the diff, 2 comments
1. "Network operators should not enable Multi-part TLVs until ensuring
that all implementations that will receive the Multi-part TLVs are
capable of interpreting them correctly."
I would
Peter,
> From: Peter Psenak
> Sent: Wednesday, November 9, 2022 2:13 PM
>
> On 09/11/2022 14:56, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> >> I guess I'd like to understand what one would accomplish with further
> >> specification of
> From: Lsr On Behalf Of David Lamparter
> Sent: Wednesday, November 9, 2022 10:45 AM
> Hi Peter, hi all,
>
>
> to iterate on the comment I made on the mic a few minutes ago, I
> apparently have a rather different understanding of existing IS-IS
> behaviour. Reading 5305/5308,
>
> ...
Les, all
Please see inline
> From: Lsr On Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, October 7, 2022 1:35 AM
A bit late in the game. At least I've read all subsequent emails.
> To: Christian Hopps
> Cc: Peter Psenak (ppsenak) ; Tony Li ;
> Robert Raszuk ; Henk Smit ;
> lsr@ietf.org
I've not followed everything in details so I've been reluctant to comment, but
nonetheless please find below a diverse set of comments.
> From: Christian Hopps mailto:cho...@chopps.org>>
[...]
> AFAICT we now have implementations out there that are sending multiple TLVs
> which are not
Hi chairs, all,
I strongly support WG adoption: the goal of this bis doc is clarification of an
existing RFC in order to ensure (well, at least help) that we have
interoperable implementations.
- Clarity and interoperability is a clear goal in general, but especially in
the context of FlexAlgo
Hi all,
Two technical changes:
- reflecting the IANA allocated code point.
- addition of a sub-TLV to specifically advertise the Receive Window of the
flow control algo (aka RWIN). Previously, the "LSP Burst Window" was used, but
the latter is more like a QoS/data plane buffer information so
Hi Tony,
Thanks the update.
1 clarification question on §5 (new capability)
« If all routers in an area advertise the Multi-part TLV Capability a node MAY
advertise multi-part TLVs "
Does this mean that if one router does not advertise the capability, routers
MUST NOT advertise multi-part
Hi Peter,
Thanks for your reply. Please see inline [Bruno2]
Orange Restricted
> -Original Message-
> From: Peter Psenak
> Sent: Thursday, June 16, 2022 11:22 AM
> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
>
> Hi
Daniel, inline
Orange Restricted
From: Voyer, Daniel
Sent: Wednesday, June 15, 2022 9:43 PM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Bruno, inline
From: Bruno Decraene
mailto:bruno.decra...@orange.com>>
Date: Wednesday, June
Hi Aijun,
Orange Restricted
From: Aijun Wang
Sent: Thursday, June 16, 2022 1:59 AM
To: DECRAENE Bruno INNOV/NET
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi, Bruno:
I agree with your thoughts on the solutions to this questions.
Actually, this is the
Hi Daniel,
I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as
"a use case"/informational.
My point is that IMO the draft changes the behavior defined in RFC5305/RFC5308.
Indeed, as per those two RFC, I'm allowed, today, to advertise a prefix with
MAX_PATH_METRIC for
Hi Peter, authors, all
Thanks for the draft. I find it a useful contribution to the problem space.
IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be
made backward compatible and provides incremental benefits with incremental
deployment.
I also have two disagreements
Hi Les, John, all,
Could we have an update on this?
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of
> John Scudder
[…]
> I think the changes could be processed either as a bis or as a so-called
> “patch” draft, i.e. one that looks substantially similar to the errata you
> submitted (a
Peter,
> From: Peter Psenak
> Sent: Thursday, January 6, 2022 11:03 AM
>
> Bruno,
>
> On 06/01/2022 10:40, bruno.decra...@orange.com wrote:
> > Peter,
> >
> > Thanks for your answer.
> > Please see inline [Bruno]
> >
> >
> >> From: Peter Psenak
> >> Sent: Thursday, January 6, 2022 10:25 AM
>
Peter,
Thanks for your answer.
Please see inline [Bruno]
> From: Peter Psenak
> Sent: Thursday, January 6, 2022 10:25 AM
>
> Bruno,
>
> the PIC is used unchanged with PULSE.
[Bruno] OK. Therefore, from a FIB standpoint, does this mean that the scaling
properties are also unchanged compared
Hi Gyan,
You are referring to both summarization and BGP PIC (edge).
BGP PIC is quite old story, but if my memory serve me well, BGP PIC edge relies
on the presence of the specific (/32) prefix information in the FIB. Hence it’s
not clear to me how you can have both prefix summarization and BGP
Orange Restricted
-Original Message-
From: IETF Secretariat
Sent: Tuesday, November 30, 2021 4:03 PM
To: draft-decraeneginsberg-lsr-isis-fast-flood...@ietf.org
Cc: ipr-annou...@ietf.org
Subject: IPR Disclosure Cisco Systems, Inc.'s Statement about IPR related to
As co-author, I support adopting this draft as a WG document.
I'd favor the standard track:
* I'd argue that _flow_ control based on a signaled window is simple
(compared to congestion control), old and well-known and not subject to
experimentation any more. It has been deployed in much
Hi Peter,
> From: Peter Psenak
> Sent: Thursday, September 9, 2021 3:30 PM
> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
>
> Hi Bruno,
>
> On 09/09/2021 15:27, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for your answer.
> >
Dear all,
During LSR interim meeting on September 29th [0] authors of
draft-decraene-lsr-isis-flooding-speed [1] and
draft-ginsberg-lsr-isis-flooding-scale [2] agreed to work together and publish
a common combined draft by October 25 [3].
New draft has been published today [4]. As presented
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Hi Bruno,
>
> On 09/09/2021 15:27, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for your answer.
> > Please see inline
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Thursday,
Hi Peter,
Thanks for your answer.
Please see inline
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, September 9, 2021 2:52 PM
> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
>
> Hi Bruno,
>
> On
Hi authors, all,
I have a question related to the two-way connectivity check performed on each
link during the FlexAlgo SPF.
Is this point documented in the document? I could not find it so far.
If not, what is the (reverse connectivity) check that need to be performed on
the reverse link?
A
Some more questions on S13 (speeding UP, aka sensing the receiver performance)
Can you clarifying the definition of the three measurements reported (LSPTxMax,
Tx, RxAv)?
So far, it seems that LSPTxMax is always higher than RxAv, i.e. the sender's
estimation seems higher than the receiver
Les,
Thank you for the implementation and test results.
I have some clarification questions on your test results
S6:
What burst size did you use? And distributions of reals values if possible, if
not (min, max, average, median) would be useful.
What scheduling frequency/period did you use on
Les,
Faster flooding may be achieved without protocol extension. But if we are at
changing flooding, it would be reasonable to try to make it good (rather than
just faster than today).
In particular some goals are:
- faster flooding when the receiver has free cycles
- slower flooding when the
Les,
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
[...]
> I also think it would be prudent to delay WG adoption
For how long exactly would it be "prudent to delay WG adoption"? (in addition
to the past two years)
Until what condition?
It's been two years now since
Hi chairs, WG,
Over the last two years, we have presented and the WG discussed
draft-decraene-lsr-isis-flooding-speed at IETF 105 and "107"
IETF 105: https://datatracker.ietf.org/meeting/105/proceedings#lsrNote:
that the presentation is in first slot/video but a large part of the discussion
OK. Crystal clear.
Thanks Peter.
--Bruno
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, June 17, 2021 4:59 PM
> To: DECRAENE Bruno INNOV/NET ; Acee Lindem
> (acee) ; lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps ;
> draft-ietf-lsr-flex-
>
Hi,
I have a question/comment.
I think that we all agree that FlexAlgo/Link State computation requires that
all node use the same topology to compute their SPF. Otherwise, permanent
forwarding loops are probable.
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12
Les, Peter,
Thank you for agreeing to clarify the sentence and for the effort put in
proposing a new text.
Proposed text looks much better to me. I particularly like the either MUST or
MUST NOT statement.
I have one comment.
In the RFC, the term "advertisement" is used to refer both to
Les, Peter,
Thanks for the clarification. This is crystal clear.
This address my concern. My goal is specification clarity to avoid interop
issues at the earliest stage, because the latter the misalignment is found the
bigger the delay and the cost, both for vendors and network operators.
From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, June 4, 2021 4:50 PM
To: DECRAENE Bruno INNOV/NET
Cc: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
To me this "permitted" is only about applying ASLA to all apps (no bit mask)
except
From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, June 4, 2021 3:35 PM
To: DECRAENE Bruno INNOV/NET
Cc: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
Ok you meant domain wide not locally ... but there is already strong normative
MUST
Hi Robert,
From: Robert Raszuk [mailto:rob...@raszuk.net]
Hi Bruno,
> I think it’s self-evident that we would end up with a permanent routing loop.
Is that so ? Wouldn't it just result in unidirectional link for a given app ?
Maybe intentional ?
It seems that what you described may cause
Hi all,
I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]
FlexAlgo is distributed routing computation so it's required that all routers
use exactly the same data to compute the routes/SPF.
FlexAlgo is clear that ASLA MUST be used:
"Link attribute advertisements that are
Peter,
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Bruno,
>
> On 03/06/2021 15:41, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thank you for your answer and for your crystal clear email.
> >
> > As a side note, my reading of RFC 8920 is that this behaviour is
> > different
Hi Peter,
Thank you for your answer and for your crystal clear email.
As a side note, my reading of RFC 8920 is that this behaviour is different in
OSPF.
“If link attributes are advertised with zero-length Application Identifier Bit
Masks for both standard applications and user-defined
Hi all,
In order to (try to) avoid interop issues, I have a clarification question on
RFC 8919.
"If link attributes are advertised associated with zero-length Application
Identifier Bit Masks for both standard applications and user-defined
applications, then any standard application and/or
Hi all,
Better safe than sorry, I guess.
FYI, in -08 (a year ago) draft introduced one single iteration of the FA
acronym: "The scope of the FA computation is an area"
Do we really want to create that FA acronym for Flex Algo?
FA has already been used for Forwarding Adjacency (e.g., [1])
Acee, Chris,
I’m not aware of non-disclosed IPR.
Thanks,
--Bruno
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, May 12, 2021 11:09 PM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Hi Peter,
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Hi Bruno,
>
> On 12/05/2021 10:24, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for the answer.
> > Please see inline.
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Hi Bruno,
> >>
> >>
> >> On
Hi Peter,
Thanks for the answer.
Please see inline.
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Hi Bruno,
>
>
> On 12/05/2021 09:51, bruno.decra...@orange.com wrote:
> > Hi Xuesong,
> >
> > Clarification question: are you talking about interoperability (between
> > two nodes) or
Hi Xuesong,
Clarification question: are you talking about interoperability (between two
nodes) or compliancy (between an implementation and the RFC)?
If the former, could you please spell out the interop issue?
Thanks,
Best regards,
--Bruno
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of
+1
The information needs to be tracked and consolidated. Seems better done by a
single person than by many persons duplicating the work, not to mention by zero
person (surely someone else is doing the job).
This may be less important in LSR though, as we have designated experts which
may
Hi Peter,
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, March 12, 2021 3:13 PM
>
> Hi Bruno,
>
> please see inline:
>
> On 12/03/2021 11:39, bruno.decra...@orange.com wrote:
> > Peter, Alvaro
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Thursday, March
Peter, Alvaro
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, March 11, 2021 11:47 AM
[...]
> > ...
> > 221 4.3. Maximum H.Encaps MSD Type
> >
> > 223 The Maximum H.Encaps MSD Type specifies the maximum number
> of SIDs
> > 224 that can be included as part of the
Peter,
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Bruno,
>
> please see inline:
>
>
>
> On 20/10/2020 11:43, bruno.decra...@orange.com wrote:
> > Peter,
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Bruno,
> >>
> >> On 19/10/2020 18:52, bruno.decra...@orange.com
Peter,
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Bruno,
>
> On 19/10/2020 18:52, bruno.decra...@orange.com wrote:
> > Ron, all,
> >
> >>From a use case standpoint, I have a use case for having both SR-MPLS and
> IP flexalgo in the same network.
> >
> >>From a protocol standpoint, I
Ron, all,
>From a use case standpoint, I have a use case for having both SR-MPLS and IP
>flexalgo in the same network.
>From a protocol standpoint, I think that the functionality could be equally
>met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit
>null) to instruct
Hi Peter,
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Hi Bruno,
>
> please see inline:
>
> On 07/09/2020 17:31, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Thursday, September 3, 2020 9:55 AM
> >>
Hi Peter,
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 9:55 AM
>
> Hi Shraddha,
>
> On 03/09/2020 05:39, Shraddha Hegde wrote:
> > Peter,
> >
> > In order to make the document clearer on this point, I would like the text
> below to be
Hi Tony,
Thanks for your reply.
At this point, area proxy spec is clear with regards to nominal behavior. So
indeed we are discussing error handling / transitions. (and thank you for
considering those cases, much appreciated).
From memory, my understanding is the area proxy nominal behaviour
Hi Tony,
Thanks for your reply.
All good to me.
Thanks,
--Bruno
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Saturday, September 5, 2020 2:18 AM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Hi Tony,
I may have a comment on 5.2. Filtering LSP information.
This is old text, but new re-reading.
"A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an
Outside Router. >
Agreed (so far)
"A Level 2 LSP with a source system identifier that is found in the Level 1
LSDB
Hi Tony,
Please find below some nits/minor comments. Please feel free to silently
discard.
1)
OLD: The
advertisement in the Proxy LSP informs the remainder of the network
that packets directed to the SID will be forwarded by one of the
Inside Edge Nodes and the Area SID will be
Hi Tony,
I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.
And thank you for listening to my use case and suggestion.
Thanks,
--Bruno
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Monday, August 24, 2020 7:02 PM
To: lsr@ietf.org
Les,
Please see inline.
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, August 4, 2020 4:50 PM
To: DECRAENE Bruno TGI/OLN ; lsr@ietf.org
Subject: RE: draft-ietf-lsr-isis-area-proxy-02
Bruno -
Please see inline.
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of
Hi,
I may be missing something but the SR Binding SID TLV extension is not clear
to me.
1) It does not seem compliant with RFC 8667
Draft says that the advertisement has: T-flag set, M & A flags cleared,
SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present
The following
Les,
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 3, 2020 5:22 PM
To: DECRAENE Bruno TGI/OLN ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for
draft-ietf-lsr-isis-area-proxy-02.txt
Bruno –
The concept of “Area SID” – at least
Hi Tony,
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Subject: Re: [Lsr] New Version Notification for
draft-ietf-lsr-isis-area-proxy-02.txt
Hi Bruno,
Thank you for the clarification.
[Bruno] You are very welcome. Thank you for listening.
I understand completely
Hi Tony,
Thank you for your reply.
Top posting the description of the use case that I have in mind.
Ø First off, the Area SID is 100% optional. If you choose not to use it, then
the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is
Les,
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, July 30, 2020 7:29 PM
To: DECRAENE Bruno TGI/OLN ; tony...@tony.li;
lsr@ietf.org
Subject: RE: [Lsr] Fwd: New Version Notification for
draft-ietf-lsr-isis-area-proxy-02.txt
Bruno –
One of the reasons to use the
Hi authors,
Please find below some feedback for information. Feel free to ignore.
4.4.13. The Area SID
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13
"The following extensions to the Binding TLV are defined in order to
support Area SID:
A new flag
Hi Tony,
Thanks for the updated draft.
“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
represents the entirety of the Inside Area to the Outside Area. This
sub-TLV is learned by all of the Inside Edge Nodes who should consume
this SID at forwarding time.”
Another data point about advertising more detailed reachability/unreachability:
https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01
(for IPv6 some form of compression may be beneficial).
--Bruno
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, July
Hi Peter,
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Hi Bruno,
>
> On 30/06/2020 18:08, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for your reply.
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Hi Bruno,
> >>
> >> please see inline:
> >>
> >> On
Hi Peter,
Thanks for your reply.
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Hi Bruno,
>
> please see inline:
>
> On 30/06/2020 16:53, bruno.decra...@orange.com wrote:
> > Hi all,
> >
> > I can live with the current text, but I'm just raising the point for
> > discussion
> (better
Hi all,
I can live with the current text, but I'm just raising the point for discussion
(better safe than sorry).
"16.1.1. IGP Algorithm Types Registry
This document makes the following registrations in the "IGP Algorithm Types"
registry:
Type: 128-255.
Description: Flexible
Hi Chris, Acee,
I support adoption.
I've provided comments on the draft a couple of days ago.
Regards,
--Bruno
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, June 10, 2020 9:28 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org;
Hi WG,
Following our presentation at the latest LSR interim meeting, we have updated
the draft as presented and discussed during the meeting.
High level changes are:
o Adding general introduction on flow control, congestion control, loss
detection and recovery.
o Reorganizing
Hi all,
I've quickly read both drafts.
In general, I don't think that I have spent enough time on the subject to
provide any feedback on the list, but I've been suggested that some feedback is
better than none. So providing some feedback for what it worth (2 cents).
I think that the use case
Les,
Thanks for the updated draft.
Looks ok to me except the point on interoperability.
Indeed, I was asking to reinforce the requirement for interoperability with
existing attributes, as this interop issue is created by this
specification/extension. But you chose the opposite direction by
Les,
Thanks for your answers.
Comments inline
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> Sent: Saturday, May 30, 2020 12:09 AM
>
> Bruno -
>
> Thanx for your (as always) meticulous review.
> Responses inline.
> Once we have reached agreement I will send out an updated
> From: Christian Hopps [mailto:cho...@chopps.org]
>
> Bruno persistence has made me realize something fundamental here.
>
> The minute the LSP originator changes the LSP and floods it you have LSDB
> inconsistency.
Exactly my point. Thank you Chris.
I would even say: "The minute the LSP
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
Subject: RE: Flooding across a network
Bruno -
Seems like it was not too long ago that we were discussing this in person.
Ahhh...the good old days...
Les,
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Monday, May 4, 2020 4:39 PM
[...]
> when only some nodes in the network support faster flooding the behavior of
> the whole network may not be "better" when faster flooding is enabled because
> it
Hi all,
Following the meeting today, and the first results with existing algorithm, it
would a priori be interesting to have simulations or implementations tests
results on the proposed algorithms.
This email is a call to for info / contribution on this.
- Do you know research
Ø ISIS flooding churn (and room for optimization) becomes a problem when node
boots up (IMHO this is not a problem) and when node fails while having many
neighbors attached. Yes maybe second case could be improved but well designed
and operated network should have pre-programmed bypass paths
Tony
From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Thursday, April 23, 2020 7:29 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
I was refering to RFC4960. Bruno, for all practical purposes I
Tony,
Thanks for engaging.
Please inline [Bruno2]
From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 9:25 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
On Wed, Apr
Peter,
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Bruno,
>
> On 22/04/2020 20:04, bruno.decra...@orange.com wrote:
> > Les,
> >
> > Pleasesee inline
> >
> > *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > *Sent:* Tuesday, April 21, 2020 11:48 PM
> > *To:* DECRAENE
Les,
Please see inline
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, April 21, 2020 11:48 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed
Bruno -
You have made an assumption that historically vendors have
Tony, all,
Thanks Tony for the technical and constructive feedback.
Please inline [Bruno]
From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 1:19 AM
To: Les Ginsberg (ginsberg)
Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for
Les,
Thank you for this first answer. This is inline with my understanding of the
behavior.
I wish some of the behaviors and values (e.g. queue size, rate limiting) could
be shared. At minimum a range of typical values for platform which are not end
of sale. I don't think this is secret.
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-decraene-lsr-isis-flooding-speed are the same as the one implemented
(configured) on multiple
Chris,
Please see inline.
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Friday, April 3, 2020 12:00 AM
> To: Robert Raszuk
>
>
>
> > On Apr 2, 2020, at 5:17 PM, Robert Raszuk wrote:
> >
> > Many thx,
> > R.
> >
> > PS. As we are talking LSR here it is
With regards to punting to TCP, I think that TCP (stacks) enforce packet
ordering.
i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1 until
you receive packet 2. In the meantime, you cannot use the (N-2) packets that
you did received.
That seems like a regression for IS-IS
Hi all,
Following many interesting discussions on the mailing list, during IETF
meetings 105 & 106 and of-list, please find below an updated version.
Htmlized:
https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed
Diff:
Hi Ketan,
Thanks fort the follow up.
Clarification inline [Bruno]
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Friday, February 28, 2020 11:11 AM
To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
Cc: lsr@ietf.org; SPRING WG List;
Hi Ketan,
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM
Hi Chris,
I agree with Peter and I would suggest to drop LSR since this is not a protocol
specific thing.
I believe the text in
Les,
Please see inline[Bruno]
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 3:32 AM
To: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
Base protocol operation of the Update process tracks the
Les,
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 6:49 PM
To: Robert Raszuk
Cc: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
Robert –
Thanx for your input.
Note that one of the suggestions
> From: Peter Psenak [mailto:ppse...@cisco.com]
>
> Hi Bruno,
>
> On 28/01/2020 18:05, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thank you.
> > Looks good.
> >
> > Just one follow up
> >
> >>> §9
> >>>
> >>> A priori the sum of all 4 sizes must be 128 bits. Could you specify the
1 - 100 of 132 matches
Mail list logo
