From internet-drafts@ietf.org Mon May 13 06:09:57 2013 Return-Path: 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 297C421F95EE; Mon, 13 May 2013 06:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 3LtSU4Yu+X5O; Mon, 13 May 2013 06:09:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEA721F940D; Mon, 13 May 2013 06:09:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-lfa-manageability-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130513130956.15571.38029.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 06:09:56 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 13:09:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Operational management of Loop Free Alternates Author(s) : Stephane Litkowski Bruno Decraene Clarence Filsfils Kamran Raza Filename : draft-ietf-rtgwg-lfa-manageability-00.txt Pages : 16 Date : 2013-05-13 Abstract: Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From akatlas@gmail.com Mon May 13 17:10:05 2013 Return-Path: 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 D554021F84A6; Mon, 13 May 2013 17:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 DO2RNKSo39Yd; Mon, 13 May 2013 17:10:04 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C9D1021F95E0; Mon, 13 May 2013 17:10:01 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id i9so4426431iad.9 for ; Mon, 13 May 2013 17:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=PEGMz3MR+fwSL6ZilOovUqmcQ5mAZ/ybQ9l2ltuucRM=; b=0ZitNth2cSM0JyJwXiSROKla2ffelLp+h501YJZuKBbmOcnVEI8QDGaZf0VgfkFBEA T+15PqRZ6LGizsX3imu+n6vfA0niLF64zFMivfhQ8B6clNfaG5YcLJ0slTUg9fK6Zz2L Hp/9GPjwVzFeBYxWLsHf+kOm0fAaBNoMXl2OZ1Do5ENTvQGZtuH4oEVNvaZhkpiMiecB hre1ZD9pjDGSOnZKcmOqPYqZlAgKoNiWXGmnwJrfX964meF0MLcVijLN/4KyxjRMeyWc 6KHp3kR7GJs4Y2uxNdrEpABBwGB2KrqzxCW772iaNYzVzHtrt0rK3SbabW8i7g9wIzsO L1QA== MIME-Version: 1.0 X-Received: by 10.50.20.38 with SMTP id k6mr373685ige.50.1368490201362; Mon, 13 May 2013 17:10:01 -0700 (PDT) Received: by 10.64.24.170 with HTTP; Mon, 13 May 2013 17:10:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 May 2013 20:10:01 -0400 Message-ID: Subject: Fwd: [systers] Fwd: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence From: Alia Atlas To: "i2rs@ietf.org" , "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd7598a54cc2704dca27401 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 00:10:06 -0000 --047d7bd7598a54cc2704dca27401 Content-Type: text/plain; charset=ISO-8859-1 Please consider volunteering. Diversity in our NomCom volunteers is incredibly important. Particularly if you don't work for one of the standard large companies that usually has volunteers on NomCom, do think about it. I was on NomCom years ago and found it a very very valuable experience. Alia ---------- Forwarded message ---------- From: Mankin, Allison Date: Mon, May 13, 2013 at 4:27 PM Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence To: "ietf-announce@ietf.org" The IETF nominating committee (nomcom) process for 2013-14 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers! The details of the operation of the nomcom can be found in RFC 3777. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 16, 2013, as follows: To: amankin@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF! I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Allison Mankin amankin@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all the volunteer mail (and any questions/comments you may have) to the address given. _______________________________________________ systers mailing list systers@ietf.org https://www.ietf.org/mailman/listinfo/systers --047d7bd7598a54cc2704dca27401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please consider volunteering. =A0Diversity in our NomCom v= olunteers is incredibly important.
Particularly if you don't work f= or one of the standard large companies that usually has volunteers
on NomCom, do think about it. =A0I was on NomCom years ago and found it a v= ery very valuable
experience.

Alia
---------- Forwarded message ----------
From: Mankin, Allison <amankin@v= erisign.com>
Date: Mon, May 13, 2013 at 4:27 PM
Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in
first sentence
To: "ietf-announce@ietf.org<= /a>" <ietf-announce@ietf.= org>


The IETF nominating committee (nomcom) process for 2013-14 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB,
and the IESG. Ten voting members for the nomcom are selected in a verifiabl= y
random way from a pool of volunteers. The more volunteers, the better chanc= e
we have of choosing a random yet representative cross section of the IETF population. =A0This year, a challenge: =A0let's get beyond the 100-mark= for
number of volunteers. =A0Let's get to 200 volunteers!

The details of the operation of the nomcom can be found in RFC 3777.

Volunteers must have attended 3 of the past 5 IETF meetings. =A0As specifie= d in
RFC 3777, that means three out of the five past meetings up to the time thi= s
email announcement goes out to start the solicitation of volunteers. The fi= ve
meetings out of which you must have attended three are IETF 82, 83, 84, 85,= 86.

If you qualify, please volunteer. =A0However, much as we want this, before = you
decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible.

The list of people and posts whose terms end with the March 2014 IETF
meeting, and thus the positions for which this nomcom is responsible, are
IAOC:
Chris Griffiths

IAB:

Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG:

Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

The primary activity for this nomcom will begin in July 2013 and should be<= br> completed in January 2014. =A0The nomcom will have regularly scheduled
conference calls to ensure progress. =A0There will be activities to collect=
requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to
candidates. =A0Thus, being a nomcom member does require some time commitmen= t.

Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours)<= br> June 16, 2013, as follows:

To: amankin@verisign.com
Subject: Nomcom 2013-14 Volunteer

Please include the following information in the email body:

=A0<Your Full Name>
=A0 // First/Given Name followed by Last/Family Name
=A0 // matching how you enter it in the IETF Registration Form)
=A0<Current Primary Affiliation>
=A0 // Typically what goes in the Company field
=A0 // in the IETF Registration Form
[<All email addresses used to register for the past 5 IETF meetings>]=
=A0<Preferred email address>
=A0<Telephone number>
=A0 // For confirmation if selected

You should expect an email response from me within 3 business days stating<= br> whether or not you are qualified. =A0If you don't receive this response= ,
please re-send your email with the tag "RESEND"" added to th= e subject line.

If you are not yet sure if you would like to volunteer, please consider
that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute
to the IETF!

I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process,
within the next couple weeks.

Thank you!
Allison Mankin
amankin@verisign.com

P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf<= br> addresses for the nomcom chair or the nomcom committee yet, so please send<= br> all the volunteer mail (and any questions/comments you may have) to the
address given.
_______________________________________________
systers mailing list
systers@ietf.org
https://www.ietf.org/mailman/listinfo/systers

--047d7bd7598a54cc2704dca27401-- From akatlas@gmail.com Tue May 14 12:10:23 2013 Return-Path: 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 1152D21F84DC for ; Tue, 14 May 2013 12:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 RlJwQNHPWbPC for ; Tue, 14 May 2013 12:10:22 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D0F2821F850B for ; Tue, 14 May 2013 12:10:21 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so1889659iea.31 for ; Tue, 14 May 2013 12:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Z/lEO0dpykXZLN8XSusiMDbUIot7MfX6JJMU5so8YGU=; b=EMzqNp5Srq7OJWPo2QsjUo4KFHMBUFU09ipHu5NR4zmSyRDAKDAwxh0sCoU3SMIxtu ljawEVdEnbBehGQtOm9l8EHDUghYdaivLNAhrEUekpB4j2RwyVilgHX+aI7OM+VPyySG m2tbBR9tINCR5yEnGI94mKkkeyFA7IGTI7q4ar1W/PZlYjlWIZmDbAdJcKiJc5y2/ZEb wpJxiONHZjcUI8ep3C36Sqtv/YMy3vdxK62wnxizF2w3Yi/vnj2iD/uq5HRtVVfqvgiI ZLLDn4gPXls9wfYAZasZO+eSBDzfxR9w0fso9elXCjOekLE2Y51RstGY5mG8fgtmtbGa 5AKw== MIME-Version: 1.0 X-Received: by 10.50.78.34 with SMTP id y2mr3225102igw.50.1368558621434; Tue, 14 May 2013 12:10:21 -0700 (PDT) Received: by 10.64.24.170 with HTTP; Tue, 14 May 2013 12:10:21 -0700 (PDT) Date: Tue, 14 May 2013 15:10:21 -0400 Message-ID: Subject: any IPR on draft-ietf-rtgwg-cl-use-cases? From: Alia Atlas To: "rtgwg@ietf.org" , draft-ietf-rtgwg-cl-use-cases@tools.ietf.org Content-Type: multipart/alternative; boundary=089e01160a1a7c2c7604dcb262c6 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 19:10:23 -0000 --089e01160a1a7c2c7604dcb262c6 Content-Type: text/plain; charset=ISO-8859-1 In preparation for a WG Last Call, could the authors please send to the mailing list whether they are aware of any IPR associated with draft-ietf-rtgwg-cl-use-cases? Everyone else, if you know of any IPR, please send it to the list also. If you're not sure - read the draft ;-) thanks, Alia --089e01160a1a7c2c7604dcb262c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In preparation for a WG Last Call, could the authors pleas= e send to the mailing list whether they are aware of any IPR associated wit= h draft-ietf-rtgwg-cl-use-cases?

