From stbryant@cisco.com Wed Jan 4 03:32:15 2012 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 2A8B321F8518 for ; Wed, 4 Jan 2012 03:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.673 X-Spam-Level: X-Spam-Status: No, score=-110.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 e+3LLxNSqhSO for ; Wed, 4 Jan 2012 03:32:14 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 59B3821F8505 for ; Wed, 4 Jan 2012 03:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2833; q=dns/txt; s=iport; t=1325676734; x=1326886334; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=CQv9V8+vM2h854SbiDmzKX/h3iqzOA1N4B9CHkYWZvw=; b=HbZK5oX0j1U0ke8KYG/AY94C9uC0el40w23fhaQ2MfjvPDqFF/Y3IDkj Bjf3PDQv055wi1y86V6+AcN1ZYuQ8WLXq7s0n4mCqsNh9HGt73CEAUkT4 hhOWSjicoC6ERhodvDwSKs4ixsTDHRI7k7yYLA7hV5fY1h6Xd7zPOyCtZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAFY4BE+Q/khL/2dsb2JhbABDggWqYoEFgXIBAQEEEgECASIzDQ0EHAMBAgEJFg8JAwIBAgE0BwIIBg0GAgEBHp8eAYMuDwGaZowPBJUEkjQ X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; d="scan'208";a="62718379" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 04 Jan 2012 11:32:13 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q04BWDnl015545 for ; Wed, 4 Jan 2012 11:32:13 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q04BWCRc023720; Wed, 4 Jan 2012 11:32:12 GMT Message-ID: <4F0438BC.8010801@cisco.com> Date: Wed, 04 Jan 2012 11:32:12 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "rtgwg@ietf.org" Subject: Fwd: Re: Review of draft-ietf-rtgwg-lfa-applicability-04 References: <4F043397.2090706@cisco.com> In-Reply-To: <4F043397.2090706@cisco.com> X-Forwarded-Message-Id: <4F043397.2090706@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 11:32:15 -0000 FYI -------- Original Message -------- Subject: Re: Review of draft-ietf-rtgwg-lfa-applicability-04 Date: Wed, 04 Jan 2012 11:10:15 +0000 From: Stewart Bryant Reply-To: stbryant@cisco.com To: Shawn Emery , draft-ietf-rtgwg-lfa-applicability.all@tools.ietf.org, rtgwg-chairs@tools.ietf.org, rtgwg-chairs@tools.ietf.org CC: iesg@ietf.org, secdir@ietf.org On 04/01/2012 08:41, Shawn Emery wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This informational draft describes optimizations for Loop-Free > Alternates (LFA) > in Service Provider (SP) networks. > > The security considerations section does exist and states that there is > no new security considerations, which I believe to be the case. > > General comments: > > Not being a routing expert this was slow to read (e.g. not knowing > some of the > unexpanded abbreviations and terminology). As a result, the editorial > comments are just > from the Abstract and Introduction sections. > > Editorial comments: > > s/applicability of LoopFree Alternates/applicability of LoopFree > Alternates (LFA)/ > s/Service Provider networks/Service Provider (SP) networks/ > I haven't looked the common abbreviations list, but should ISIS, et. > al. be expanded? > > Shawn. > -- > > Shawn Thank you for your review, and for picking up an inconsistency that we had all missed. "ISIS" is well known, but technically it should be IS-IS. There is some security text that is in previous work on this subject that it is useful to reference that I have added in via an editor's note. For everyone's benefit I append the editors notes for the document. Though out the document please: s/ISIS/IS-IS/ s/LoopFree/loop-free/ Then s/Service Provider networks/Service Provider (SP) networks/ In section 1 Old In this document, we analyze the applicability of LoopFree Alternates in both core and access parts of Service Provider networks. New In this document, we analyze the applicability of Loop-Free Alternates (LFA) [RFC5714][RFC5286] in both core and access parts of Service Provider (SP) networks. End ===== In References add normative ref to RFC 5286 ===== In Section 8 Old This document does not introduce any new security considerations. New The security considerations applicable to LFAs are described in RFC5286. This document does not introduce any new security considerations. End ===== - Stewart From wwwrun@ietfa.amsl.com Tue Jan 10 09:30:24 2012 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id D6AAE21F8631; Tue, 10 Jan 2012 09:30:24 -0800 (PST) From: IESG Secretary To: IETF Announcement list Subject: WG Action: RECHARTER: Routing Area Working Group (rtgwg) Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120110173024.D6AAE21F8631@ietfa.amsl.com> Date: Tue, 10 Jan 2012 09:30:24 -0800 (PST) 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: Tue, 10 Jan 2012 17:30:25 -0000 The Routing Area Working Group (rtgwg) in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Routing Area Working Group (rtgwg) ------------------------------------- Current Status: Active Working Group Last Updated: 2011-12-22 IETF Area: Routing Area Chairs: Alia Atlas Alvaro Retana Routing Area Directors: Stewart Bryant Adrian Farrel Responsible Area Director: Stewart Bryant Mailing List: rtgwg@ietf.org To Subscribe: rtgwg-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtgwg/ Description of the Working Group: The Routing area receives occasional proposals for the development and publication of RFCs dealing with routing topics, but for which the required work does not yet rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and it is either not ready for a BOF or a single BOF would not provide the time to ensure a mature proposal. The RTGWG will serve as the forum for developing these types of proposals. The RTGWG also focuses on enhancements to hop-by-hop distributed routing (e.g. multicast, LDP-MPLS, unicast routing) related to fast-reroute and loop-free convergence. A specific goal of fast-reroute mechanisms is to provide up to complete coverage when the potential failure would not partition the network. All work in this area should be specifically evaluated by the WG in terms of practicality and applicability to deployed networks. The RTGWG mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion. The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose. Goals and Milestones: Mar 2012 Submit IP Fast Re-Route Using Not-via Addresses to IESG for publication as Informational Nov 2012 Submit Composite-Link Requirements to IESG for publication as Informational Nov 2012 Submit Ordered FIB architecture to IESG for publication as Informational Nov 2012 Submit initial Internet Draft on Multicast IP Fast Reroute Architecture Nov 2012 Submit Composite-Link Framework to IESG for publication as Informational Apr 2013 Submit specification on Advanced IP Fast Reroute mechanism to IESG for publication as Proposed Standard From alvaro.retana@hp.com Tue Jan 10 11:34:47 2012 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 AE58621F84B8 for ; Tue, 10 Jan 2012 11:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 yfv4+GcyXWFz for ; Tue, 10 Jan 2012 11:34:46 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by ietfa.amsl.com (Postfix) with ESMTP id B9D7221F8499 for ; Tue, 10 Jan 2012 11:34:46 -0800 (PST) Received: from G9W0369G.americas.hpqcorp.net (g9w0369g.houston.hp.com [16.216.193.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 308443814A; Tue, 10 Jan 2012 19:34:46 +0000 (UTC) Received: from G1W1331.americas.hpqcorp.net (16.236.60.36) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 10 Jan 2012 19:33:34 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G1W1331.americas.hpqcorp.net ([16.236.60.36]) with mapi; Tue, 10 Jan 2012 19:33:34 +0000 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Date: Tue, 10 Jan 2012 19:33:24 +0000 Subject: RE: Adoption of the MRT Architecture Draft as WG Document Thread-Topic: Adoption of the MRT Architecture Draft as WG Document Thread-Index: Acyt5kOsRZxYt/msRm2zvww9/zcpsgh555bA Message-ID: <24646CE17826CF4A8DF71F9856C7E6565959E269D5@GVW1338EXA.americas.hpqcorp.net> References: <24646CE17826CF4A8DF71F9856C7E65659572B63D8@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E65659572B63D8@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_24646CE17826CF4A8DF71F9856C7E6565959E269D5GVW1338EXAame_" MIME-Version: 1.0 Cc: "draft-atlas-rtgwg-mrt-frr-architecture@tools.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: Tue, 10 Jan 2012 19:34:47 -0000 --_000_24646CE17826CF4A8DF71F9856C7E6565959E269D5GVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! Sorry for the delay in closing on this item. This call for adoption closed= a few weeks ago. Considering the support at the meeting in Taipei and the votes on the maili= ng list, we are adopting the MRT Architecture draft as a WG item. Authors: Please go ahead and post the draft-rtgwg- document. As the text below says, the multicast-related sections should be moved into= a separate document (individual submission) which we will consider separat= ely. Thanks! Alvaro. From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of R= etana, Alvaro Sent: Monday, November 28, 2011 10:56 AM To: rtgwg@ietf.org Subject: Adoption of the MRT Architecture Draft as WG Document Hi! As discussed at the meeting in Taipei, this e-mail is a call for adoption o= f the MRT Architecture draft as a WG item. There was strong support in the= room. http://tools.ietf.org/html/draft-atlas-rtgwg-mrt-frr-architecture As was also suggested at the meeting, the multicast-related sections (4.3 a= nd 4.4) will be moved into a separate document (to be discussed separately)= . It was also brought up that the draft has an IPR claim attached to it. The= following links are to the IPR claim and to the application itself (provid= ed by the authors): https://datatracker.ietf.org/ipr/1594/ http://www.wipo.int/patentscope/search/en/detail.jsf?docId=3DWO2010055408&r= ecNum=3D1&docAn=3DIB2009007467&queryString=3DFP:%28PCT/IB2009/007467%29&max= Rec=3D1 As a reminder, having an IPR claim does not disqualify a draft from advanci= ng in the IETF, being adopted by a working group or from eventually becomin= g a standard. It just represents one more item to be considered by the wor= king group. http://www.ietf.org/ipr/policy.html Please post your opinions and votes about adoption to the list. We will ke= ep this discussion open until Dec/12, 2011. Thanks! Alvaro. --_000_24646CE17826CF4A8DF71F9856C7E6565959E269D5GVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

