Subject: question about draft-ietf-rtgwg-uloop-delay-02

From: [email-masked]
Date: Thu, 20 Oct 2016 17:03:22 +0800

Hi Stephane,

I find that section “4.4.2.  Link up event” of 
draft-litkowski-rtgwg-uloop-delay-04 has been removed. 
Does it mean that there is no need for this?

Thanks,
Deccan

---

From: <[email-masked]>
Date: Thu, 20 Oct 2016 12:33:39 +0000

Hi,

Achieving link up microloop avoidance with a local mechanism is only achievable by tweaking flooding (we need to converge locally, then flood local LSP update) which was not well received by the WG, that's why it was removed. The draft focus now on what has already been implemented by vendors and deployed in live networks.

Some other solutions like SR microloop avoidance will provide link up case at the "price" of having a SR-enabled network.

Brgds,

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 20, 2016 11:03
To: LITKOWSKI Stephane OBS/OINIS
Cc: [email-masked]; [email-masked]
Subject: question about draft-ietf-rtgwg-uloop-delay-02

Hi Stephane,

I find that section "4.4.2.  Link up event" of draft-litkowski-rtgwg-uloop-delay-04 has been removed.
Does it mean that there is no need for this?

Thanks,
Deccan

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 20 Oct 2016 13:51:30 +0100

On 20/10/2016 13:33, [email-masked] wrote:
>
> Hi,
>
> Achieving link up microloop avoidance with a local mechanism is only 
> achievable by tweaking flooding (we need to converge locally, then 
> flood local LSP update) which was not well received by the WG, that’s 
> why it was removed. The draft focus now on what has already been 
> implemented by vendors and deployed in live networks.
>

If it is in live networks, can you share with us how well it works, and 
what, if any, disruption you see under link up.

> Some other solutions like SR microloop avoidance will provide link up 
> case at the “price” of having a SR-enabled network.
>

You can do link up with SR, but SR is not required by all methods.

Stewart

> Brgds,
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Thursday, October 20, 2016 11:03
> *To:* LITKOWSKI Stephane OBS/OINIS
> *Cc:* [email-masked]; [email-masked]
> *Subject:* question about draft-ietf-rtgwg-uloop-delay-02
>
> Hi Stephane,
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: <[email-masked]>
Date: Thu, 20 Oct 2016 14:03:03 +0000

Hi Stewart,

For link down, we easily see the improvement as uloops were breaking FRR sometimes and now we do not see anymore breakage (traffic initiated from a probe connected to PLR).
For link up, we observed some traffic disruption in some cases but there is no tool to ensure that it comes from a microloop or something else: but the affected paths were subject to microloops (from theorical point of view) upon link up event of the failed link.
There is a clear lack of accurate tools today to identity microloops in live networks: having probes sending traffic at high rate is not enough, on labs we have analyzers to check packet TTL, but it's impossible to use in a live network for unplanned events ...

Brgds,

Stephane

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, October 20, 2016 14:52
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: question about draft-ietf-rtgwg-uloop-delay-02

On 20/10/2016 13:33, [email-masked]<mailto:[email-masked]> wrote:
Hi,

If it is in live networks, can you share with us how well it works, and what, if any, disruption you see under link up.

Stewart

Brgds,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, October 20, 2016 11:03
To: LITKOWSKI Stephane OBS/OINIS
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: question about draft-ietf-rtgwg-uloop-delay-02

Hi Stephane,

Thanks,
Deccan

Thank you.

rtgwg mailing list

[email-masked]<mailto:[email-masked]>