Everyone else, if= you know of any IPR, please send it to the list also. =A0If you're not= sure - read the draft ;-)

thanks,
Alia
--089e01160a1a7c2c7604dcb262c6-- From andrew.g.malis@verizon.com Tue May 14 12:13:47 2013 Return-Path: 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 B5D3121F9057 for ; Tue, 14 May 2013 12:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 agdZXFDgtiNo for ; Tue, 14 May 2013 12:13:41 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5397021F901A for ; Tue, 14 May 2013 12:13:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe03.verizon.com with ESMTP; 14 May 2013 19:13:39 +0000 From: "Malis, Andrew G \(Andy\)" X-IronPort-AV: E=Sophos;i="4.87,671,1363132800"; d="scan'208,217";a="470407918" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi02.verizon.com with ESMTP; 14 May 2013 19:13:39 +0000 Received: from fhdp1lumxc7v22.us.one.verizon.com ([166.68.59.158]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Tue, 14 May 2013 15:13:38 -0400 To: Alia Atlas , "rtgwg@ietf.org" , "draft-ietf-rtgwg-cl-use-cases@tools.ietf.org" Date: Tue, 14 May 2013 15:13:37 -0400 Subject: Re: any IPR on draft-ietf-rtgwg-cl-use-cases? Thread-Topic: any IPR on draft-ietf-rtgwg-cl-use-cases? Thread-Index: Ac5Q1yNhX1v4/WKESTeIgZ3lCneTtg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CDB8051B40D01andrewgmalisoneverizoncom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 14 May 2013 12:16:09 -0700 Cc: "Malis, Andrew G \(Andy\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 19:13:47 -0000 --_000_CDB8051B40D01andrewgmalisoneverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alia, I'm not aware of any IPR on this draft. Cheers, Andy From: Alia Atlas > Date: Tuesday, May 14, 2013 15:10 To: "rtgwg@ietf.org" >, "draft-ietf-rtgwg-cl-use-cases@tools.ietf.org" > Subject: any IPR on draft-ietf-rtgwg-cl-use-cases? Resent-To: Andrew Malis >, >, >, >, > In preparation for a WG Last Call, could the authors please send to the mai= ling list whether they are aware of any IPR associated with draft-ietf-rtgw= g-cl-use-cases? Everyone else, if you know of any IPR, please send it to the list also. If= you're not sure - read the draft ;-) thanks, Alia --_000_CDB8051B40D01andrewgmalisoneverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Alia,
I'm not aware of any IPR on this draft.

Cheers,
Andy


= In preparation for a WG Last Call, could the authors please send to the mai= ling list whether they are aware of any IPR associated with draft-ietf-rtgw= g-cl-use-cases?

Everyone else, if you know of any IPR, pleas= e send it to the list also.  If you're not sure - read the draft ;-)

thanks,
Alia
<= /div>
--_000_CDB8051B40D01andrewgmalisoneverizoncom_-- From Ning.So@tatacommunications.com Tue May 14 12:31:07 2013 Return-Path: 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 24ABA21F8F3E for ; Tue, 14 May 2013 12:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 IhoTUugzNqIa for ; Tue, 14 May 2013 12:31:00 -0700 (PDT) Received: from vmx3.tatacommunications.com (vmx3.tatacommunications.com [66.198.167.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E221F8E7C for ; Tue, 14 May 2013 12:30:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,671,1363147200"; d="scan'208,217";a="283554174" Received: from unknown (HELO wv1-cas-02.vsnl.co.in) ([64.86.157.138]) by mx3-2.tatacommunications.com with ESMTP; 14 May 2013 15:30:53 -0400 Received: from USWV1VCAS02.vsnl.co.in (64.86.157.180) by wv1-cas-02.vsnl.co.in (64.86.157.138) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 14 May 2013 15:30:54 -0400 Received: from USWV1VDAG02.vsnl.co.in ([fe80::7c6a:fd71:7022:40b6]) by uswv1vcas02.vsnl.co.in ([fe80::14e7:a24:f48:e268%12]) with mapi id 14.02.0309.002; Tue, 14 May 2013 15:30:53 -0400 From: Ning So To: Alia Atlas , "rtgwg@ietf.org" , "draft-ietf-rtgwg-cl-use-cases@tools.ietf.org" Subject: RE: any IPR on draft-ietf-rtgwg-cl-use-cases? Thread-Topic: any IPR on draft-ietf-rtgwg-cl-use-cases? Thread-Index: AQHOUNbEVMFJKoKSNkSg5AVZPuRBG5kFEJgA Date: Tue, 14 May 2013 19:30:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.86.157.8] Content-Type: multipart/alternative; boundary="_000_F03A6CD051CB7946A6E58423E26D99A970F6A68Buswv1vdag02vsnl_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 14 May 2013 12:32:57 -0700 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 19:31:07 -0000 --_000_F03A6CD051CB7946A6E58423E26D99A970F6A68Buswv1vdag02vsnl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR associated with the draft. I am aware of a couple CL IPR. They are related to specific CL solution/im= plementation, and have no claims impacting the stated draft here. Best regards, Ning So Head of Network Architecture Mobile Broadband Services Tata Communications (Cell) 972-955-0914 From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Tuesday, May 14, 2013 2:10 PM To: rtgwg@ietf.org; draft-ietf-rtgwg-cl-use-cases@tools.ietf.org Subject: any IPR on draft-ietf-rtgwg-cl-use-cases? In preparation for a WG Last Call, could the authors please send to the mai= ling list whether they are aware of any IPR associated with draft-ietf-rtgw= g-cl-use-cases? Everyone else, if you know of any IPR, please send it to the list also. If= you're not sure - read the draft ;-) thanks, Alia --_000_F03A6CD051CB7946A6E58423E26D99A970F6A68Buswv1vdag02vsnl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR= associated with the draft.

 <= /p>

I am aware of a couple CL= IPR.  They are related to specific CL solution/implementation, and ha= ve no claims impacting the stated draft here. 

 <= /p>

Best regar= ds,

 = ;

Ning So

Head of Ne= twork Architecture

Mobile Bro= adband Services

Tata Commu= nications

(Cell) 972= -955-0914

 <= /p>

From: Alia Atl= as [mailto:akatlas@gmail.com]
Sent: Tuesday, May 14, 2013 2:10 PM
To: rtgwg@ietf.org; draft-ietf-rtgwg-cl-use-cases@tools.ietf.org
Subject: any IPR on draft-ietf-rtgwg-cl-use-cases?=

 

In preparation for a WG Last Call, could the authors= please send to the mailing list whether they are aware of any IPR associat= ed with draft-ietf-rtgwg-cl-use-cases?

 

Everyone else, if you know of any IPR, please send i= t to the list also.  If you're not sure - read the draft ;-)

 

thanks,

Alia

--_000_F03A6CD051CB7946A6E58423E26D99A970F6A68Buswv1vdag02vsnl_-- From lucy.yong@huawei.com Tue May 14 13:22:26 2013 Return-Path: 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 4376321F90FD for ; Tue, 14 May 2013 13:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 EDWeSJb-D0y9 for ; Tue, 14 May 2013 13:22:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DC78921F8F43 for ; Tue, 14 May 2013 13:22:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASU42602; Tue, 14 May 2013 20:22:16 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 21:21:42 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 21:22:11 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.204]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 14 May 2013 13:22:06 -0700 From: Lucy yong To: Alia Atlas , "rtgwg@ietf.org" , "draft-ietf-rtgwg-cl-use-cases@tools.ietf.org" Subject: RE: any IPR on draft-ietf-rtgwg-cl-use-cases? Thread-Topic: any IPR on draft-ietf-rtgwg-cl-use-cases? Thread-Index: AQHOUNa6zg1DoTBl9kOedJp9D/f9jpkFH5eg Date: Tue, 14 May 2013 20:22:05 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4525B54E@dfweml509-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.173] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4525B54Edfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 20:22:26 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4525B54Edfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of an IPR related to this draft. Lucy From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Tuesday, May 14, 2013 2:10 PM To: rtgwg@ietf.org; draft-ietf-rtgwg-cl-use-cases@tools.ietf.org Subject: any IPR on draft-ietf-rtgwg-cl-use-cases? In preparation for a WG Last Call, could the authors please send to the mai= ling list whether they are aware of any IPR associated with draft-ietf-rtgw= g-cl-use-cases? Everyone else, if you know of any IPR, please send it to the list also. If= you're not sure - read the draft ;-) thanks, Alia --_000_2691CE0099834E4A9C5044EEC662BB9D4525B54Edfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of  a= n IPR related to this draft.

 <= /p>

Lucy

 <= /p>

From: Alia Atl= as [mailto:akatlas@gmail.com]
Sent: Tuesday, May 14, 2013 2:10 PM
To: rtgwg@ietf.org; draft-ietf-rtgwg-cl-use-cases@tools.ietf.org
Subject: any IPR on draft-ietf-rtgwg-cl-use-cases?=

 

In preparation for a WG Last Call, could the authors= please send to the mailing list whether they are aware of any IPR associat= ed with draft-ietf-rtgwg-cl-use-cases?

 