Sorry for the delay in closing on this item.  This = call for adoption closed a few weeks ago. 

 

<= p class=3DMsoNormal>Considering the support a= t the meeting in Taipei and the votes on the mailing list, we are adopting = the MRT Architecture draft as a WG item.

 

Authors: Please go ahead and pos= t the draft-rtgwg- document.

 

= As the text below says, the multicast-related= sections should be moved into a separate document (individual submission) = which we will consider separately.

 

Thanks!

 

Alvaro.

 

From: rtgwg-bounces@ietf.org [= mailto:rtgwg-bounces@ietf.org] On Behalf Of Retana, Alvaro
Sen= t: Monday, November 28, 2011 10:56 AM
To: rtgwg@ietf.org
<= b>Subject: Adoption of the MRT Architecture Draft as WG Document

 

Hi!

 

=

As discussed at the meeting in Taipei, this e-mail is = a call for adoption of the MRT Architecture draft as a WG item.  There= was strong support in the room.

&n= bsp;

http://tools.ietf.org/html/draft-atla= s-rtgwg-mrt-frr-architecture

&n= bsp;

As was also suggested at the meeting, th= e multicast-related sections (4.3 and 4.4) will be moved into a separate do= cument (to be discussed separately).

 

 

It was also brought up that the draft has an IPR claim attached to it= .  The following links are to the IPR claim and to the application its= elf (provided by the authors):

&nbs= p;

https://datatracker.ietf.org/ipr/1594/

http://www.wipo.int/patentscope/search/en/detail.jsf?docId=3DWO20100= 55408&recNum=3D1&docAn=3DIB2009007467&queryString=3DFP:%28PCT/I= B2009/007467%29&maxRec=3D1

&n= bsp;

As a reminder, having an IPR= claim does not disqualify a draft from advancing in the IETF, being adopte= d by a working group or from eventually becoming a standard.  It just = represents one more item to be considered by the working group.   = ; http://www.ietf.org/= ipr/policy.html

 

 

Please post= your opinions and votes about adoption to the list.  We will keep thi= s discussion open until Dec/12, 2011.

 

Thanks!

 

Alvaro.

= --_000_24646CE17826CF4A8DF71F9856C7E6565959E269D5GVW1338EXAame_-- From alvaro.retana@hp.com Tue Jan 10 11:52:13 2012 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 6851C21F86AD for ; Tue, 10 Jan 2012 11:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 kGpEKz5XNXet for ; Tue, 10 Jan 2012 11:52:10 -0800 (PST) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2C84521F86DC for ; Tue, 10 Jan 2012 11:52:09 -0800 (PST) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id 8324EC368; Tue, 10 Jan 2012 19:52:08 +0000 (UTC) Received: from G1W0397.americas.hpqcorp.net (16.236.31.21) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 10 Jan 2012 19:49:37 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G1W0397.americas.hpqcorp.net ([16.236.31.21]) with mapi; Tue, 10 Jan 2012 19:49:36 +0000 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Date: Tue, 10 Jan 2012 19:49:28 +0000 Subject: WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses Thread-Topic: WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses Thread-Index: AczP0PbOKJrmPJkgRQOoV2xhWFeolg== Message-ID: <24646CE17826CF4A8DF71F9856C7E6565959E269F7@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_24646CE17826CF4A8DF71F9856C7E6565959E269F7GVW1338EXAame_" MIME-Version: 1.0 Cc: "draft-ietf-rtgwg-ipfrr-notvia-addresses@tools.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: Tue, 10 Jan 2012 19:52:13 -0000 --_000_24646CE17826CF4A8DF71F9856C7E6565959E269F7GVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Happy New Year! This message is to start a Working Group Last Call for 'IP Fast Reroute Usi= ng Not-via Addresses' (http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-no= tvia-addresses-08). This last call will end on January 26, 2012. The intent is to publish this document as an Informational RFC. Please send any comments to the WG list. Thanks! Alvaro. --_000_24646CE17826CF4A8DF71F9856C7E6565959E269F7GVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Happy New Year!<= o:p>

