IETF Logo Mail Archive

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

<stephane.litkowski@orange.com> Thu, 20 October 2016 14:03 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D2A129452 for <rtgwg@ietfa.amsl.com>; Thu, 20 Oct 2016 07:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.318
X-Spam-Level:
X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9a6xg5LofYC for <rtgwg@ietfa.amsl.com>; Thu, 20 Oct 2016 07:03:12 -0700 (PDT)
Received: from relais-inet.orange.com (relais-aub41.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57132129624 for <rtgwg@ietf.org>; Thu, 20 Oct 2016 07:03:06 -0700 (PDT)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 0A3431200BB; Thu, 20 Oct 2016 16:03:04 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id AB12A6006C; Thu, 20 Oct 2016 16:03:04 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 16:03:04 +0200
From: stephane.litkowski@orange.com
To: Stewart Bryant <stewart.bryant@gmail.com>, "peng.shaofu@zte.com.cn" <peng.shaofu@zte.com.cn>
Subject: RE: question about draft-ietf-rtgwg-uloop-delay-02
Thread-Topic: question about draft-ietf-rtgwg-uloop-delay-02
Thread-Index: AQHSKrD6JUg/qjcdlUq/UlHIIX+EB6CxRe2w///khQCAADEZAA==
Date: Thu, 20 Oct 2016 14:03:03 +0000
Message-ID: <5202_1476972184_5808CE98_5202_6659_1_9E32478DFA9976438E7A22F69B08FF921DB271CD@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <OF4AE091F6.5B59F0A7-ON48258052.00309A39-48258052.0031BC89@zte.com.cn> <7031_1476966820_5808B9A4_7031_144_4_9E32478DFA9976438E7A22F69B08FF921DB269CE@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <8e17550d-65bb-c697-cbb3-bb82fc12af71@gmail.com>
In-Reply-To: <8e17550d-65bb-c697-cbb3-bb82fc12af71@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921DB271CDOPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/pILATY4jAfANIelDe_AvAviYuFQ>
Cc: "chen.minyu@zte.com.cn" <chen.minyu@zte.com.cn>, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2016 14:03:17 -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:stewart.bryant@gmail.com]
Sent: Thursday, October 20, 2016 14:52
To: LITKOWSKI Stephane OBS/OINIS; peng.shaofu@zte.com.cn
Cc: chen.minyu@zte.com.cn; rtgwg@ietf.org
Subject: Re: question about draft-ietf-rtgwg-uloop-delay-02




On 20/10/2016 13:33, stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> 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: peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn> [mailto:peng.shaofu@zte.com.cn]
Sent: Thursday, October 20, 2016 11:03
To: LITKOWSKI Stephane OBS/OINIS
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; chen.minyu@zte.com.cn<mailto:chen.minyu@zte.com.cn>
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.




_______________________________________________

rtgwg mailing list

rtgwg@ietf.org<mailto:rtgwg@ietf.org>

https://www.ietf.org/mailman/listinfo/rtgwg


_________________________________________________________________________________________________________________________

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.

v2.23.0 | Report a Bug | By Email