Everyone else, if you know of any IPR, please send i= t to the list also.  If you're not sure - read the draft ;-)

 

thanks,

Alia

--_000_2691CE0099834E4A9C5044EEC662BB9D4525B54Edfweml509mbxchi_-- From pierre.francois@imdea.org Mon May 20 04:57:49 2013 Return-Path: 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 8648C21F90D2 for ; Mon, 20 May 2013 04:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 OeUjTTOBSihd for ; Mon, 20 May 2013 04:57:44 -0700 (PDT) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 35B4021F9123 for ; Mon, 20 May 2013 04:57:42 -0700 (PDT) Received: from localhost (estafeta22.imdea.org [172.17.99.146]) by estafeta22.imdea.org (Postfix) with ESMTP id DBFE125D9C8; Mon, 20 May 2013 13:57:40 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.146]) by localhost (estafeta22.imdea.org [172.17.99.146]) (amavisd-new, port 10024) with ESMTP id 2PQgvDNAME7b; Mon, 20 May 2013 13:57:40 +0200 (CEST) Received: from dhcp-10-61-98-65.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta22.imdea.org (Postfix) with ESMTP id 60B1425D9C7; Mon, 20 May 2013 13:57:40 +0200 (CEST) From: Pierre Francois Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Progressing with draft-litkowski-rtgwg-uloop-delay-00 ? Date: Mon, 20 May 2013 13:57:39 +0200 Message-Id: <830E8EED-9BBB-4E58-8C17-BBA721B114D3@imdea.org> To: "rtgwg@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 11:57:49 -0000 Dear rtgwg list members,=20 I would like to know your opinion about what we should do with = http://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-00 , that = we presented in Orlando.=20 The idea was to avoid microloops occurring in the direct neighbourhood = of a node shutting down or bringing up a link in an IGP topology, by = introducing some fixed delay in the update of the FIB in the down case, and introducing a = fixed delay in the propagation of the LSP describing the link as up in = the up case.=20 The solution is simple, will be released by some in the upcoming months, = and the Orlando audience was seeming to find it interesting to work on. Alia mentioned the interest of comparing this solution with the state of = the art before going further with the doc, so here it comes.=20 Generally, compared to other solutions, local-delay does not provide = full coverage, as it only avoids all (but only) microloops occurring = locally to the affected node. However,=20 in many networks, as shown by Stephane's analysis, it is already highly = beneficial to have loop avoidance there. Considering the simplicity of = the approach,=20 this looks like a low hanging fruit.=20 Alia was considering a comparison with PLSN. (described in = http://tools.ietf.org/html/draft-ietf-rtgwg-microloop-analysis-01, = expired 7 years ago ;) ) The differences with the PLSN approach are the following:=20 PLSN lets all routers having to converge for some destinations, try to = understand the safety of their new next hops, for each destination. Based on this assessment, they either=20 1. Transiently use a safe, non post-convergence, set of next hops, to = finally converge to the post-convergence one, or 2. Transiently use old next-hops, to finally converge to the = post-convergence ones.=20 Local delay can be defined as a subset of this approach:=20 Only the node local to the event applies the procedure.=20 Step 1 in PLSN is not applied, we only suggest the node to wait for a = fixed time, no transient FIB state.=20 I was considering a comparison with oFIB, draft-ietf-rtgwg-ordered-fib , = submitted to IESG as informational.=20 local-delay can be defined as a subset of this approach: While oFIB defines an ordering among all the nodes of the network, = telling which node should wait for which neighbours to be done with = their update, before performing their own, local-delay tells the local = node to wait before fast convergence has happened in the rest of the = network. I think that despite the close relationships between these approaches, = local-delay is worth being documented on its own because: It's simple, on its way to be supported, and provides loop avoidance = where they happen to be the most annoying. =20 Cheers, Pierre. From akatlas@gmail.com Mon May 20 08:04:10 2013 Return-Path: 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 64DC721F9354 for ; Mon, 20 May 2013 08:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 AzCdXuqbhsFy for ; Mon, 20 May 2013 08:04:09 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id D1B5F21F933B for ; Mon, 20 May 2013 08:04:07 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id b11so13573869iee.23 for ; Mon, 20 May 2013 08:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+HZq2oFnicd8bDOAgjQQLPKzjV9Ts4DMAjJjVoMEP0I=; b=QwrJuytdsWxSNI6FM4XcEJ86w522TVPaEAio5BbvUJtJFi1LNvTpd6f2tgVpTgq56b wop5arDAnlYEymtKr4IZu6ijDiCXDyPHaNXY/xEfK00fGdkiIKsd2wz9TbyNWKW3tEff ToWKtCgzpi/6A6FJfCB1vaeU7XUpPk5csSGFrDxaxdjBdUgyl5BmqRq8hnkCcRvlXYtd JRDZIFkYleBJpSn/Ln7w8NqGrzoqiDrCE0w+eP2sxlLFgAjS62aYM+dqy99zmbODEbit PpnfXmAe1tMjgYCPNUUrMfLqVa7K5A29z/zNmgqCTdvtKzuI/G3H8hbr3+pPeEKqvioa OAwg== MIME-Version: 1.0 X-Received: by 10.42.53.129 with SMTP id n1mr32417083icg.28.1369062247410; Mon, 20 May 2013 08:04:07 -0700 (PDT) Received: by 10.64.24.170 with HTTP; Mon, 20 May 2013 08:04:07 -0700 (PDT) In-Reply-To: <830E8EED-9BBB-4E58-8C17-BBA721B114D3@imdea.org> References: <830E8EED-9BBB-4E58-8C17-BBA721B114D3@imdea.org> Date: Mon, 20 May 2013 11:04:07 -0400 Message-ID: Subject: Re: Progressing with draft-litkowski-rtgwg-uloop-delay-00 ? From: Alia Atlas To: Pierre Francois Content-Type: multipart/alternative; boundary=20cf302235d9eeb6c704dd27a4ca Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 15:04:10 -0000 --20cf302235d9eeb6c704dd27a4ca Content-Type: text/plain; charset=ISO-8859-1 Hi Pierre, Thank you for starting the conversation and a quick intro on the differences. When I look at this draft and PLSN, what I see is that the PLR is definitionally either a type B router (since it has an alternate that is safe for forwarding traffic or for link up it's old primary) and that the PLR is then the only router to apply the basic procedure. However, the PLR may not have an alternate available, unless MRT is used. As draft-ietf-rtgwg-microloop-analysis-01 says in Sec 3.3: " Another distinct situation is when the router does not support IPFRR or could not repair the failure, the new primary next-hops do not satisfy the safety condition, and there's no other neighbor that does, i.e. a type-C situation. Unlike other routers in the network, the router directly connected to the network does not have the old next-hop any more, and cannot continue using it. Immediately switching to the new next-hops, on the other hand, may result in a micro-loop. In this situation, the router MUST discard traffic forwarded along the affected route for the duration of DELAY_TYPEC, and then update the routes. Implementations MAY have a configuration option to allow switching immediately to the new next-hops for situations where this type of a micro-loop is not a concern. If implemented, this option MUST be disabled by default." Granted, this discarding becomes the default behavior for draft-litkowski-rtgwg-uloop-delay-00, but the reasoning and trade-offs are not discussed. In the analysis given in draft-litkowski-rtgwg-uloop-delay-00, the benefit discussed is only in terms of local microloops and completely ignores non-local microloops. I know that this particular technique is not solving the remote microloops problem - but those are a real problem and without even attempting to characterize that, there's little way of telling whether the local microloops are 1% of the problem or 99%. That the technique can apply when only the PLR does it is not as interesting as having a more general technique that works for traffic from routers that implement it and does not cause problems. Obviously, the WG debated this issue quite some time ago and was willing to go for a simpler partial solution (PLSN) over OFIB that gave similar coverage to RLFA. Is your current argument that this even simpler and more partial a solution might gain some traction? Or is it that this was simpler to implement and provides some mitigation? In addition to lacking any guidance on the scale of the total problem that it solves, the draft also lacks details to handle the cases where the network hasn't been stable. Granted, the latter is not deeply complex - but the solution isn't safely usable without it. I think that we as a WG need to do 4 things: a) Understand the scope of the total microloop problem and what fraction of this that draft-litkowski-rtgwg-uloop-delay-00 actually can solve. Does it handle asymmetric link-costs and multi-hop micro-loops? Better examples of what types of local microloops are handled and why other types aren't protected would be useful. How would an operator be certain as to what protection would be provided or how to engineer a network to obtain it? b) Have a draft that fully describes the problem, the trade-offs, and the solution in detail rather than just a brief conceptual overview. c) Understand the computation and complexity trade-offs between the different solutions - given that LFA is already assumed for it to be useful. d) Discuss how partial a solution is desirable to standardize and the pros/cons of having a worse solution standardized. Implementations aren't free - and by standardizing a more partial solution, this can delay implementations of a better solution. I understand the desire to standardize something and to take something that seems straightforward and is likely useful to at least one network, but given the WG track record, at a minimum, I think we must have a more complete draft that fully documents the solution in detail and compares it fairly. Regards, Alia On Mon, May 20, 2013 at 7:57 AM, Pierre Francois wrote: > > > Dear rtgwg list members, > > I would like to know your opinion about what we should do with > http://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-00 , that we > presented in Orlando. > > The idea was to avoid microloops occurring in the direct neighbourhood of > a node shutting down or bringing up a link in an IGP topology, by > introducing some > fixed delay in the update of the FIB in the down case, and introducing a > fixed delay in the propagation of the LSP describing the link as up in the > up case. > > The solution is simple, will be released by some in the upcoming months, > and the Orlando audience was seeming to find it interesting to work on. > > Alia mentioned the interest of comparing this solution with the state of > the art before going further with the doc, so here it comes. > > Generally, compared to other solutions, local-delay does not provide full > coverage, as it only avoids all (but only) microloops occurring locally to > the affected node. However, > in many networks, as shown by Stephane's analysis, it is already highly > beneficial to have loop avoidance there. Considering the simplicity of the > approach, > this looks like a low hanging fruit. > > Alia was considering a comparison with PLSN. (described in > http://tools.ietf.org/html/draft-ietf-rtgwg-microloop-analysis-01, > expired 7 years ago ;) ) > > The differences with the PLSN approach are the following: > > PLSN lets all routers having to converge for some destinations, try to > understand the safety of their new next hops, for each destination. > Based on this assessment, they either > > 1. Transiently use a safe, non post-convergence, set of next hops, to > finally converge to the post-convergence one, or > 2. Transiently use old next-hops, to finally converge to the > post-convergence ones. > > Local delay can be defined as a subset of this approach: > Only the node local to the event applies the procedure. > Step 1 in PLSN is not applied, we only suggest the node to wait for a > fixed time, no transient FIB state. > > I was considering a comparison with oFIB, draft-ietf-rtgwg-ordered-fib , > submitted to IESG as informational. > local-delay can be defined as a subset of this approach: > > While oFIB defines an ordering among all the nodes of the network, telling > which node should wait for which neighbours to be done with their update, > before performing their own, local-delay tells the local node to wait > before fast convergence has happened in the rest of the network. > > I think that despite the close relationships between these approaches, > local-delay is worth being documented on its own because: > > It's simple, on its way to be supported, and provides loop avoidance where > they happen to be the most annoying. > > Cheers, > > Pierre. > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --20cf302235d9eeb6c704dd27a4ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pierre,

