RE: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

<stephane.litkowski@orange.com> Thu, 31 October 2013 16:29 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 9E74E21F9F80 for <rtgwg@ietfa.amsl.com>; Thu, 31 Oct 2013 09:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.123
X-Spam-Level:
X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKotfEYe1xK5 for <rtgwg@ietfa.amsl.com>; Thu, 31 Oct 2013 09:29:13 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 153EB21F9F85 for <rtgwg@ietf.org>; Thu, 31 Oct 2013 09:29:12 -0700 (PDT)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id A7030C0682; Thu, 31 Oct 2013 17:29:10 +0100 (CET)
Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 8EEFA384072; Thu, 31 Oct 2013 17:29:10 +0100 (CET)
Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.46]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 31 Oct 2013 17:29:10 +0100
From: stephane.litkowski@orange.com
To: Pierre Francois <pierre.francois@imdea.org>, Alia Atlas <akatlas@gmail.com>
Date: Thu, 31 Oct 2013 17:29:07 +0100
Subject: RE: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00
Thread-Topic: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00
Thread-Index: Ac7WUuAwOPctbXsWSeax0xrwWsXJcgAA0ciw
Message-ID: <17617_1383236950_52728556_17617_2779_1_EEE55384044474429A926C625D0FCC8109902E3E05@PUEXCB2F.nanterre.francetelecom.fr>
References: <D496C972D1A13540A730720631EC73413A39ECE3@nkgeml507-mbs.china.huawei.com> <16236_1382529710_5267BAAE_16236_1925_1_EEE55384044474429A926C625D0FCC81098FE657D2@PUEXCB2F.nanterre.francetelecom.fr> <241747C2-51B7-4252-AEAE-5B65F0691A2C@imdea.org> <CAG4d1rf8z30swE2quka_f9o71Qd75DDphoKx+jeMttdS-S7K8Q@mail.gmail.com> <0D953FB7-A7CC-4224-9C83-5A8424AAB52B@imdea.org>
In-Reply-To: <0D953FB7-A7CC-4224-9C83-5A8424AAB52B@imdea.org>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC8109902E3E05PUEXCB2Fnante_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.31.151815
Cc: Yangang <yangang@huawei.com>, "Zhangxudong (zhangxudong, VRP)" <zhangxudong@huawei.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 31 Oct 2013 16:29:17 -0000

>I do not think this is a practical approach to apply after a FRR application.

+1, in term of operations, I would say that incremental metric would be applicable only for maintenance and may not for outages


De : Pierre Francois [mailto:pierre.francois@imdea.org]
Envoyé : jeudi 31 octobre 2013 17:04
À : Alia Atlas
Cc : LITKOWSKI Stephane DTF/DERX; rtgwg@ietf.org; Zhangxudong (zhangxudong, VRP); Yangang
Objet : Re: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

Alia,

Some corner cases here and there, but yes, Francois' code (Francois Clad, not me) computes these sequences in a ridiculously low amount of time, and the sequences tend to be very short even in large topologies.

I still think this should be investigated for maintenance cases and metric updates stemming out of a TE exercise.

I do not think this is a practical approach to apply after a FRR application.

Cheers,

Pierre.

On Oct 31, 2013, at 4:54 PM, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>> wrote:


Pierre,

Thanks for the updates.   Can you summarize?  Have the number of changes become few enough in general to be practical?

Alia

On Thu, Oct 31, 2013 at 11:49 AM, Pierre Francois <pierre.francois@imdea.org<mailto:pierre.francois@imdea.org>> wrote:
Stephane,

Much progress on the topic has been made since that much preliminary Infocom paper.
So here come more up-to-date reference points to compare:

Graceful Convergence in Link-State IP Networks
F. Clad, P. Mérindol, J.-J. Pansiot, P. Francois and O. Bonaventure
In IEEE/ACM Transactions on Networking, 2013

documents the most optimised algorithm known so far for the link shutdown case, with extensive simulation results and performance analysis.


Graceful Router Updates for Link-State Protocols
F. Clad, P. Mérindol, S. Vissicchio, J.-J. Pansiot and P. Francois
In proceedings of IEEE ICNP 2013, Göttingen, Germany, October 2013

provides an algorithm to do the same in the node shutdown case, smarter than doing one link after the other.

Cheers,

Pierre.





On Oct 23, 2013, at 2:01 PM, stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> wrote:


Hi,

I would need more time to review your algo part. But anyway, could you explain the difference with some old public approach like the paper from Pierre, Mike and Olivier :  http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.8263&rep=rep1&type=pdf

Moreover I would be interested to see in your draft some simulation proving the metric list is quite low ...
I can remember in the paper I'm referencing that the challenge was to compress the KMS list in order to prevent a very very long list which would not be applicable in a live network.

Thanks

Stephane



-----Message d'origine-----
De : rtgwg-bounces@ietf.org<mailto:rtgwg-bounces@ietf.org> [mailto:rtgwg-<mailto:rtgwg->bounces@ietf.org<mailto:bounces@ietf.org>] De la part de Yangang
Envoyé : lundi 21 octobre 2013 03:49
À : rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Cc : Zhangxudong (zhangxudong, VRP); Yangang
Objet : Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

Hi:

We had submitted the a new draft: http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, we want to discuss the micro-loop problem through another method. Your feedback and comments on the rtgwg mailing list are appreciated.

Thanks,
Rahul.Yan

-----邮件原件-----
发件人: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>]
发送时间: 2013年10月18日 15:47
收件人: Zhangxudong (zhangxudong, VRP); Yangang
主题: New Version Notification for draft-zxd-rtgwg-ordered-metric-adjustment-00.txt


A new version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt
has been successfully submitted by Xudong Zhang and posted to the
IETF repository.

Filename: draft-zxd-rtgwg-ordered-metric-adjustment
Revision: 00
Title: Algorithm for Ordered Metric Adjustment
Creation date: 2013-10-18
Group: Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjustment-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment
Htmlized:        http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00


Abstract:
  Upon link down event or link up event, each device in network
  individually schedules route calculation.  Because of different
  hardware capabilities and internal/external environments, the time to
  update forwarding entries on these devices are disordered which can
  cause a transient forwarding loop.  This document introduces a method
  to prevent forwarding loop by adjusting link metric gradually for
  several times.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

_______________________________________________
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.

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg


_______________________________________________
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.