Hi Huaimo,
> You’ve computed the backup paths: [R4, R3, R6, R7] and [R5, R2, R9, R8].
> This results in enabling flooding on (R3, R6) and on (R5, R2), (R2, R9), (R9,
> R8).
>
> [HC]: The enhanced algorithm enables the temporary flooding on (R3, R6) and
> (R2, R9). It does not enable
] Min Links for Multiple Failures on Flooding Topology
Hi Huaimo,
What is “the existing algorithm” that you have?
Is it the “rate limiting”? If so, can you describe the “rate limiting”
algorithm in details?
Yes. We haven’t described it very formally, so let me see if I can be more
precise
Hi Huaimo,
> What is “the existing algorithm” that you have?
> Is it the “rate limiting”? If so, can you describe the “rate limiting”
> algorithm in details?
Yes. We haven’t described it very formally, so let me see if I can be more
precise:
On each node, in parallel:
On a
Chen
Cc: lsr@ietf.org
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology
Hi Huaimo,
Thank you, this is very clear.
It leaves me with one question: how is this better than what we have?
You’ve computed the backup paths: [R4, R3, R6, R7] and [R5, R2, R9, R8]. This
results
ing.
>
> The FT split is repaired. Refer to Fig. 6, FT partition A and partition B
> are connected by the links added to the FT temporarily.
>
> Best Regards,
> Huaimo
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
> Sent: Friday, April 19, 201
Hi Huaimo,
> I don’t think you can just assume that the network topology is not damaged in
> some way. After all, the FT partitioned because of real failures. Your
> algorithm for computing backup paths relies on old information about the
> topology of other partitions. That information
Hi Tony,
My explanations are inline below with prefix [HC].
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Monday, April 15, 2019 11:37 AM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology
Hi Huaimo
Hi Huaimo:
Thanks for replying, my comments in line prefaced with DA2>
1. The alternate backup path would appear to also require the criteria of
being link diverse with the FT if the goal is to protect against multiple
failures.
[HC]: Can you give some more details about
Hi Dave,
My explanations are inline below with prefix [HC2].
From: David Allan I [mailto:david.i.al...@ericsson.com]
Sent: Sunday, April 14, 2019 2:33 PM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: RE: [Lsr] Min Links for Multiple Failures on Flooding Topology
Hi Huaimo:
Replies are in line
Hi Huaimo,
> Consider the case that the multiple failures occur at almost the same time
> and there is no other failure following these multiple failures shortly. In
> this case, the backup paths will connect the live end nodes of the failures
> on the FT, and the FT partition is fixed. Note
rah Chen ; lsr@ietf.org
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology
Hi Huaimo,
Computing a whole backup path between two end nodes of a failure and enabling
temporary flooding at each hop of the path will guarantee that these two end
nodes are connected on the FT, t
Hi Huaimo:
Replies are in line….prefaced with DA>
1. The alternate backup path would appear to also require the criteria of
being link diverse with the FT if the goal is to protect against multiple
failures.
[HC]: Can you give some more details about this?
[DA] There is a
Hi guys,
I think that there’s some confusion here.
> 1) The alternate backup path would appear to also require the criteria
> of being link diverse with the FT if the goal is to protect against multiple
> failures.
>
> [HC]: Can you give some more details about this?
I think that
Hi Huaimo,
> Computing a whole backup path between two end nodes of a failure and enabling
> temporary flooding at each hop of the path will guarantee that these two end
> nodes are connected on the FT, thus the FT partition caused by multiple
> failures is fixed.
The backup path is not a
Hi Dave,
Thank you for your observations.
My explanations are inline below with prefix [HC].
>From: David Allan I [mailto:david.i.al...@ericsson.com]
>Sent: Friday, April 12, 2019 8:57 AM
>To: Huaimo Chen ; tony...@tony.li
>Cc: lsr@ietf.org
>Subject: RE: [Lsr] Min Links for Mu
: Thursday, April 11, 2019 2:29 PM
To: Huaimo Chen
Cc: tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology
Hi, Huaimo,
Why do we need to compute a whole backup path and enable flooding at each hop?
In your example, when R0-R2 and R3-R9 fail, R0
il.com] *On Behalf Of *
> tony...@tony.li
> *Sent:* Wednesday, April 10, 2019 10:00 PM
> *To:* Huaimo Chen
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Min Links for Multiple Failures on Flooding Topology
>
>
>
>
>
> Hi Huaimo,
>
>
>
> Thank you for the ex
t; Best Regards,
> Huaimo
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
> Sent: Tuesday, April 9, 2019 12:41 PM
> To: Huaimo Chen
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology
>
>
> Hi Huaimo,
&
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology
Hi Huaimo,
Thank you for your note. I have many questions, please see inline.
When multiple (i.e., two or more) failures on the current flooding topology (FT
for short) happen at almost the same time, the FT may be split even
Hi Huaimo,
Thank you for your note. I have many questions, please see inline.
> When multiple (i.e., two or more) failures on the current flooding topology
> (FT for short) happen at almost the same time, the FT may be split even
> though the real network topology is connected. A solution
Hi Everyone,
When multiple (i.e., two or more) failures on the current flooding topology (FT
for short) happen at almost the same time, the FT may be split even though the
real network topology is connected. A solution or procedure for fixing the FT
split is described below. It uses almost the
21 matches
Mail list logo