Thank you for sta= rting the conversation and a quick intro on the differences.

When I look at this draft and PLSN, what I see is th= at the PLR is definitionally either a type B router (since
it has an alternate that is safe for forwarding traffic or for l= ink up it's old primary) and that the PLR is then the
o= nly router to apply the basic procedure. =A0However, the PLR may not have a= n alternate available, unless MRT is used.

As=A0draft-ietf-rtgwg-microloop-analysis-01= says in Sec 3.3:

" Another distinct situation is when the = router does not support IPFRR=A0or could not repair the failure, the new primary next-hops do no= t=A0satisfy the safet= y condition, and there's no other neighbor that=A0does, i.e. a type-C situation. Unlike othe= r routers in the network,=A0the router directly connected to the network does not have the old n= ext-hop any more, and cannot continue using it. Immediately switching to th= e new next-hops, on the other hand, may result in a micro-loop. In this sit= uation, the router MUST discard traffic forwarded along the affected route = for the duration of DELAY_TYPEC, and then update the routes. Implementation= s MAY have a configuration option to allow switching immediately to the new= next-hops for situations where this type of a micro-loop is not a concern.= If implemented, this option MUST be disabled by default."

Granted, this discarding becomes the defaul= t behavior for=A0draft-litkowski-rtgwg-uloop-delay-00, but the reasoning an= d trade-offs are not discussed.

In the= analysis given in=A0draft-litkowski-rtgwg-uloop-delay-00, the benefit disc= ussed is only in terms of local
microloops and completely ignores non-local microloops. =A0I kno= w that this particular technique is not solving
the remote = microloops problem - but those are a real problem and without even attempti= ng to characterize that,
there's little way of telling whether the local microloops a= re 1% of the problem or 99%.

That the = technique can apply when only the PLR does it is not as interesting as havi= ng a more general technique=A0
that works for traffic from routers that implement it and does n= ot cause problems.

Obviously, the WG d= ebated this issue quite some time ago and was willing to go for a simpler p= artial solution (PLSN)
over OFIB that gave similar coverage to RLFA.
Is your current argument that this even simpler and more= partial a solution might gain some traction? =A0Or is it that this
was simpler to implement and provides some mitigation?

In addition to lacking any guidance on the scal= e of the total problem that it solves, the draft also lacks details to hand= le
the cases where the network hasn't been stable. =A0Granted, = the latter is not deeply complex - but the solution isn't safely
<= div style>usable without it.

I t= hink that we as a WG need to do 4 things:
=A0 =A0 a) Understand the scope of the total microloop problem a= nd what fraction of this that=A0draft-litkowski-rtgwg-uloop-delay-00 actual= ly can solve. =A0 Does it handle asymmetric link-costs and multi-hop micro-= loops? =A0Better examples of what types of local microloops are handled and= why other types aren't protected would be useful. =A0How would an oper= ator be certain as to what protection would be provided or how to engineer = a network to obtain it? =A0
=A0 =A0 b) Have a draft that fully describes the problem, the tr= ade-offs, and the solution in detail rather than just a brief conceptual ov= erview.
=A0 =A0 c) Understand the computation and complexit= y trade-offs between the different solutions - given that LFA is already as= sumed for it to be useful.
=A0 =A0 d) Discuss how partial a solution is desirable to standa= rdize and the pros/cons of having a worse solution standardized. =A0 Implem= entations aren't free - and by standardizing a more partial solution, t= his can delay implementations of a better solution.

I understand the desire to standardize some= thing and to take something that seems straightforward and is likely useful= to at least one network, but given the WG track record, at a minimum, I th= ink we must have a more complete draft that fully documents the solution in= detail and compares it fairly.=A0

Regards,
Alia


On Mon, May 20,= 2013 at 7:57 AM, Pierre Francois <pierre.francois@imdea.org&g= t; wrote:


Dear rtgwg list members,

I would like to know your opinion about what we should do with http://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-00 = , that we presented in Orlando.

The idea was to avoid microloops occurring in the direct neighbourhood of a= node shutting down or bringing up a link in an IGP topology, by introducin= g some
fixed delay in the update of the FIB in the down case, and introducing a fi= xed delay in the propagation of the LSP describing the link as up in the up= case.

The solution is simple, will be released by some in the upcoming months, an= d the Orlando audience was seeming to find it interesting to work on.

Alia mentioned the interest of comparing this solution with the state of th= e art before going further with the doc, so here it comes.

Generally, compared to other solutions, local-delay does not provide full c= overage, as it only avoids all (but only) =A0microloops occurring locally t= o the affected node. However,
in many networks, as shown by Stephane's analysis, it is already highly= beneficial to have loop avoidance there. Considering the simplicity of the= approach,
this looks like a low hanging fruit.