This message is to start a Working Group Last= Call for ‘IP Fast Reroute Using Not-via Addresses’ (htt= p://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-notvia-addresses-08).

This last call will end on January 26, = 2012.

The intent is to publish this d= ocument as an Informational RFC.

Plea= se send any comments to the WG list.

Thanks!

Alvaro.

= --_000_24646CE17826CF4A8DF71F9856C7E6565959E269F7GVW1338EXAame_-- From internet-drafts@ietf.org Wed Jan 11 02:45:07 2012 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 BF3A821F85F2; Wed, 11 Jan 2012 02:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, 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 4CTzQAIJfMYh; Wed, 11 Jan 2012 02:45:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B2E21F852C; Wed, 11 Jan 2012 02:45:07 -0800 (PST) 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-applicability-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120111104507.31588.73307.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 02:45:07 -0800 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: Wed, 11 Jan 2012 10:45:07 -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 Gr= oup of the IETF. Title : LFA applicability in SP networks Author(s) : Clarence Filsfils Pierre Francois Filename : draft-ietf-rtgwg-lfa-applicability-05.txt Pages : 34 Date : 2012-01-11 In this document, we analyze the applicability of -Loop-Free Alternates in both core and access parts of Service Provider networks. We provide design guides to favor their applicability where relevant, typically in the access part of the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-lfa-applicability-05.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtgwg-lfa-applicability-05.txt From ulrich@herberg.name Mon Jan 16 13:49:22 2012 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 BF2F221F86A4 for ; Mon, 16 Jan 2012 13:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 HzrPPuOgnpWR for ; Mon, 16 Jan 2012 13:49:22 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0736021F8686 for ; Mon, 16 Jan 2012 13:49:18 -0800 (PST) Received: by werp11 with SMTP id p11so34495wer.31 for ; Mon, 16 Jan 2012 13:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=J7o741RPEGRJF4iyfYnkf7UiMak0tz9YUynlvxu0cqc=; b=Oxhkgpvt1SAwMboyCmBlZ1n/esOLJ9SEKkczy2BKiqi+PYwEzLr/XCW+K/egVrDJvL VXsvrlK8ZrRBSQUzGFaonjZKW7abqjEJFNMgdb5sgPCiQIBqk3I9MCqsqPF6olKyg3Hl 4UKcR1rJDn4Ap5hCc6s4KIR4Dm70jrNe9Pk6M= MIME-Version: 1.0 Received: by 10.216.133.82 with SMTP id p60mr4555760wei.59.1326750558130; Mon, 16 Jan 2012 13:49:18 -0800 (PST) Received: by 10.216.54.146 with HTTP; Mon, 16 Jan 2012 13:49:18 -0800 (PST) Date: Mon, 16 Jan 2012 13:49:18 -0800 Message-ID: Subject: DFF From: Ulrich Herberg To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 16 Jan 2012 21:49:22 -0000 Hi, In December, I have sent a link to a draft which may be of interest for the RtgWG. There was not much discussion (maybe because of the upcoming Christmas holidays), so I was asked by the chairs to resend the link and ask for review. Below you find a summary of the contents. I would also like to request a slot at the upcoming Paris IETF to present the draft. Our draft describes a data forwarding mechanism, currently specified for 6lowpan (but it would be doable to add the same mechanism for IPv6 as well). The idea is that a node first tries to forward a data packet along the route proposed by the routing protocol. However, if the topology has changed or a link has become unstable, instead of dropping the packet, the node tries to find alternate paths towards the destination by applying a "depth-first search" in the network, possibly updating the route cost in the routing protocol. This allows for increasing the delivery ratio until the route has been corrected by the routing protocol. The advantage is that one requires fewer updates of the control plane, which may have negative effects on an already unstable topology (e.g. by flooding RREQ or LSAs). We have done a number of simulations and also real tests with several hundred nodes at Fujitsu which showed a significant performance improvement. If you are interested in reading the draft, I would appreciate any kind of feedback. I-D http://tools.ietf.org/html/draft-cardenas-dff We have code both for the real testbed and for the simulator. Moreover, I am currently developing open source code. Some results in a paper (http://www.flacp.fujitsulabs.com/~uherberg/DFF.pdf= ) Comparison of Data Forwarding Mechanisms for AMI Networks. Sandra C=E9spedes, Alvaro A. C=E1rdenas, Tadashige Iwao. 2012 IEEE Innovative Smart Grid Technologies Conference (ISGT). January 17-19, 2012. Best regards Ulrich From stephane.litkowski@orange.com Tue Jan 17 08:35:48 2012 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 EAFF421F86C4 for ; Tue, 17 Jan 2012 08:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP3c3kKJoWX7 for ; Tue, 17 Jan 2012 08:35:48 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D4E0121F8687 for ; Tue, 17 Jan 2012 08:35:47 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id EB8802647B8 for ; Tue, 17 Jan 2012 17:35:46 +0100 (CET) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C554D27C057 for ; Tue, 17 Jan 2012 17:35:46 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jan 2012 17:35:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCD536.1020149B" Subject: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link Date: Tue, 17 Jan 2012 17:35:45 +0100 Message-ID: <2800_1326818146_4F15A362_2800_19426_1_4FC3556A36EE3646A09DAA60429F5335079D19F5@PUEXCBL0.nanterre.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link Thread-Index: AczVNg/ebQ3Ak710TZGZ7UWNJ5bueQ== From: To: X-OriginalArrivalTime: 17 Jan 2012 16:35:47.0683 (UTC) FILETIME=[10FC6B30:01CCD536] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.17.153017 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, 17 Jan 2012 16:35:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCD536.1020149B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I made some simulation based on real topologies on LFA and remote LFA. I saw some issues related to topologies and I wanted to have some feedback on it. =20 We focus on P-P link failures. In some ring topologies between Ps (which doesn't work very well with LFA), alternate Ps are not eligible for LFAs (for some destinations) but some PEs are eligible providing link protection for the P-P link failure. =20 We tried to apply remote LFA algorithm for non LFA eligible destinations, and sometimes we have the same thing : PEs are used as best rLFA because there is no eligible P. =20 PE are sometimes meshed with low BW link (compared to core links). So if P core link fails, traffic will be switched on PE link (during protection time) and so will potentially (high probability) make the link congestionned. =20 >From P point of view : traffic is protected, even if some traffic is dropped due to congestion(CoS should prioritize traffic), it's better than dropping all. =20 >From PE point of view : some destinations of the PE where maybe not using the P-P link that fails. But due to congestion of the link, they become impacted. So impact for the PE is maybe greater than not having LFA on the core (we are talking about few seconds of impact -> time for the P to converge). =20 Note : it's not a one to one mapping of traffic between the P-P link that fails and the P-PE link used as LFA. It will depend on how many destinations are using this PE as LFA (and quantity of traffic per destination). But we could clearly expect congestion as PE links are sized only for their usage. =20 Do you think this is a real concern ? If yes, is there already a proposal/solution to deal this issue ? - like using TE informations (ISIS subTLV) to take account BW, and so basically not protecting a link by a lower BW link - preventing some links to be used as LFA =20 =20 Thanks for your feedback =20 --- Stephane =20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if th= is message was modified, changed or falsified. Thank you. ------_=_NextPart_001_01CCD536.1020149B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
I made so= me=20 simulation based on real topologies on LFA and remote LFA.
I saw=20 some issues related to topologies and I wanted to have some feedback o= n=20 it.
 
We focus = on P-P link=20 failures.
In some r= ing=20 topologies between Ps (which doesn't work very well with LFA), = =20 alternate Ps are not eligible for LFAs (for some destinations) but som= e PEs=20 are eligible providing link protection for the P-P link=20 failure.
 
We tried = to apply=20 remote LFA algorithm for non LFA eligible destinations, and sometimes we ha= ve=20 the same thing  : PEs are used as best rLFA because there is no eligib= le=20 P.
 
PE are so= metimes=20 meshed with low BW link (compared to core links). So if P core link fails,= =20 traffic will be switched on PE link (during protection time) and so wi= ll=20 potentially (high probability) make the link congestionned.
 
From P po= int of view=20 : traffic is protected, even if some traffic is dropped due to congestion(C= oS=20 should prioritize traffic), it's better than dropping all.
 
From PE p= oint of=20 view : some destinations of the PE where maybe not using the P-P link that= =20 fails. But due to congestion of the link, they become impacted. So impact f= or=20 the PE is maybe greater than not having LFA on the core (we are talking abo= ut=20 few seconds of impact -> time for the P to converge).
 
Note : it= 's not a=20 one to one mapping of traffic between the P-P link that fails and the P-PE = link=20 used as LFA. It will depend on how many destinations are using this PE as L= FA=20 (and quantity of traffic per destination). But we could clearly expect=20 congestion as PE links are sized only for their usage.
 
Do you th= ink this is=20 a real concern ?
If yes, i= s there=20 already a proposal/solution to deal this issue ?
    -=20 like using TE informations (ISIS subTLV) to take account BW, and so basical= ly=20 not protecting a link by a lower BW link
    -=20 preventing some links to be used as LFA
 
 
Thanks fo= r your=20 feedback
 
---
Stephane
 
__________=
___________________________________________________________________________=
____________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.
------_=_NextPart_001_01CCD536.1020149B-- From asmirnov@cisco.com Tue Jan 17 09:30:55 2012 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 8733E1F0C40 for ; Tue, 17 Jan 2012 09:30:55 -0800 (PST) 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 6iXnFiNrDaA8 for ; Tue, 17 Jan 2012 09:30:54 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9529C1F0C49 for ; Tue, 17 Jan 2012 09:30:54 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0HHUr8X001037; Tue, 17 Jan 2012 18:30:53 +0100 (CET) Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0HHUoLr003969; Tue, 17 Jan 2012 18:30:50 +0100 (CET) Message-ID: <4F15B04A.5020007@cisco.com> Date: Tue, 17 Jan 2012 18:30:50 +0100 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: stephane.litkowski@orange.com Subject: Re: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link References: <2800_1326818146_4F15A362_2800_19426_1_4FC3556A36EE3646A09DAA60429F5335079D19F5@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <2800_1326818146_4F15A362_2800_19426_1_4FC3556A36EE3646A09DAA60429F5335079D19F5@PUEXCBL0.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 17 Jan 2012 17:30:55 -0000 Hi Stephane, if link which you want to exclude is local to the calculating router then implementation is trivial and doesn't need any signaling. If link is not local then this is very similar to more general problem of non-local SRLG. It was discussed but computation is relatively complex and still needs investigation. Anton On 01/17/2012 05:35 PM, stephane.litkowski@orange.com wrote: > Hi all, > I made some simulation based on real topologies on LFA and remote LFA. > I saw some issues related to topologies and I wanted to have some > feedback on it. > We focus on P-P link failures. > In some ring topologies between Ps (which doesn't work very well with > LFA), alternate Ps are not eligible for LFAs (for some destinations) but > some PEs are eligible providing link protection for the P-P link failure. > We tried to apply remote LFA algorithm for non LFA eligible > destinations, and sometimes we have the same thing : PEs are used as > best rLFA because there is no eligible P. > PE are sometimes meshed with low BW link (compared to core links). So if > P core link fails, traffic will be switched on PE link (during > protection time) and so will potentially (high probability) make the > link congestionned. > From P point of view : traffic is protected, even if some traffic is > dropped due to congestion(CoS should prioritize traffic), it's better > than dropping all. > From PE point of view : some destinations of the PE where maybe not > using the P-P link that fails. But due to congestion of the link, they > become impacted. So impact for the PE is maybe greater than not having > LFA on the core (we are talking about few seconds of impact -> time for > the P to converge). > Note : it's not a one to one mapping of traffic between the P-P link > that fails and the P-PE link used as LFA. It will depend on how many > destinations are using this PE as LFA (and quantity of traffic per > destination). But we could clearly expect congestion as PE links are > sized only for their usage. > Do you think this is a real concern ? > If yes, is there already a proposal/solution to deal this issue ? > - like using TE informations (ISIS subTLV) to take account BW, and so > basically not protecting a link by a lower BW link > - preventing some links to be used as LFA > Thanks for your feedback > --- > Stephane > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorization. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. > Thank you. > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From bashandy@cisco.com Tue Jan 17 09:55:24 2012 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 3665411E809B for ; Tue, 17 Jan 2012 09:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 u9JR457+4PqZ for ; Tue, 17 Jan 2012 09:55:23 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B32BE21F8585 for ; Tue, 17 Jan 2012 09:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=12913; q=dns/txt; s=iport; t=1326822868; x=1328032468; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=8o8KmwMTa1snBceK24A7pnr/9F77ynBeAzjFoE5M2Ps=; b=M3nIxhvubsY+N+UidEyhCoObYI4VLyUKNANML/1XZ+l2exjz6KtZuzfU T1uDhim8K6xKJiO5LtTaZZ7MoDpGOEQNZReh3nOM2zERI6fCUXzqFpO1X BxE2ExmAYT6HppU5Y0LZn/8Agp6WwmK1Vw3ClsFFOHAWnxbbvnlbepHk4 0=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="asc'?scan'208,217";a="126742240" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2012 17:54:27 +0000 Received: from [10.61.99.86] (dhcp-10-61-99-86.cisco.com [10.61.99.86]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0HHsQGg027221; Tue, 17 Jan 2012 17:54:26 GMT Message-ID: <4F15B5CD.60806@cisco.com> Date: Tue, 17 Jan 2012 19:54:21 +0200 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: stephane.litkowski@orange.com Subject: Re: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link References: <2800_1326818146_4F15A362_2800_19426_1_4FC3556A36EE3646A09DAA60429F5335079D19F5@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <2800_1326818146_4F15A362_2800_19426_1_4FC3556A36EE3646A09DAA60429F5335079D19F5@PUEXCBL0.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA8C34C59AAFD209314B264DB" 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: Tue, 17 Jan 2012 17:55:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA8C34C59AAFD209314B264DB Content-Type: multipart/alternative; boundary="------------030900030805030704020203" This is a multi-part message in MIME format. --------------030900030805030704020203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If I understand the concern correctly, the issue is that the PE is used as a remote LFA even though the PE is not connected to links with enough bandwidth. A quick solution is to configure the protecting/repairing routers to only consider certain routers as rLFAs. Admin tags or routing policy can be used to achieve this goal. I believe this would be an internal implementation detail rather than a protocol modification Thanks Ahmed On 1/17/2012 6:35 PM, stephane.litkowski@orange.com wrote: > Hi all, > =20 > I made some simulation based on real topologies on LFA and remote LFA. > I saw some issues related to topologies and I wanted to have some > feedback on it. > =20 > We focus on P-P link failures. > In some ring topologies between Ps (which doesn't work very well with > LFA), alternate Ps are not eligible for LFAs (for some > destinations) but some PEs are eligible providing link protection for > the P-P link failure. > =20 > We tried to apply remote LFA algorithm for non LFA eligible > destinations, and sometimes we have the same thing : PEs are used as > best rLFA because there is no eligible P. > =20 > PE are sometimes meshed with low BW link (compared to core links). So > if P core link fails, traffic will be switched on PE link (during > protection time) and so will potentially (high probability) make the > link congestionned. > =20 > From P point of view : traffic is protected, even if some traffic is > dropped due to congestion(CoS should prioritize traffic), it's better > than dropping all. > =20 > From PE point of view : some destinations of the PE where maybe not > using the P-P link that fails. But due to congestion of the link, they > become impacted. So impact for the PE is maybe greater than not having > LFA on the core (we are talking about few seconds of impact -> time > for the P to converge). > =20 > Note : it's not a one to one mapping of traffic between the P-P link > that fails and the P-PE link used as LFA. It will depend on how many > destinations are using this PE as LFA (and quantity of traffic per > destination). But we could clearly expect congestion as PE links are > sized only for their usage. > =20 > Do you think this is a real concern ? > If yes, is there already a proposal/solution to deal this issue ? > - like using TE informations (ISIS subTLV) to take account BW, and > so basically not protecting a link by a lower BW link > - preventing some links to be used as LFA > =20 > =20 > Thanks for your feedback > =20 > --- > Stephane > =20 > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a et= e altere, deforme ou falsifie. Merci > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorization. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange shall not be liable i= f this message was modified, changed or falsified. > Thank you. > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg --------------030900030805030704020203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If I understand the concern correctly, the issue is that the PE is used as a remote LFA even though the PE is not connected to links with enough bandwidth.

A quick solution is to configure the protecting/repairing routers to only consider certain routers as rLFAs. Admin tags or routing policy can be used to achieve this goal. I believe this would be an internal implementation detail rather than a protocol modification
Thanks

Ahmed


On 1/17/2012 6:35 PM, stephane.litkowski@orange.com wr= ote:
Hi all,
 
I made some simulation based on real topologies on LFA and remote LFA.
I saw some issues related to topologies and I wanted to ha= ve some feedback on it.
 
We focus on P-P link failures.
In some ring topologies between Ps (which doesn't work very= well with LFA),  alternate Ps are not eligible for LFAs = (for some destinations) but some PEs are eligible providing l= ink protection for the P-P link failure.
 
We tried to apply remote LFA algorithm for non LFA eligible destinations, and sometimes we have the same thing  : PE= s are used as best rLFA because there is no eligible P.<= /span>
 
PE are sometimes meshed with low BW link (compared to core links). So if P core link fails, traffic will be switched on PE link (during protection time) and so will potentially= (high probability) make the link congestionned.=
 
From P point of view : traffic is protected, even if some traffic is dropped due to congestion(CoS should prioritize traffic), it's better than dropping all.
 
From PE point of view : some destinations of the PE where maybe not using the P-P link that fails. But due to congestion of the link, they become impacted. So impact for the PE is maybe greater than not having LFA on the core (we are talking about few seconds of impact -> time for the P to converge).
 
Note : it's not a one to one mapping of traffic between the P-P link that fails and the P-PE link used as LFA. It will depend on how many destinations are using this PE as LFA (and quantity of traffic per destination). But we could clearly expect congestion as PE links are sized only for their usage.
 
Do you think this is a real concern ?
If yes, is there already a proposal/solution to deal this issue ?
    - like using TE informations (ISIS subTLV) to take= account BW, and so basically not protecting a <= span class=3D"101201316-17012012">li= nk by a lower BW link
    - preventing some links to be used as LFA
 
 
Thanks for your feedback
 
---
Stephane<= /div>
  
______________________________________________________________=
___________________________________________________________

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

This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if =
this message was modified, changed or falsified.
Thank you.


_______________________________________________
rtgwg mailing list
rtgw=
g@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
--------------030900030805030704020203-- --------------enigA8C34C59AAFD209314B264DB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPFbXR+G19kFA5zIYRAjqEAJ9LpmBBDm52b1BBbAxnXkJnfcQ8nwCfeIFa zxkby6SNwB8vcuZyxYdhg18= =gZ8V -----END PGP SIGNATURE----- --------------enigA8C34C59AAFD209314B264DB-- From stephane.litkowski@orange.com Wed Jan 18 01:25:16 2012 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 A300021F8793 for ; Wed, 18 Jan 2012 01:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyYL5NukGUvp for ; Wed, 18 Jan 2012 01:25:15 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3280B21F8789 for ; Wed, 18 Jan 2012 01:25:15 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id E146918C46D; Wed, 18 Jan 2012 10:25:11 +0100 (CET) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9BAC027C064; Wed, 18 Jan 2012 10:25:11 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jan 2012 10:25:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCD5C3.137C7346" Subject: RE: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link Date: Wed, 18 Jan 2012 10:25:10 +0100 Message-ID: <21833_1326878711_4F168FF7_21833_2077_14_4FC3556A36EE3646A09DAA60429F5335079D1C12@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4F15B5CD.60806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link Thread-Index: AczVQQ7h8zIOxSR5T2KkBTpKTUQk0gAgK1Aw References: <2800_1326818146_4F15A362_2800_19426_1_4FC3556A36EE3646A09DAA60429F5335079D19F5@PUEXCBL0.nanterre.francetelecom.fr> <4F15B5CD.60806@cisco.com> From: To: "Ahmed Bashandy" , X-OriginalArrivalTime: 18 Jan 2012 09:25:10.0615 (UTC) FILETIME=[134E7670:01CCD5C3] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.18.82115 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: Wed, 18 Jan 2012 09:25:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCD5C3.137C7346 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 [Ahmed] > If I understand the concern correctly, the issue is that the PE is used as a remote LFA even though the PE is not connected to links with=20= =20 > enough bandwidth. > A quick solution is to configure the protecting/repairing routers to only consider certain routers as rLFAs. Admin tags or routing policy >can be used to achieve this goal. I believe this would be an internal implementation detail rather than a protocol modification =20 [SLI] Yes the problem comes even with LFA or rLFA.=20 =20 =20 [Anton]=20 > if link which you want to exclude is local to the calculating router then implementation is trivial and doesn't need any signaling.=20 >If link is not local then this is very similar to more general problem of non-local SRLG. It was discussed but computation is relatively complex and still needs investigation. [SLI] I'm talking about only local links, so I agree that it should be quite "easy" to implement, but I'm not aware of such implementation today. Maybe it can be dealed with local SRLG but will be hard to operate as SRLG database will require manual configuration/maintenance. =20 Don't you think this concern should be highlighted somewhere (even if no modification required) to make people aware of this ? =20 Best Regards=20 =20 Stephane =20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if th= is message was modified, changed or falsified. Thank you. ------_=_NextPart_001_01CCD5C3.137C7346 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
[Ahmed]
> If I understand the concer= n=20 correctly, the issue is that the PE is used as a remote LFA even though the= PE=20 is not connected to links with  
> enough bandwidth.
> <= /SPAN>A=20 quick solution is to configure the protecting/repairing routers to only con= sider=20 certain routers as rLFAs. Admin tags or routing policy&nbs= p; >can  be used to achiev= e this=20 goal. I believe this would be an internal implementation detail rather than= a=20 protocol modification
 
[SLI] Yes the problem comes even with LFA or= =20 rLFA. 
 
 <= BR>[Anton] 
=

 > if link which you wa= nt to=20 exclude is local to the calculating router then implementation is trivial a= nd=20 doesn't need any signaling. 

 >If link is=20 not local then this is very similar to more general problem of non-local SR= LG.=20 It was discussed but computation is relatively complex and still needs=20 investigation.

 <= FONT=20 face=3DArial color=3D#0000ff size=3D2>[SLI] I'm talking about only local li= nks, so I=20 agree that it should be quite "easy" to implement, but I'm not aware of suc= h=20 implementation today. Maybe it can be dealed with local SRLG but will be ha= rd to=20 operate as SRLG database will require manual=20 configuration/maintenance.
 
Don't you think this concern should be highlighted= =20 somewhere (even if no modification required) to make people aware of=20 this ?
 
Best Regards
 
Stephane
 
_________________=
___________________________________________________________________________=
_____________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th=
is message was modified, changed or falsified.
Thank you.
------_=_NextPart_001_01CCD5C3.137C7346-- From internet-drafts@ietf.org Wed Jan 18 02:44:00 2012 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 6574B21F87D1; Wed, 18 Jan 2012 02:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, 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 UamRiOeOS18T; Wed, 18 Jan 2012 02:43:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB54221F8746; Wed, 18 Jan 2012 02:43:59 -0800 (PST) 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-applicability-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120118104359.6895.5226.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2012 02:43:59 -0800 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: Wed, 18 Jan 2012 10:44:00 -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 Gr= oup of the IETF. Title : LFA applicability in SP networks Author(s) : Clarence Filsfils Pierre Francois Filename : draft-ietf-rtgwg-lfa-applicability-06.txt Pages : 34 Date : 2012-01-18 In this document, we analyze the applicability of the Loop-Free Alternates method of providing IP fast re-route in both the core and the access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFA to different network topologies, with special emphasis on the access parts of the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-lfa-applicability-06.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtgwg-lfa-applicability-06.txt From alvaro.retana@hp.com Wed Jan 18 06:55:42 2012 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 3BEFA21F86F3 for ; Wed, 18 Jan 2012 06:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.001, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 5FXoqD6cLHTV for ; Wed, 18 Jan 2012 06:55:41 -0800 (PST) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by ietfa.amsl.com (Postfix) with ESMTP id 723DC21F86CB for ; Wed, 18 Jan 2012 06:55:41 -0800 (PST) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id D453B14350; Wed, 18 Jan 2012 14:55:40 +0000 (UTC) Received: from G2W0893.americas.hpqcorp.net (16.238.89.28) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 18 Jan 2012 14:52:43 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G2W0893.americas.hpqcorp.net ([16.238.89.28]) with mapi; Wed, 18 Jan 2012 14:52:43 +0000 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Date: Wed, 18 Jan 2012 14:52:35 +0000 Subject: FW: Document Action: 'LFA applicability in SP networks' to Informational RFC (draft-ietf-rtgwg-lfa-applicability-06.txt) Thread-Topic: Document Action: 'LFA applicability in SP networks' to Informational RFC (draft-ietf-rtgwg-lfa-applicability-06.txt) Thread-Index: AczV7/WDDcWdXnXwS9+PtrK29MbQ9QAAM8Rw Message-ID: <24646CE17826CF4A8DF71F9856C7E656595A34F8AD@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-rtgwg-lfa-applicability@tools.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: Wed, 18 Jan 2012 14:55:42 -0000 FYI -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of The IESG Sent: Wednesday, January 18, 2012 9:46 AM To: IETF-Announce Cc: RFC Editor Subject: Document Action: 'LFA applicability in SP networks' to Information= al RFC (draft-ietf-rtgwg-lfa-applicability-06.txt) The IESG has approved the following document: - 'LFA applicability in SP networks' (draft-ietf-rtgwg-lfa-applicability-06.txt) as an Informational RFC This document is the product of the Routing Area Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-applicability/ Technical Summary In this document, the applicability of LoopFree Alternates in both core and access parts of Service Provider networks is analyzed. Design guides are provided to favor their applicability where relevant, typically in the access part of the network. Working Group Summary There is consensus in the WG to publish this document. Document Quality This document analyzes the applicability and provides design and deployment guidance for LFAs (as defined in RFC 5714 - IP Fast Reroute Framework). There are no changes suggested to the original framework. Personnel Alvaro Retana is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. RFC Editor Note Though out the document please: s/ISIS/IS-IS/ s/LoopFree/loop-free/ Then In section 1 Old In this document, we analyze the applicability of LoopFree Alternates in both core and access parts of Service Provider networks. New In this document, we analyze the applicability of Loop-Free Alternates (LFA= ) [RFC5714][RFC5286] in both core and access parts of Service Provider (SP) networks. End =3D=3D=3D=3D=3D In References add normative ref to RFC 5286 =3D=3D=3D=3D=3D In Section 8 Old This document does not introduce any new security considerations. New The security considerations applicable to LFAs are described in=20 RFC5286. This document does not introduce any new security=20 considerations. End =3D=3D=3D=3D=3D _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From akatlas@gmail.com Wed Jan 18 08:06:30 2012 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 7AE3B21F85DD for ; Wed, 18 Jan 2012 08:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wWrueZr9zSTu for ; Wed, 18 Jan 2012 08:06:29 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7B6C21F85D4 for ; Wed, 18 Jan 2012 08:06:29 -0800 (PST) Received: by ghrr16 with SMTP id r16so1637338ghr.31 for ; Wed, 18 Jan 2012 08:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wPJ7YGuUhmkyGajVAS7bqACy50hYn1QzmMjfBzbL9QY=; b=RWgV9yIlNhqkPWFKbIR6+baYUUF8DhOrdNrmv8GDlKFxVqv1234bsZLzrTbjkxd70F SptchiSx7n8bvgFbLBlENPqntj9wu9UbUcqP9ElRT1jseLtC/2asjjy71ALwt7Ix9SyZ 1M3hDVSi2hwxLs9NIqfskM8aGaiC7mr39rC8M= MIME-Version: 1.0 Received: by 10.50.88.129 with SMTP id bg1mr23138541igb.10.1326902789252; Wed, 18 Jan 2012 08:06:29 -0800 (PST) Received: by 10.50.237.42 with HTTP; Wed, 18 Jan 2012 08:06:29 -0800 (PST) In-Reply-To: <21833_1326878711_4F168FF7_21833_2077_14_4FC3556A36EE3646A09DAA60429F5335079D1C12@PUEXCBL0.nanterre.francetelecom.fr> References: <2800_1326818146_4F15A362_2800_19426_1_4FC3556A36EE3646A09DAA60429F5335079D19F5@PUEXCBL0.nanterre.francetelecom.fr> <4F15B5CD.60806@cisco.com> <21833_1326878711_4F168FF7_21833_2077_14_4FC3556A36EE3646A09DAA60429F5335079D1C12@PUEXCBL0.nanterre.francetelecom.fr> Date: Wed, 18 Jan 2012 11:06:29 -0500 Message-ID: Subject: Re: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link From: Alia Atlas To: stephane.litkowski@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Wed, 18 Jan 2012 16:06:30 -0000 Stephane, For local links, it makes sense to have the ability to administratively allow/disallow their use as an alternate. This is what I implemented when at Avici. If you read RFC5286, step 3 in the example algorithm in Sec 3.6 says " 3. If H_h.link is administratively allowed to be used as an alternate, " Some of the feedback from the LFA Applicability draft is that we really should have a document that talks about management as well as MIBs. Would you be interested in working on that? Alia On Wed, Jan 18, 2012 at 4:25 AM, wrote: > > [Ahmed] >>=A0If I understand the concern correctly, the issue is that the PE is use= d as >> a remote LFA even though the PE is not connected to links with >>=A0enough bandwidth. >>=A0A quick solution is to configure the protecting/repairing routers to o= nly >> consider certain routers as rLFAs. Admin tags or routing policy=A0 >can= =A0=A0be >> used to achieve this goal. I believe this would be an internal >> implementation detail rather than a protocol modification > > [SLI] Yes the problem comes even with LFA=A0or rLFA. > > > [Anton] > > =A0>=A0if link which you want to exclude is local to the calculating rout= er then > implementation is trivial and doesn't need any signaling. > > =A0>If link is not local then this is very similar to more general proble= m of > non-local SRLG. It was discussed but computation is relatively complex an= d > still needs investigation. > > =A0[SLI] I'm talking about only local links, so I agree that it should be > quite "easy" to implement, but I'm not aware of such implementation today= . > Maybe it can be dealed with local SRLG but will be hard to operate as SRL= G > database will require manual configuration/maintenance. > > Don't you think this concern should be highlighted somewhere (even if no > modification required) to make people aware of this=A0? > > Best Regards > > Stephane > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorization. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, France Telecom - Orange shall not be liable if > this message was modified, changed or falsified. > Thank you. > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From stephane.litkowski@orange.com Thu Jan 19 06:45:30 2012 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 8848221F862A for ; Thu, 19 Jan 2012 06:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37LAOKoSpS6m for ; Thu, 19 Jan 2012 06:45:29 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 94D0B21F85FF for ; Thu, 19 Jan 2012 06:45:29 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3562B22C3EA; Thu, 19 Jan 2012 15:45:28 +0100 (CET) Received: from puexcc31.nanterre.francetelecom.fr (unknown [10.168.74.8]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1229E4C06C; Thu, 19 Jan 2012 15:45:28 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc31.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jan 2012 15:45:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link Date: Thu, 19 Jan 2012 15:45:27 +0100 Message-ID: <15828_1326984328_4F182C88_15828_3291_1_4FC3556A36EE3646A09DAA60429F533507A24D12@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link Thread-Index: AczV+ySZk3f5oB+jSWCfFzDEq/nswQAvLNYw References: <2800_1326818146_4F15A362_2800_19426_1_4FC3556A36EE3646A09DAA60429F5335079D19F5@PUEXCBL0.nanterre.francetelecom.fr><4F15B5CD.60806@cisco.com><21833_1326878711_4F168FF7_21833_2077_14_4FC3556A36EE3646A09DAA60429F5335079D1C12@PUEXCBL0.nanterre.francetelecom.fr> From: To: "Alia Atlas" X-OriginalArrivalTime: 19 Jan 2012 14:45:28.0381 (UTC) FILETIME=[FC6696D0:01CCD6B8] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.19.123030 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, 19 Jan 2012 14:45:30 -0000 Hi Alia, Thanks for your feedback. Yes, some work is needed on management part. Some global items to address are already proposed in RFC 5714 section 6 (Ma= nagement considerations). The main issue I can see is are we ready for that now ? Or should we wait f= or LFA deployment start in SP networks to have a better feedback on needs. = I don't know where are other SPs regarding LFA deployment. If the work is t= oo theorical, it may not fit the SP needs and so will never be implemented = or used. We internally have already few ideas on what is needed as LFA is deployed i= n some areas. Does someone already started this work ? Thanks Stephane -----Message d'origine----- De : Alia Atlas [mailto:akatlas@gmail.com]=20 Envoy=E9 : mercredi 18 janvier 2012 17:06 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Ahmed Bashandy; asmirnov@cisco.com; rtgwg@ietf.org Objet : Re: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-app= licability =3D> using low BW link as LFA to protect high BW link Stephane, For local links, it makes sense to have the ability to administratively all= ow/disallow their use as an alternate. This is what I implemented when at = Avici. If you read RFC5286, step 3 in the example algorithm in Sec 3.6 says " 3. If H_h.link is administratively allowed to be used as an alternate, " Some of the feedback from the LFA Applicability draft is that we really sho= uld have a document that talks about management as well as MIBs. Would you= be interested in working on that? Alia On Wed, Jan 18, 2012 at 4:25 AM, wrote: > > [Ahmed] >>=A0If I understand the concern correctly, the issue is that the PE is=20 >>used as a remote LFA even though the PE is not connected to links=20 >>with >>=A0enough bandwidth. >>=A0A quick solution is to configure the protecting/repairing routers to= =20 >>only consider certain routers as rLFAs. Admin tags or routing policy=A0= =20 >>>can=A0=A0be used to achieve this goal. I believe this would be an=20 >>internal implementation detail rather than a protocol modification > > [SLI] Yes the problem comes even with LFA=A0or rLFA. > > > [Anton] > > =A0>=A0if link which you want to exclude is local to the calculating=20 > router then implementation is trivial and doesn't need any signaling. > > =A0>If link is not local then this is very similar to more general=20 > problem of non-local SRLG. It was discussed but computation is=20 > relatively complex and still needs investigation. > > =A0[SLI] I'm talking about only local links, so I agree that it should=20 > be quite "easy" to implement, but I'm not aware of such implementation to= day. > Maybe it can be dealed with local SRLG but will be hard to operate as=20 > SRLG database will require manual configuration/maintenance. > > Don't you think this concern should be highlighted somewhere (even if=20 > no modification required) to make people aware of this=A0? > > Best Regards > > Stephane > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, France Telecom - Orange decline toute responsabilite si=20 > ce message a ete altere, deforme ou falsifie. Merci > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorization. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, France Telecom - Orange shall not be liable=20 > if this message was modified, changed or falsified. > Thank you. > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if th= is message was modified, changed or falsified. Thank you. From internet-drafts@ietf.org Thu Jan 26 15:27:14 2012 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 E718F21F8603; Thu, 26 Jan 2012 15:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 H0sfsLG51FKX; Thu, 26 Jan 2012 15:27:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D21521F85E3; Thu, 26 Jan 2012 15:27:14 -0800 (PST) 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-mrt-frr-architecture-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120126232714.5975.83346.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2012 15:27:14 -0800 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, 26 Jan 2012 23:27:15 -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 Gr= oup of the IETF. Title : An Architecture for IP/LDP Fast-Reroute Using Maximally = Redundant Trees Author(s) : Alia Atlas Robert Kebler Maciek Konstantynowicz Gabor Sandor Enyedi Andras Csaszar Russ White Mike Shand Filename : draft-ietf-rtgwg-mrt-frr-architecture-00.txt Pages : 21 Date : 2012-01-26 As IP and LDP Fast-Reroute are increasingly deployed, the coverage limitations of Loop-Free Alternates are seen as a problem that requires a straightforward and consistent solution for IP and LDP, for unicast and multicast. This draft describes an architecture based on redundant backup trees where a single failure can cut a point-of-local-repair from the destination only on one of the pair of redundant trees. One innovative algorithm to compute such topologies is maximally disjoint backup trees. Each router can compute its next-hops for each pair of maximally disjoint trees rooted at each node in the IGP area with computational complexity similar to that required by Dijkstra. The additional state, address and computation requirements are believed to be significantly less than the Not-Via architecture requires. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-mrt-frr-architecture-0= 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtgwg-mrt-frr-architecture-00= .txt From internet-drafts@ietf.org Mon Jan 30 13:53:47 2012 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 1315511E80BB; Mon, 30 Jan 2012 13:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, 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 DUX8XCyhnmHq; Mon, 30 Jan 2012 13:53:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E123711E80BA; Mon, 30 Jan 2012 13:53:29 -0800 (PST) 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-cl-requirement-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120130215329.13499.84153.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 13:53:29 -0800 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, 30 Jan 2012 21:53:47 -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 Gr= oup of the IETF. Title : Requirements for MPLS Over a Composite Link Author(s) : Curtis Villamizar Dave McDysan So Ning Andrew Malis Lucy Yong Filename : draft-ietf-rtgwg-cl-requirement-05.txt Pages : 16 Date : 2012-01-30 There is often a need to provide large aggregates of bandwidth that are best provided using parallel links between routers or MPLS LSR. In core networks there is often no alternative since the aggregate capacities of core networks today far exceed the capacity of a single physical link or single packet processing element. The presence of parallel links, with each link potentially comprised of multiple layers has resulted in additional requirements. Certain services may benefit from being restricted to a subset of the component links or a specific component link, where component link characteristics, such as latency, differ. Certain services require that an LSP be treated as atomic and avoid reordering. Other services will continue to require only that reordering not occur within a microflow as is current practice. Current practice related to multipath is described briefly in an appendix. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-cl-requirement-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtgwg-cl-requirement-05.txt From curtis@occnc.com Mon Jan 30 14:46:39 2012 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 1011121F873A for ; Mon, 30 Jan 2012 14:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 41BTO3FpgsrG for ; Mon, 30 Jan 2012 14:46:38 -0800 (PST) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 410C721F8739 for ; Mon, 30 Jan 2012 14:46:37 -0800 (PST) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q0UMkVGv066793; Mon, 30 Jan 2012 14:46:32 -0800 (PST) (envelope-from curtis@occnc.com) Message-Id: <201201302246.q0UMkVGv066793@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: Composite Link (CL) Requirements (draft-ietf-rtgwg-cl-requirement-05) From: Curtis Villamizar Date: Mon, 30 Jan 2012 14:46:31 -0800 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:46:39 -0000 FYI - I was going through email and noticed that the -04 version was expired and that I was the person that was supposed to submit the -05 version after the Taipei IETF. (Oops!) Title : Requirements for MPLS Over a Composite Link Author(s) : Curtis Villamizar Dave McDysan So Ning Andrew Malis Lucy Yong Filename : draft-ietf-rtgwg-cl-requirement-05.txt Pages : 16 Date : 2012-01-30 Changes since October 24, 2011 to now: Changed date from October 24, 2011 to January 30, 2012 Changes since -04 version were presented in the IETF meeting by Ning So, but I missed the submission date even though there were no changes between October 24 and the submission deadline. Changes since -04 version: Date changed. One author affiliation changed (me). Section 6 "Management Requirements" was added as discussed on list. Section numbers after section 6 shifted. Appendix A and B were removed and are moving to other documents. Appendix A will be moved into a "CL Use Cases" document. Appendix B will be merged into the framework or may appear in a separate document that will simply document current practices. FR#21 was split into FR#21 and FR#22 to be more clear. Second paragraph (informational) in DR#1 was deleted. IEEE 802.1AX, ITU-T Y.154[01] deleted from references (was cited only in the appendices that were deleted. We have good agreement on cl-framwork among authors and AFAIK on list at this point. We had last called but decided to do a last call on cl-requirements and cl-framework together at a later date. To do: 1. Complete and submit "CL Use Cases" (after discussing with co-authors). 2. Decide among authors whether former Appendix B should be part of the framework or expanded and submitted as a separate document. 3. Replace the following in "CL Requirements" (after #1, #2): Remove from Appendix A: The network operator practices appendix has been moved to a separate document. When that document has an XML I-D tag the references to this appendix will be changed to that document and this appendix will be deleted. Remove from Appendix B: The multipath standards and techniques appendix has been moved to a separate document. When that document has an XML I-D tag the references to this appendix will be changed to that document and this appendix will be deleted. The appendices may be deleted and replaced with a simple citation to related work in the main body and reference entry added. 4. Merge content of draft-villamizar-cl-framework (discussed at Quebec IETF) into cl-framework. Make other framework changes as discussed among authors. Will need a bit of discussion among co-authors before submitting. I'm going through the email from August to now in hopes of picking up all the changes to use-cases and cl-framwork suggested by co-authors. Discussion related to cl-framework was lively at Quebec and just after Quebec so cl-framwork will take at least a few cycles among the co-authors before seeing the light of day. Curtis From alvaro.retana@hp.com Tue Jan 31 13:12:18 2012 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 E627F21F8554 for ; Tue, 31 Jan 2012 13:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.598 X-Spam-Level: X-Spam-Status: No, score=-109.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 MR7lqcOPextK for ; Tue, 31 Jan 2012 13:12:17 -0800 (PST) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8F53721F845C for ; Tue, 31 Jan 2012 13:12:17 -0800 (PST) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id BE7A73839C; Tue, 31 Jan 2012 21:12:16 +0000 (UTC) Received: from G1W0397.americas.hpqcorp.net (16.236.31.21) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 31 Jan 2012 21:11:35 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.12]) by G1W0397.americas.hpqcorp.net ([16.236.31.21]) with mapi; Tue, 31 Jan 2012 21:11:34 +0000 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Date: Tue, 31 Jan 2012 21:11:29 +0000 Subject: RE: WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses Thread-Topic: WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses Thread-Index: AczP0PbOKJrmPJkgRQOoV2xhWFeolgQX4zKw Message-ID: <24646CE17826CF4A8DF71F9856C7E656595B2024A6@GVW1338EXA.americas.hpqcorp.net> References: <24646CE17826CF4A8DF71F9856C7E6565959E269F7@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E6565959E269F7@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_24646CE17826CF4A8DF71F9856C7E656595B2024A6GVW1338EXAame_" MIME-Version: 1.0 Cc: "draft-ietf-rtgwg-ipfrr-notvia-addresses@tools.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: Tue, 31 Jan 2012 21:12:19 -0000 --_000_24646CE17826CF4A8DF71F9856C7E656595B2024A6GVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! Just to be thorough, we're going to extend the WGLC one extra week (until F= ebruary 7, 2012). As a reminder, this document is being published as an Informational RFC for= completeness purposes...as has been discussed in the mailing list and live= meetings. Please reply to this message if you are NOT in favor of having this documen= t progress. Thanks! Alvaro. From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of R= etana, Alvaro Sent: Tuesday, January 10, 2012 2:49 PM To: rtgwg@ietf.org Cc: draft-ietf-rtgwg-ipfrr-notvia-addresses@tools.ietf.org Subject: WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses Happy New Year! This message is to start a Working Group Last Call for 'IP Fast Reroute Usi= ng Not-via Addresses' (http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-no= tvia-addresses-08). This last call will end on January 26, 2012. The intent is to publish this document as an Informational RFC. Please send any comments to the WG list. Thanks! Alvaro. --_000_24646CE17826CF4A8DF71F9856C7E656595B2024A6GVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

Just to be thorough, we’re going to extend the WGL= C one extra week (until February 7, 2012).

 

As a reminder, this document is= being published as an Informational RFC for completeness purposes…as= has been discussed in the mailing list and live meetings.

 

Please reply to= this message if you are NOT in favor of having this document progress.

&= nbsp;

Th= anks!

 

Alvaro.

 

From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Beh= alf Of Retana, Alvaro
Sent: Tuesday, January 10, 2012 2:49 PM=
To: rtgwg@ietf.org
Cc: draft-ietf-rtgwg-ipfrr-notvia-a= ddresses@tools.ietf.org
Subject: WGLC:draft-ietf-rtgwg-ipfrr-notv= ia-addresses

&nb= sp;

Happy New Year!

This message is to start a Working Group Last Call for ‘IP Fast = Reroute Using Not-via Addresses’ (http://tools.ietf.org/html/d= raft-ietf-rtgwg-ipfrr-notvia-addresses-08).

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";font-weig= ht:normal'>This last call will end on January 26, 2012.

The intent is to publish this document as an Information= al RFC.

Please send any comments to t= he WG list.

Thanks!=

Alvaro.

= --_000_24646CE17826CF4A8DF71F9856C7E656595B2024A6GVW1338EXAame_--