Robert,
Assuming C and E provide access to the same set of destinations, that are
closer of further away from C and E.
B (which is fast), after it notifies A that it can’t reach C directly will
cause A to send traffic to D. D - dependent on total cost would start happily
sending some traffic
Robert,
I agree with you…
Disruptions based on protocol changes with non-current/legacy
type products and/or intenal black-hole , loss of packets/rexmits, aka
reliability should be primary. Even good/great ideas of IPv4 / IPv6
intermediate systems/routers find
This is not a simple let's-build-a-better-mechanism problem, this is an
epistemology problem and uneven information diffusion cannot be fixed by
magic when dealing with total distributed computation. Traditional
Link-state basically only works because we assume an epsilon consistently
(correct
Joel -
No - I am not "asking" for anything.
I am simply trying to demonstrate that a deployment that has nodes with
significantly different flooding rate support can encounter long periods of
looping in certain failure scenarios - and that a similar period of looping
would NOT occur if all
Les, maybe I am missing your point, but it sounds like what you are
asking for is a (better?) version of the micro-loop prevention work, so
as to mitigate the interaction between inconsistent convergence and
fast-reroute?
Yours,
Joel
On 5/6/2020 1:53 PM, Les Ginsberg (ginsberg) wrote:
Bruno
Bruno -
I am sorry it has been so difficult for us to understand each other. I am
trying my best.
Look at it this way:
You are the customer.
I am the vendor.
The failure scenario I describe below happens and you notice that all
Northbound destinations loop for 35 seconds whenever fast
> 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
Hi Peter, Dhruv,
On 5/6/20, 12:00 PM, "Peter Psenak" wrote:
Hi Dhruv,
please see inline:
On 06/05/2020 17:40, Dhruv Dhody wrote:
> Hi Peter,
>
> Thanks for your reply, snipping to points that need further discussion...
>
>> What about:
>>
>> Segment
I guess all this discussion has to do with this other part of that document:
"o Limitations on the processing rate of incoming control traffic
However, intentionally using different flooding rates on different
interfaces increases the possibility of longer periods of LSDB
Hi Xuesong,
> I think there is no need to distinguish the concept of flow control
> and congestion control, considering that the core idea is the same: monitor
> the sending rate to match the capability of the bottleneck, no matter there
> are competitors or not. And the control loop is
Hi Dhruv,
please see inline:
On 06/05/2020 17:40, Dhruv Dhody wrote:
Hi Peter,
Thanks for your reply, snipping to points that need further discussion...
What about:
Segment Routing with the MPLS Data Plane relies on Interior Gateway
Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3
Hi Peter,
Thanks for your reply, snipping to points that need further discussion...
> What about:
>
> Segment Routing with the MPLS Data Plane relies on Interior Gateway
> Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3 [RFC8666] to signal
> labels.
>
Much better.
> > (3) Section 4
> >
>
Chris -
I agree.
https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-3.1
states:
" Inability to handle LSP reception at the
targeted flooding rate should be viewed as an error condition which
should be reported. If this condition persists, it indicates that
Bruno -
The key in this example is when all nodes in the network realize that there are
no longer any northbound paths via C.
I am willing to stipulate that nodes that can receive LSPs faster will also be
able to flood LSPs faster. If that isn't the case we might as well all stop
working on
Bruno persistence has made me realize something fundamental here.
The minute the LSP originator changes the LSP and floods it you have LSDB
inconsistency. That is going to last until the last node in the network has
updated it's LSDB.
Les is pointing out that LSDB inconsistency can be bad in
Reviewer: Elwyn Davies
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more
Bruno -
I am somewhat at a loss to understand your comments.
The example is straightforward and does not need to consider FIB update time
nor the ordering of prefix updates on different nodes.
Consider the state of Node B and Node D at various time points from the trigger
event.
T+ 2 seconds:
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...
Hi Murray,
On 06/05/2020 07:52, Murray Kucherawy via Datatracker wrote:
Murray Kucherawy has entered the following ballot position for
draft-ietf-ospf-mpls-elc-13: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC
Hi Barry,
thanks for your comments. I have fixed all editorial comments.
For the last two comments, Alvaro has already taken care of.
thanks,
Peter
On 06/05/2020 07:12, Barry Leiba via Datatracker wrote:
Barry Leiba has entered the following ballot position for
draft-ietf-ospf-mpls-elc-13:
Hi Barry,
thanks for comments, I fixed them all.
thanks,
Peter
On 06/05/2020 06:58, Barry Leiba via Datatracker wrote:
Barry Leiba has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: No Objection
When responding, please keep the subject line intact and reply to all
Esteemed LSR WG members,
Virtual IETF meeting survey link below – please take the survey if you intend
on participating in future virtual IETF meetings.
Thanks,
Acee
From: WGChairs on behalf of Alissa Cooper
Date: Tuesday, May 5, 2020 at 7:49 AM
To: IETF WG Chairs
Subject: Fwd: Reminder:
Hi Dhruv,
thanks, for your comments, please see inline:
On 05/05/2020 11:43, Dhruv Dhody via Datatracker wrote:
Reviewer: Dhruv Dhody
Review result: Has Issues
Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing
Hi Dhruv,
thanks, for your comments, please see inline:
On 05/05/2020 11:44, Dhruv Dhody via Datatracker wrote:
Reviewer: Dhruv Dhody
Review result: Has Issues
Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing
On May 6, 2020 at 1:12:42 AM, Barry Leiba wrote:
Barry:
Hi!
> — Section 4 —
>
> The ERLD is advertised in a Node MSD sub-TLV [RFC8476] using the
> ERLD-MSD type defined in [I-D.ietf-isis-mpls-elc].
>
> Just checking: is the IS-IS draft the right reference here in this OSPF
> document?
Yes,
Murray:
Hi!
Yes, I have.
In this case, this document was the result of merging several other
documents so it was decided to allow 6 authors (the rest became
contributors). The same is true for the OSPF version.
Thanks!
Alvaro.
On May 6, 2020 at 1:44:50 AM, Murray Kucherawy via Datatracker (
Christian,
It is not about "hand-wringing and theorizing about being too-successful".
It is about impact to the overall network service when you make ISIS
convergence not consistent across nodes of the topology, I think our goal
is not to converge ISIS faster by improving flooding speed ... it
Hi Tony,
Thank you for your explanation. Please find my comments inline.
Best Regards
Xuesong
> -Original Message-
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
> Sent: Friday, May 1, 2020 12:16 AM
> To: Gengxuesong (Geng Xuesong)
> Cc: Christian Hopps ;
28 matches
Mail list logo