Alia was considering a comparison =A0with PLSN. (described in http://tools.ietf.org/html/draft-ietf-rtgwg-microloop-analysis-01, expired 7 years ago ;) )

The differences with the PLSN approach are the following:

PLSN lets all routers having to converge for some destinations, try to unde= rstand the safety of their new next hops, for each destination.
Based on this assessment, they either

1. Transiently use a safe, non post-convergence, set of next hops, to final= ly converge to the post-convergence one, or
2. Transiently use old next-hops, to finally converge to the post-convergen= ce ones.

Local delay can be defined as a subset of this approach:
Only the node local to the event applies the procedure.
Step 1 in PLSN is not applied, we only suggest the node to wait for a fixed= time, no transient FIB state.

I was considering a comparison with oFIB, draft-ietf-rtgwg-ordered-fib , su= bmitted to IESG as informational.
local-delay can be defined as a subset of this approach:

While oFIB defines an ordering among all the nodes of the network, telling = which node should wait for which neighbours to be done with their update, b= efore performing their own, local-delay tells the local node to wait before= fast convergence has happened in the rest of the network.

I think that despite the close relationships between these approaches, loca= l-delay is worth being documented on its own because:

It's simple, on its way to be supported, and provides loop avoidance wh= ere they happen to be the most annoying.

Cheers,

Pierre.


_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg

--20cf302235d9eeb6c704dd27a4ca-- From pierre.francois@imdea.org Mon May 20 08:27:48 2013 Return-Path: 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 A388221F93BF for ; Mon, 20 May 2013 08:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 sA-s8UP3gtNK for ; Mon, 20 May 2013 08:27:43 -0700 (PDT) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id F06A221F8F12 for ; Mon, 20 May 2013 08:27:42 -0700 (PDT) Received: from localhost (estafeta21.imdea.org [172.17.99.144]) by estafeta21.imdea.org (Postfix) with ESMTP id 0B60F18AA02; Mon, 20 May 2013 17:27:43 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.144]) by localhost (estafeta21.imdea.org [172.17.99.144]) (amavisd-new, port 10024) with ESMTP id VWR17Ptls6iG; Mon, 20 May 2013 17:27:42 +0200 (CEST) Received: from [192.168.1.60] (rosnet.u-strasbg.fr [130.79.48.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (Postfix) with ESMTP id 8645918AA01; Mon, 20 May 2013 17:27:42 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0DF5ABBD-E6D3-4E82-BC4E-66933124CD8D" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Progressing with draft-litkowski-rtgwg-uloop-delay-00 ? From: Pierre Francois In-Reply-To: Date: Mon, 20 May 2013 17:27:40 +0200 Message-Id: References: <830E8EED-9BBB-4E58-8C17-BBA721B114D3@imdea.org> To: Alia Atlas X-Mailer: Apple Mail (2.1503) Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 15:27:48 -0000 --Apple-Mail=_0DF5ABBD-E6D3-4E82-BC4E-66933124CD8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Alia,=20 Thanks for your quick feedback.=20 Let me check with my co-authors on whether we should change the doc to = answer your comments and come back=20 for a discussion based on ink-on-paper, or answer on the list. I am = afraid of a never-ending thread for the later :) Cheers, Pierre. On May 20, 2013, at 5:04 PM, Alia Atlas wrote: > Hi Pierre, >=20 > Thank you for starting the conversation and a quick intro on the = differences. >=20 > When I look at this draft and PLSN, what I see is that the PLR is = definitionally either a type B router (since > it has an alternate that is safe for forwarding traffic or for link up = it's old primary) and that the PLR is then the > only router to apply the basic procedure. However, the PLR may not = have an alternate available, unless MRT is used. >=20 > As draft-ietf-rtgwg-microloop-analysis-01 says in Sec 3.3: >=20 > " Another distinct situation is when the router does not support IPFRR = or could not repair the failure, the new primary next-hops do not = satisfy the safety condition, and there's no other neighbor that does, = i.e. a type-C situation. Unlike other routers in the network, the router = directly connected to the network does not have the old next-hop any = more, and cannot continue using it. Immediately switching to the new = next-hops, on the other hand, may result in a micro-loop. In this = situation, the router MUST discard traffic forwarded along the affected = route for the duration of DELAY_TYPEC, and then update the routes. = Implementations MAY have a configuration option to allow switching = immediately to the new next-hops for situations where this type of a = micro-loop is not a concern. If implemented, this option MUST be = disabled by default." >=20 > Granted, this discarding becomes the default behavior for = draft-litkowski-rtgwg-uloop-delay-00, but the reasoning and trade-offs = are not discussed. >=20 > In the analysis given in draft-litkowski-rtgwg-uloop-delay-00, the = benefit discussed is only in terms of local > microloops and completely ignores non-local microloops. I know that = this particular technique is not solving > the remote microloops problem - but those are a real problem and = without even attempting to characterize that, > there's little way of telling whether the local microloops are 1% of = the problem or 99%. >=20 > That the technique can apply when only the PLR does it is not as = interesting as having a more general technique=20 > that works for traffic from routers that implement it and does not = cause problems. >=20 > Obviously, the WG debated this issue quite some time ago and was = willing to go for a simpler partial solution (PLSN) > over OFIB that gave similar coverage to RLFA. >=20 > Is your current argument that this even simpler and more partial a = solution might gain some traction? Or is it that this > was simpler to implement and provides some mitigation? >=20 > In addition to lacking any guidance on the scale of the total problem = that it solves, the draft also lacks details to handle > the cases where the network hasn't been stable. Granted, the latter = is not deeply complex - but the solution isn't safely > usable without it. >=20 > I think that we as a WG need to do 4 things: > a) Understand the scope of the total microloop problem and what = fraction of this that draft-litkowski-rtgwg-uloop-delay-00 actually can = solve. Does it handle asymmetric link-costs and multi-hop micro-loops? = Better examples of what types of local microloops are handled and why = other types aren't protected would be useful. How would an operator be = certain as to what protection would be provided or how to engineer a = network to obtain it? =20 > b) Have a draft that fully describes the problem, the trade-offs, = and the solution in detail rather than just a brief conceptual overview. > c) Understand the computation and complexity trade-offs between = the different solutions - given that LFA is already assumed for it to be = useful. > d) Discuss how partial a solution is desirable to standardize and = the pros/cons of having a worse solution standardized. Implementations = aren't free - and by standardizing a more partial solution, this can = delay implementations of a better solution. >=20 > I understand the desire to standardize something and to take something = that seems straightforward and is likely useful to at least one network, = but given the WG track record, at a minimum, I think we must have a more = complete draft that fully documents the solution in detail and compares = it fairly.=20 >=20 > Regards, > Alia >=20 >=20 > On Mon, May 20, 2013 at 7:57 AM, Pierre Francois = wrote: >=20 >=20 > Dear rtgwg list members, >=20 > I would like to know your opinion about what we should do with = http://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-00 , that = we presented in Orlando. >=20 > The idea was to avoid microloops occurring in the direct neighbourhood = of a node shutting down or bringing up a link in an IGP topology, by = introducing some > fixed delay in the update of the FIB in the down case, and introducing = a fixed delay in the propagation of the LSP describing the link as up in = the up case. >=20 > The solution is simple, will be released by some in the upcoming = months, and the Orlando audience was seeming to find it interesting to = work on. >=20 > Alia mentioned the interest of comparing this solution with the state = of the art before going further with the doc, so here it comes. >=20 > Generally, compared to other solutions, local-delay does not provide = full coverage, as it only avoids all (but only) microloops occurring = locally to the affected node. However, > in many networks, as shown by Stephane's analysis, it is already = highly beneficial to have loop avoidance there. Considering the = simplicity of the approach, > this looks like a low hanging fruit. >=20 > Alia was considering a comparison with PLSN. (described in = http://tools.ietf.org/html/draft-ietf-rtgwg-microloop-analysis-01, = expired 7 years ago ;) ) >=20 > The differences with the PLSN approach are the following: >=20 > PLSN lets all routers having to converge for some destinations, try to = understand the safety of their new next hops, for each destination. > Based on this assessment, they either >=20 > 1. Transiently use a safe, non post-convergence, set of next hops, to = finally converge to the post-convergence one, or > 2. Transiently use old next-hops, to finally converge to the = post-convergence ones. >=20 > Local delay can be defined as a subset of this approach: > Only the node local to the event applies the procedure. > Step 1 in PLSN is not applied, we only suggest the node to wait for a = fixed time, no transient FIB state. >=20 > I was considering a comparison with oFIB, draft-ietf-rtgwg-ordered-fib = , submitted to IESG as informational. > local-delay can be defined as a subset of this approach: >=20 > While oFIB defines an ordering among all the nodes of the network, = telling which node should wait for which neighbours to be done with = their update, before performing their own, local-delay tells the local = node to wait before fast convergence has happened in the rest of the = network. >=20 > I think that despite the close relationships between these approaches, = local-delay is worth being documented on its own because: >=20 > It's simple, on its way to be supported, and provides loop avoidance = where they happen to be the most annoying. >=20 > Cheers, >=20 > Pierre. >=20 >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg >=20 --Apple-Mail=_0DF5ABBD-E6D3-4E82-BC4E-66933124CD8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 akatlas@gmail.com> = wrote:
Hi Pierre,

Thank you for starting the conversation and a quick intro on = the differences.

When I = look at this draft and PLSN, what I see is that the PLR is = definitionally either a type B router (since
it has an alternate that is safe for forwarding traffic = or for link up it's old primary) and that the PLR is then the
only router to apply the basic procedure.  However, the = PLR may not have an alternate available, unless MRT is used.

As draft-ietf-rtgwg-microloop-analysis-01 says in Sec = 3.3:

" Another distinct situation is when the = router does not support IPFRR  satisfy the safety = condition, and there's no other neighbor that does, i.e. a type-C situation. Unlike other = routers in the network, the = router directly connected to the network does not have the old next-hop = any more, and cannot continue using it. Immediately switching to the new = next-hops, on the other hand, may result in a micro-loop. In this = situation, the router MUST discard traffic forwarded along the affected = route for the duration of DELAY_TYPEC, and then update the routes. = Implementations MAY have a configuration option to allow switching = immediately to the new next-hops for situations where this type of a = micro-loop is not a concern. If implemented, this option MUST be = disabled by default."

Granted, this discarding = becomes the default behavior = for draft-litkowski-rtgwg-uloop-delay-00, but the reasoning and = trade-offs are not discussed.

In the analysis given = in draft-litkowski-rtgwg-uloop-delay-00, the benefit discussed is = only in terms of local
microloops and completely ignores non-local microloops. =  I know that this particular technique is not solving
the remote microloops problem - but those are a real problem = and without even attempting to characterize that,
there's little way of telling whether the local = microloops are 1% of the problem or 99%.

That the technique can apply when = only the PLR does it is not as interesting as having a more general = technique 
that works for traffic from routers that implement it = and does not cause problems.

Obviously, the WG debated this issue quite some time ago and = was willing to go for a simpler partial solution (PLSN)
over OFIB that gave similar coverage to RLFA.

Is your current argument that this = even simpler and more partial a solution might gain some traction? =  Or is it that this
was simpler to implement and provides some = mitigation?

In addition = to lacking any guidance on the scale of the total problem that it = solves, the draft also lacks details to handle
the cases where the network hasn't been stable. =  Granted, the latter is not deeply complex - but the solution isn't = safely
usable without it.

I think that we as a WG need to do = 4 things:
    a) Understand the scope of the total = microloop problem and what fraction of this = that draft-litkowski-rtgwg-uloop-delay-00 actually can solve. =   Does it handle asymmetric link-costs and multi-hop micro-loops? =  Better examples of what types of local microloops are handled and = why other types aren't protected would be useful.  How would an = operator be certain as to what protection would be provided or how to = engineer a network to obtain it?  
    b) Have a draft that fully describes the = problem, the trade-offs, and the solution in detail rather than just a = brief conceptual overview.
    c) = Understand the computation and complexity trade-offs between the = different solutions - given that LFA is already assumed for it to be = useful.
    d) Discuss how partial a solution is = desirable to standardize and the pros/cons of having a worse solution = standardized.   Implementations aren't free - and by standardizing = a more partial solution, this can delay implementations of a better = solution.

I understand the desire to = standardize something and to take something that seems straightforward = and is likely useful to at least one network, but given the WG track = record, at a minimum, I think we must have a more complete draft that = fully documents the solution in detail and compares it = fairly. 

Regards,
Alia


On Mon, May 20, 2013 at 7:57 AM, Pierre Francois = <pierre.francois@imdea.org> wrote:


Dear rtgwg list members,

I would like to know your opinion about what we should do with http://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-d= elay-00 , that we presented in Orlando.

The idea was to avoid microloops occurring in the direct neighbourhood = of a node shutting down or bringing up a link in an IGP topology, by = introducing some
fixed delay in the update of the FIB in the down case, and introducing a = fixed delay in the propagation of the LSP describing the link as up in = the up case.

The solution is simple, will be released by some in the upcoming months, = and the Orlando audience was seeming to find it interesting to work = on.

Alia mentioned the interest of comparing this solution with the state of = the art before going further with the doc, so here it comes.

Generally, compared to other solutions, local-delay does not provide = full coverage, as it only avoids all (but only)  microloops = occurring locally to the affected node. However,
in many networks, as shown by Stephane's analysis, it is already highly = beneficial to have loop avoidance there. Considering the simplicity of = the approach,
this looks like a low hanging fruit.

Alia was considering a comparison  with PLSN. (described in http://tools.ietf.org/html/draft-ietf-rtgwg-microloop-an= alysis-01, expired 7 years ago ;) )

The differences with the PLSN approach are the following:

PLSN lets all routers having to converge for some destinations, try to = understand the safety of their new next hops, for each destination.
Based on this assessment, they either

1. Transiently use a safe, non post-convergence, set of next hops, to = finally converge to the post-convergence one, or
2. Transiently use old next-hops, to finally converge to the = post-convergence ones.

Local delay can be defined as a subset of this approach:
Only the node local to the event applies the procedure.
Step 1 in PLSN is not applied, we only suggest the node to wait for a = fixed time, no transient FIB state.

I was considering a comparison with oFIB, draft-ietf-rtgwg-ordered-fib , = submitted to IESG as informational.
local-delay can be defined as a subset of this approach:

While oFIB defines an ordering among all the nodes of the network, = telling which node should wait for which neighbours to be done with = their update, before performing their own, local-delay tells the local = node to wait before fast convergence has happened in the rest of the = network.

I think that despite the close relationships between these approaches, = local-delay is worth being documented on its own because:

It's simple, on its way to be supported, and provides loop avoidance = where they happen to be the most annoying.

Cheers,

Pierre.


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


= --Apple-Mail=_0DF5ABBD-E6D3-4E82-BC4E-66933124CD8D-- From akatlas@gmail.com Mon May 20 08:37:12 2013 Return-Path: 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 7FD6521F8E3C for ; Mon, 20 May 2013 08:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 87bRiczmU0zt for ; Mon, 20 May 2013 08:37:11 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id DF00B21F881C for ; Mon, 20 May 2013 08:37:10 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id a14so14273215iee.27 for ; Mon, 20 May 2013 08:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ju2/zgwdN7nnCSTP0wU0lecrZfqLQdA1wTceRdqR7mc=; b=hltFcX+u3nL+Vh/P+YOhn7HY6mH4MiGTy5G+vP50SmrXqnGsiw8mILmmCFRvHKx8kN 01GBOegntxMf0vZQuVIomB6MjcZtnnmdpUwNc75XkE60Bm2YIFhQ5USQbwSu261UOCTM vPpJzwYR1B6v7MkhMxYur5Waf0hjmjV8MnQ3vRcQOhDL/xYzdhTL3GQXhX8hjsx6O7Zp +cQ8a5p5oAlMW0W+8Xj8XidSf88bjMpJnLEuBjkNGj8QYYT9OfmiaGZXq2iAJvRjD+4z Pgc3JAd7BqCmTcjm7Lhx9HDlJZt7VgjPDYm/wdSphyTZbWFu4cJwh+gYSVYDQpzxXwYn UVWw== MIME-Version: 1.0 X-Received: by 10.50.176.166 with SMTP id cj6mr5685425igc.56.1369064230257; Mon, 20 May 2013 08:37:10 -0700 (PDT) Received: by 10.64.24.170 with HTTP; Mon, 20 May 2013 08:37:10 -0700 (PDT) In-Reply-To: References: <830E8EED-9BBB-4E58-8C17-BBA721B114D3@imdea.org> Date: Mon, 20 May 2013 11:37:10 -0400 Message-ID: Subject: Re: Progressing with draft-litkowski-rtgwg-uloop-delay-00 ? From: Alia Atlas To: Pierre Francois Content-Type: multipart/alternative; boundary=e89a8f6435a21e8a3a04dd281bb7 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 15:37:12 -0000 --e89a8f6435a21e8a3a04dd281bb7 Content-Type: text/plain; charset=ISO-8859-1 Pierre, The end result should be an updated draft. The list is good for discussing what should go in and why :-) Regards, Alia On Mon, May 20, 2013 at 11:27 AM, Pierre Francois wrote: > > Alia, > > Thanks for your quick feedback. > > Let me check with my co-authors on whether we should change the doc to > answer your comments and come back > for a discussion based on ink-on-paper, or answer on the list. I am afraid > of a never-ending thread for the later :) > > Cheers, > > Pierre. > > On May 20, 2013, at 5:04 PM, Alia Atlas wrote: > > Hi Pierre, > > Thank you for starting the conversation and a quick intro on the > differences. > > When I look at this draft and PLSN, what I see is that the PLR is > definitionally either a type B router (since > it has an alternate that is safe for forwarding traffic or for link up > it's old primary) and that the PLR is then the > only router to apply the basic procedure. However, the PLR may not have > an alternate available, unless MRT is used. > > As draft-ietf-rtgwg-microloop-analysis-01 says in Sec 3.3: > > " Another distinct situation is when the router does not support IPFRR or > could not repair the failure, the new primary next-hops do not satisfy > the safety condition, and there's no other neighbor that does, i.e. a > type-C situation. Unlike other routers in the network, the router > directly connected to the network does not have the old next-hop any more, > and cannot continue using it. Immediately switching to the new next-hops, > on the other hand, may result in a micro-loop. In this situation, the > router MUST discard traffic forwarded along the affected route for the > duration of DELAY_TYPEC, and then update the routes. Implementations MAY > have a configuration option to allow switching immediately to the new > next-hops for situations where this type of a micro-loop is not a concern. > If implemented, this option MUST be disabled by default." > > Granted, this discarding becomes the default behavior > for draft-litkowski-rtgwg-uloop-delay-00, but the reasoning and trade-offs > are not discussed. > > In the analysis given in draft-litkowski-rtgwg-uloop-delay-00, the benefit > discussed is only in terms of local > microloops and completely ignores non-local microloops. I know that this > particular technique is not solving > the remote microloops problem - but those are a real problem and without > even attempting to characterize that, > there's little way of telling whether the local microloops are 1% of the > problem or 99%. > > That the technique can apply when only the PLR does it is not as > interesting as having a more general technique > that works for traffic from routers that implement it and does not cause > problems. > > Obviously, the WG debated this issue quite some time ago and was willing > to go for a simpler partial solution (PLSN) > over OFIB that gave similar coverage to RLFA. > > Is your current argument that this even simpler and more partial a > solution might gain some traction? Or is it that this > was simpler to implement and provides some mitigation? > > In addition to lacking any guidance on the scale of the total problem that > it solves, the draft also lacks details to handle > the cases where the network hasn't been stable. Granted, the latter is > not deeply complex - but the solution isn't safely > usable without it. > > I think that we as a WG need to do 4 things: > a) Understand the scope of the total microloop problem and what > fraction of this that draft-litkowski-rtgwg-uloop-delay-00 actually can > solve. Does it handle asymmetric link-costs and multi-hop micro-loops? > Better examples of what types of local microloops are handled and why > other types aren't protected would be useful. How would an operator be > certain as to what protection would be provided or how to engineer a > network to obtain it? > b) Have a draft that fully describes the problem, the trade-offs, and > the solution in detail rather than just a brief conceptual overview. > c) Understand the computation and complexity trade-offs between the > different solutions - given that LFA is already assumed for it to be useful. > d) Discuss how partial a solution is desirable to standardize and the > pros/cons of having a worse solution standardized. Implementations aren't > free - and by standardizing a more partial solution, this can delay > implementations of a better solution. > > I understand the desire to standardize something and to take something > that seems straightforward and is likely useful to at least one network, > but given the WG track record, at a minimum, I think we must have a more > complete draft that fully documents the solution in detail and compares it > fairly. > > Regards, > Alia > > > On Mon, May 20, 2013 at 7:57 AM, Pierre Francois < > pierre.francois@imdea.org> wrote: > >> >> >> Dear rtgwg list members, >> >> I would like to know your opinion about what we should do with >> http://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-00 , that >> we presented in Orlando. >> >> The idea was to avoid microloops occurring in the direct neighbourhood of >> a node shutting down or bringing up a link in an IGP topology, by >> introducing some >> fixed delay in the update of the FIB in the down case, and introducing a >> fixed delay in the propagation of the LSP describing the link as up in the >> up case. >> >> The solution is simple, will be released by some in the upcoming months, >> and the Orlando audience was seeming to find it interesting to work on. >> >> Alia mentioned the interest of comparing this solution with the state of >> the art before going further with the doc, so here it comes. >> >> Generally, compared to other solutions, local-delay does not provide full >> coverage, as it only avoids all (but only) microloops occurring locally to >> the affected node. However, >> in many networks, as shown by Stephane's analysis, it is already highly >> beneficial to have loop avoidance there. Considering the simplicity of the >> approach, >> this looks like a low hanging fruit. >> >> Alia was considering a comparison with PLSN. (described in >> http://tools.ietf.org/html/draft-ietf-rtgwg-microloop-analysis-01, >> expired 7 years ago ;) ) >> >> The differences with the PLSN approach are the following: >> >> PLSN lets all routers having to converge for some destinations, try to >> understand the safety of their new next hops, for each destination. >> Based on this assessment, they either >> >> 1. Transiently use a safe, non post-convergence, set of next hops, to >> finally converge to the post-convergence one, or >> 2. Transiently use old next-hops, to finally converge to the >> post-convergence ones. >> >> Local delay can be defined as a subset of this approach: >> Only the node local to the event applies the procedure. >> Step 1 in PLSN is not applied, we only suggest the node to wait for a >> fixed time, no transient FIB state. >> >> I was considering a comparison with oFIB, draft-ietf-rtgwg-ordered-fib , >> submitted to IESG as informational. >> local-delay can be defined as a subset of this approach: >> >> While oFIB defines an ordering among all the nodes of the network, >> telling which node should wait for which neighbours to be done with their >> update, before performing their own, local-delay tells the local node to >> wait before fast convergence has happened in the rest of the network. >> >> I think that despite the close relationships between these approaches, >> local-delay is worth being documented on its own because: >> >> It's simple, on its way to be supported, and provides loop avoidance >> where they happen to be the most annoying. >> >> Cheers, >> >> Pierre. >> >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> > > > --e89a8f6435a21e8a3a04dd281bb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Pierre,

The end result should be = an updated draft. =A0The list is good for discussing what should go in and = why :-)

Regards,
Alia= =A0


On Mon,= May 20, 2013 at 11:27 AM, Pierre Francois <pierre.francois@imdea.= org> wrote:
Alia,=A0

Thanks for your quick feedbac= k.=A0

Let me check with my co-authors on whether we should ch= ange the doc to answer your comments and come back=A0
for a discu= ssion based on ink-on-paper, or answer on the list. I am afraid of a never-= ending thread for the later :)

Cheers,

Pierre.

On May 20, 2013, at 5:04 PM, Alia Atlas <akatlas@gmail.com&g= t; wrote:

Hi Pierre,

Thank you for starting the conversation and a quick intro on the dif= ferences.

When I look at this draft and PLSN, what= I see is that the PLR is definitionally either a type B router (since
it has an alternate that is safe for forwarding traffic or for link up= it's old primary) and that the PLR is then the
only router t= o apply the basic procedure. =A0However, the PLR may not have an alternate = available, unless MRT is used.

As=A0draft-ietf-rtgwg-microloop-analysis-01 says in Sec= 3.3:

" Anoth= er distinct situation is when the router does not support IPFRR=A0or could not repair the failure, the new primar= y next-hops do not=A0satisfy the safet= y condition, and there's no other neighbor that=A0does, i.e. a type-C situation. Unlike other routers in the = network,=A0the router directly connect= ed to the network does not have the old next-hop any more, and cannot conti= nue using it. Immediately switching to the new next-hops, on the other hand= , may result in a micro-loop. In this situation, the router MUST discard tr= affic forwarded along the affected route for the duration of DELAY_TYPEC, a= nd then update the routes. Implementations MAY have a configuration option = to allow switching immediately to the new next-hops for situations where th= is type of a micro-loop is not a concern. If implemented, this option MUST = be disabled by default."

Granted, this discarding becomes the default behavior f= or=A0draft-litkowski-rtgwg-uloop-delay-00, but the reasoning and trade-offs= are not discussed.

In the analysis given in=A0dra= ft-litkowski-rtgwg-uloop-delay-00, the benefit discussed is only in terms o= f local
microloops and completely ignores non-local microloops. =A0I know that= this particular technique is not solving
the remote microloops p= roblem - but those are a real problem and without even attempting to charac= terize that,
there's little way of telling whether the local microloops are 1% = of the problem or 99%.

That the technique can appl= y when only the PLR does it is not as interesting as having a more general = technique=A0
that works for traffic from routers that implement it and does not cau= se problems.

Obviously, the WG debated this issue = quite some time ago and was willing to go for a simpler partial solution (P= LSN)
over OFIB that gave similar coverage to RLFA.

Is your current argument that this even simpler and more partial a solutio= n might gain some traction? =A0Or is it that this
was simpler to implement and provides some mitigation?

<= /div>
In addition to lacking any guidance on the scale of the total pro= blem that it solves, the draft also lacks details to handle
the cases where the network hasn't been stable. =A0Granted, the la= tter is not deeply complex - but the solution isn't safely
us= able without it.

I think that we as a WG nee= d to do 4 things:
=A0 =A0 a) Understand the scope of the total microloop problem and wha= t fraction of this that=A0draft-litkowski-rtgwg-uloop-delay-00 actually can= solve. =A0 Does it handle asymmetric link-costs and multi-hop micro-loops?= =A0Better examples of what types of local microloops are handled and why o= ther types aren't protected would be useful. =A0How would an operator b= e certain as to what protection would be provided or how to engineer a netw= ork to obtain it? =A0
=A0 =A0 b) Have a draft that fully describes the problem, the trade-of= fs, and the solution in detail rather than just a brief conceptual overview= .
=A0 =A0 c) Understand the computation and complexity trade-offs= between the different solutions - given that LFA is already assumed for it= to be useful.
=A0 =A0 d) Discuss how partial a solution is desirable to standardize = and the pros/cons of having a worse solution standardized. =A0 Implementati= ons aren't free - and by standardizing a more partial solution, this ca= n delay implementations of a better solution.

I understand the desire to standardize something and to= take something that seems straightforward and is likely useful to at least= one network, but given the WG track record, at a minimum, I think we must = have a more complete draft that fully documents the solution in detail and = compares it fairly.=A0

Regards,
Alia


On Mon, May 20, 2013 at 7:57 AM, = Pierre Francois <pierre.francois@imdea.org> wrote:


Dear rtgwg list members,

I would like to know your opinion about what we should do with http://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-00 = , that we presented in Orlando.

The idea was to avoid microloops occurring in the direct neighbourhood of a= node shutting down or bringing up a link in an IGP topology, by introducin= g some
fixed delay in the update of the FIB in the down case, and introducing a fi= xed delay in the propagation of the LSP describing the link as up in the up= case.

The solution is simple, will be released by some in the upcoming months, an= d the Orlando audience was seeming to find it interesting to work on.

Alia mentioned the interest of comparing this solution with the state of th= e art before going further with the doc, so here it comes.

Generally, compared to other solutions, local-delay does not provide full c= overage, as it only avoids all (but only) =A0microloops occurring locally t= o the affected node. However,
in many networks, as shown by Stephane's analysis, it is already highly= beneficial to have loop avoidance there. Considering the simplicity of the= approach,
this looks like a low hanging fruit.

Alia was considering a comparison =A0with PLSN. (described in http://tools.ietf.org/html/draft-ietf-rtgwg-microloop-analysis-01, expired 7 years ago ;) )

The differences with the PLSN approach are the following:

PLSN lets all routers having to converge for some destinations, try to unde= rstand the safety of their new next hops, for each destination.
Based on this assessment, they either

1. Transiently use a safe, non post-convergence, set of next hops, to final= ly converge to the post-convergence one, or
2. Transiently use old next-hops, to finally converge to the post-convergen= ce ones.

Local delay can be defined as a subset of this approach:
Only the node local to the event applies the procedure.
Step 1 in PLSN is not applied, we only suggest the node to wait for a fixed= time, no transient FIB state.

I was considering a comparison with oFIB, draft-ietf-rtgwg-ordered-fib , su= bmitted to IESG as informational.
local-delay can be defined as a subset of this approach:

While oFIB defines an ordering among all the nodes of the network, telling = which node should wait for which neighbours to be done with their update, b= efore performing their own, local-delay tells the local node to wait before= fast convergence has happened in the rest of the network.

I think that despite the close relationships between these approaches, loca= l-delay is worth being documented on its own because:

It's simple, on its way to be supported, and provides loop avoidance wh= ere they happen to be the most annoying.

Cheers,

Pierre.


_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg



--e89a8f6435a21e8a3a04dd281bb7-- From internet-drafts@ietf.org Thu May 23 14:36:52 2013 Return-Path: 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 8AFF621F96C1; Thu, 23 May 2013 14:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Zsk6OzkdYus4; Thu, 23 May 2013 14:36:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A904C21F9774; Thu, 23 May 2013 13:51:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523205113.6051.94668.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 13:51:13 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:36:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Remote LFA FRR Author(s) : Stewart Bryant Clarence Filsfils Stefano Previdi Mike Shand Ning So Filename : draft-ietf-rtgwg-remote-lfa-02.txt Pages : 15 Date : 2013-05-23 Abstract: This draft describes an extension to the basic IP fast re-route mechanism described in RFC5286 that provides additional backup connectivity for link failures when none can be provided by the basic mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-remote-lfa-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri May 24 06:52:53 2013 Return-Path: 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 DC4E521F9285; Fri, 24 May 2013 06:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 dA7ys9VF3TFL; Fri, 24 May 2013 06:52:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B60C21F918C; Fri, 24 May 2013 06:52:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-ipfrr-notvia-addresses-11.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130524135237.1424.92264.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2013 06:52:37 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 13:52:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : A Framework for IP and MPLS Fast Reroute Using Not-via A= ddresses Author(s) : Stewart Bryant Stefano Previdi Mike Shand Filename : draft-ietf-rtgwg-ipfrr-notvia-addresses-11.txt Pages : 32 Date : 2013-05-24 Abstract: This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics. The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ipfrr-notvia-addresses There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-notvia-addresses-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-ipfrr-notvia-addresses-= 11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri May 24 09:09:12 2013 Return-Path: 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 56F7E21F9601; Fri, 24 May 2013 09:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 F4PJhcpDVuJ7; Fri, 24 May 2013 09:09:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFDA21F96E9; Fri, 24 May 2013 09:09:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-ordered-fib-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130524160900.17710.38962.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2013 09:09:00 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 16:09:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Framework for Loop-free convergence using oFIB Author(s) : Mike Shand Stewart Bryant Stefano Previdi Clarence Filsfils Pierre Francois Olivier Bonaventure Filename : draft-ietf-rtgwg-ordered-fib-10.txt Pages : 26 Date : 2013-05-24 Abstract: This document describes an illustrative framework of a mechanism for use in conjunction with link state routing protocols which prevents the transient loops which would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers. This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast re-route mechanism which converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described. The technology described in this document has been subject to extensive simulation using real network topologies and costs, and pathological convergence behaviour. However the mechanism described in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-ordered-fib-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri May 24 10:26:57 2013 Return-Path: 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 2620A21F966F; Fri, 24 May 2013 10:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 4wCCxB08yRrS; Fri, 24 May 2013 10:26:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D46021F8EAF; Fri, 24 May 2013 10:26:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-ordered-fib-11.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130524172641.772.5505.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2013 10:26:41 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 17:26:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Framework for Loop-free convergence using oFIB Author(s) : Mike Shand Stewart Bryant Stefano Previdi Clarence Filsfils Pierre Francois Olivier Bonaventure Filename : draft-ietf-rtgwg-ordered-fib-11.txt Pages : 26 Date : 2013-05-24 Abstract: This document describes an illustrative framework of a mechanism for use in conjunction with link state routing protocols which prevents the transient loops which would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers. This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast re-route mechanism which converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described. The technology described in this document has been subject to extensive simulation using real network topologies and costs, and pathological convergence behaviour. However the mechanism described in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-ordered-fib-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri May 24 10:35:50 2013 Return-Path: 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 1E22721F968D; Fri, 24 May 2013 10:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Fgw1X5EZBVF1; Fri, 24 May 2013 10:35:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6829D21F9644; Fri, 24 May 2013 10:35:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-ordered-fib-12.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130524173549.4685.50147.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2013 10:35:49 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 17:35:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Framework for Loop-free convergence using oFIB Author(s) : Mike Shand Stewart Bryant Stefano Previdi Clarence Filsfils Pierre Francois Olivier Bonaventure Filename : draft-ietf-rtgwg-ordered-fib-12.txt Pages : 27 Date : 2013-05-24 Abstract: This document describes an illustrative framework of a mechanism for use in conjunction with link state routing protocols which prevents the transient loops which would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers. This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast re-route mechanism which converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described. The technology described in this document has been subject to extensive simulation using real network topologies and costs, and pathological convergence behaviour. However the mechanism described in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-ordered-fib-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf-ipr@ietf.org Thu May 30 09:10:42 2013 Return-Path: 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 DD25721F9729; Thu, 30 May 2013 09:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 l4wH6mXti1o3; Thu, 30 May 2013 09:10:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7861E21F96A9; Thu, 30 May 2013 09:10:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: stbryant@cisco.com, cfilsfil@cisco.com, imc.shand@gmail.com, ning.so@tatacommunications.com, sprevidi@cisco.com Subject: IPR Disclosure: Verizon Patent and Licensing Inc.'s Statement about IPR related to draft-ietf-rtgwg-remote-lfa-01 X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130530161042.15973.60603.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2013 09:10:42 -0700 Cc: adrian@olddog.co.uk, stbryant@cisco.com, ipr-announce@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:10:43 -0000 Dear Stewart Bryant, Clarence Filsfils, Mike Shand, So Ning, Stefano Previd= i: An IPR disclosure that pertains to your Internet-Draft entitled "Remote LFA FRR" (draft-ietf-rtgwg-remote-lfa) was submitted to the IETF Secretariat on 2013-05-08 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/2071/). The title of the IPR disclosure is "Verizon Patent and Licensing Inc.'s Statement about IPR rela= ted to draft-ietf-rtgwg-remote-lfa-01.""); The IETF Secretariat From akatlas@gmail.com Fri May 31 08:04:59 2013 Return-Path: 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 48A9921F9732 for ; Fri, 31 May 2013 08:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001, NO_RELAYS=-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 IJlK-+Duje-N for ; Fri, 31 May 2013 08:04:58 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id D6A9721F9611 for ; Fri, 31 May 2013 08:04:58 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id u16so1625458iet.8 for ; Fri, 31 May 2013 08:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CX3nCRWDSZv0SdY77gODuiGyoXWuA8rl87Kngv0/q4Q=; b=xLI1oDXRsXRKFixOFF6yR4aQRpMNnB1Nc/CFaWmbc2rQpga02XBgSQdP2PrQJKe8M4 gleNxzqLLSyXJdbj+HnRZNOtRwlgngdFxF+hCVV2ob+A7XAASwackWg8V3Diw8OeW5Pq qYZ49rLSzHjcZpYqze/Uf//AjdWBpS/3YebLHdWChzJoMgTQ84EjYVtDTZefS4hqboIg G8ycxnZQtZLtp5cEKrIKdU6AxLPvmrNPnn4DFYuUpzu/EKCA2+CWXd63SCQD37aGn9cJ YvJNK4U02hK0Yy6bYRxUVZPk/OjRwPRJIZeikBdspR4aiUwATlTmO572myMZGY+a5H7b vmww== MIME-Version: 1.0 X-Received: by 10.50.85.6 with SMTP id d6mr1886467igz.4.1370012698484; Fri, 31 May 2013 08:04:58 -0700 (PDT) Received: by 10.64.46.4 with HTTP; Fri, 31 May 2013 08:04:58 -0700 (PDT) Date: Fri, 31 May 2013 11:04:58 -0400 Message-ID: Subject: meeting time requests From: Alia Atlas To: "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=089e013cbf703b2a8904de04f035 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 15:04:59 -0000 --089e013cbf703b2a8904de04f035 Content-Type: text/plain; charset=ISO-8859-1 Alvaro has put in for a 1.5 hour slot for the Berlin meeting. Please let us know ASAP if you are would like significant time. The cut-off for session requests is Monday so if we need more time, we'll want to know very soon. Alia --089e013cbf703b2a8904de04f035 Content-Type: text/html; charset=ISO-8859-1
Alvaro has put in for a 1.5 hour slot for the Berlin meeting.
Please let us know ASAP if you are would like significant time.
The cut-off for session requests is Monday so if we need more time, we'll
want to know very soon.

Alia
--089e013cbf703b2a8904de04f035--