From sriganeshkini@gmail.com Mon Apr 4 02:02:32 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98213A6935 for ; Mon, 4 Apr 2011 02:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDuY6um6Ugsb for ; Mon, 4 Apr 2011 02:02:32 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 085A23A659A for ; Mon, 4 Apr 2011 02:02:31 -0700 (PDT) Received: by qyk29 with SMTP id 29so825789qyk.10 for ; Mon, 04 Apr 2011 02:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=wSE2plnXMSdjL0V76VF8zRFF59ainwlw43NzveL7QBg=; b=Q+X5SKiFsUrRaOIq6x4sUliO0mHu6mYrh+lBDLvVHo80xbi1nrn+pnlmf6jSM10C54 AIY8AdF3abrjvPEAlEkD6kXsVoYtKov++NoyyKO8bc1mWYbY3iGg4gYbHEFE2UAzTHJG /GTFvPqi2h2X2LggbcChKl1A7/AB+66nIS9nc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; b=dQUMgH1G/eSZ6wvla7Y0Z7JnQpfqSmcA8oKCHKQ5dW/t771pVGVZb5lYJhi7rty7Ym aChJhZ+K5NChDld/4snf8YwjsOmRttZEr68EDl5zHRtbxt0Zr/3jhzq1Rz0aIXi0t0/X pk4GNzfxuk4p2aC0fAZc6szmMMRGVOIejBFP4= Received: by 10.229.67.66 with SMTP id q2mr5324244qci.282.1301907854107; Mon, 04 Apr 2011 02:04:14 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.231.143 with HTTP; Mon, 4 Apr 2011 02:03:44 -0700 (PDT) From: Sriganesh Kini Date: Mon, 4 Apr 2011 02:03:44 -0700 X-Google-Sender-Auth: SY-ZdOGjYN-dLb1vsbsyUgO3yNA Message-ID: Subject: Mail regarding draft-ietf-rtgwg-lfa-applicability To: draft-ietf-rtgwg-lfa-applicability@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 09:02:32 -0000 Hello Clarence and other authors, A couple comments 1. Section 2 Terminology - "A per prefix LFA at destination D for a node S ..." should read "A per prefix LFA at node S for destination D..." 2. The equation for link/node protecting assumes that all downstream paths are not used. Given that ISIS (which allows such paths) is used as a reference, it is necessary to state this assumption. Otherwise the equations must be modified. Thanks -- - Sri From mshand@cisco.com Tue Apr 5 05:43:58 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800A528C0EF for ; Tue, 5 Apr 2011 05:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPPPHzSbUYAQ for ; Tue, 5 Apr 2011 05:43:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5139128C14E for ; Tue, 5 Apr 2011 05:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mshand@cisco.com; l=1470; q=dns/txt; s=iport; t=1302007535; x=1303217135; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=l9wKDUAwe9Xs+7+U74AU/hcnf6zTVtOmoNc0U6UMC3s=; b=GcrUVuEOTAMz8gBrEq83gluCdZpdpXu7exH+s50xfwHDdA5qmhohn/h8 sGa8OOID4DIuYf+4f98fVePMpVv1rqXtMbATbjGms8gEh0BCbzoR7Up/x w0vr39gcV9pDPsA1xJ4nKbW0i8hXsSgn8WTjykxreHotAnX5vU67tUgXf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkHAK0Om02Q/khNgWdsb2JhbACYYI0JFAEBFiYlplycLYVrBI0lg1s X-IronPort-AV: E=Sophos;i="4.63,304,1299456000"; d="scan'208";a="82249596" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2011 12:45:33 +0000 Received: from [64.103.65.46] (printer-xx-dbba4e.cisco.com [64.103.65.46]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p35CjXDQ012177 for ; Tue, 5 Apr 2011 12:45:33 GMT Message-ID: <4D9B0EED.5080702@cisco.com> Date: Tue, 05 Apr 2011 13:45:33 +0100 From: mike shand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: Mail regarding draft-ietf-rtgwg-lfa-applicability References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 12:43:58 -0000 Regarding 2, yes, of course, it is not possible to use downstream paths for "normal" routing in conjunction with LFAs, since they would loop. If you have downstream paths deployed at all, then it is only possible to use downstream paths as repairs. This is equivalent to dealing with multiple simultaneous failures, where, of course LFAs have the potential for looping, but downstream paths do not. While this is well known, it has not been considered to be a problem to date because as far as I know, there are no implementations of downstream path support in IS-IS, despite it having been permitted by ISO/IEC 10589 (clause 7.2.6.2) for the last 20 years. However, you are right that it would be useful to draw attention to this in the draft. Note that while IS-IS specifically permits such paths, the concept of downstream paths could be applied to any hop by hop forwarding routing paradigm. Mike On 04/04/2011 10:03, Sriganesh Kini wrote: > Hello Clarence and other authors, > > A couple comments > > 1. Section 2 Terminology - "A per prefix LFA at destination D for a > node S ..." should read "A per prefix LFA at node S for destination > D..." > > 2. The equation for link/node protecting assumes that all downstream > paths are not used. Given that ISIS (which allows such paths) is used > as a reference, it is necessary to state this assumption. Otherwise > the equations must be modified. > > Thanks From Andras.Csaszar@ericsson.com Tue Apr 5 06:10:57 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E2428C10D for ; Tue, 5 Apr 2011 06:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.72 X-Spam-Level: X-Spam-Status: No, score=-5.72 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3V-kqdtHbTx for ; Tue, 5 Apr 2011 06:10:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5562028C0FE for ; Tue, 5 Apr 2011 06:10:47 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-2a-4d9b153e58cd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id ED.4C.09202.E351B9D4; Tue, 5 Apr 2011 15:12:30 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.133]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 5 Apr 2011 15:12:30 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: "rtgwg@ietf.org" Date: Tue, 5 Apr 2011 15:12:29 +0200 Subject: RE: fn-transport/ipfrr drafts Thread-Topic: fn-transport/ipfrr drafts Thread-Index: AcvuEPsMZcHWm7VeSfqbDajC5qgxFgFgbJlg Message-ID: <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> References: <0ED867EB33AB2B45AAB470D5A64CDBF60CAB204D66@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF60CAB204D66@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 13:10:58 -0000 Dear All, Note that fn-transport already is at version 01. Links to the docs: http://tools.ietf.org/html/draft-lu-fn-transport-01 http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00 We'd really appreciate comments and suggestions.=20 Andr=E1s > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20 > On Behalf Of Jeff Tantsura > Sent: 2011. m=E1rcius 29. 14:58 > To: rtgwg@ietf.org > Subject: fn-transport/ipfrr drafts >=20 > Hi rtgwg, >=20 > The authors would like to solicit comments from the workgroup. >=20 > draft-lu-fn-transport-00 > draft-csaszar-ipfrr-fn-00 >=20 > Thank you in advance! >=20 > Regards, > Jeff =20 >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > = From curtis@occnc.com Tue Apr 5 14:22:41 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167093A67D7 for ; Tue, 5 Apr 2011 14:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJCm8eNkwIcO for ; Tue, 5 Apr 2011 14:22:40 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 0F5AA3A67C1 for ; Tue, 5 Apr 2011 14:22:39 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p35LO0ib061406; Tue, 5 Apr 2011 17:24:00 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104052124.p35LO0ib061406@harbor.orleans.occnc.com> To: Lucy yong , "So, Ning" , "McDysan, David E (Dave)" , "Malis, Andrew G (Andy)" , "eosborne@cisco.com" , Tony Li Subject: draft-so-yong-rtgwg-cl-framework-03 comments From: Curtis Villamizar Date: Tue, 05 Apr 2011 17:24:00 -0400 Sender: curtis@occnc.com Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 05 Apr 2011 21:22:41 -0000 Here are some comments on draft-so-yong-rtgwg-cl-framework-03. BTW- We should take this discussion to the WG list so that it is archived. The author list with a few people added covered most people that had been active on the list anyway. These are comments on "what is there". I will have to comment later on "what is not there". A lot is missing that should be there if this were to be a reasonably complete framework document. 1. In a few places the following is specified: "If two unidirectional LSPs are used to construct a component link, they MUST be co-routed." LSP may be unidirectional, associated bidirectional, or corouted bidirectional. There is no such thing as a "corouted unidirectional pair" since a make-before-break reroute, or any reroute is done on each LSP independently of the other. Maybe this could be put in one place and replaced with SHOULD since MUST is impossible during reroute. A corouted bidirectional LSP will fail on a make-before-break reroute if one direction can't come up so it always remains either corouted or down. 2. The requiement to make all CL LSP corouted is a new requiement. Requirments belong in draft-ietf-rtgwg-cl-requirement, so if we've missed some we SHOULD tell the IESG that we need to respin cl-requirement already. Otherwise we should drop this from the framework. No reason is given to require corouted. 3. The framework states that "Both LDP [RFC5036] and RSVP-TE [RFC3209] can be used to signal a LSP over a composite link. The router of composite link ingress MUST place the LSP on the component link that meets the LSP criteria indicated in the signal message." This is a framework so we have to say *how* LDP and RSVP-TE will be used to signal a LSP over a composite link. We should not define the protocol bits, just describe what information needs to be exchanged in order for this to happen. We can cite the existing LDP requirements in cl-requirements. The framework needs to take the next step and indicate what is necessary to meet these requirements (DR#1, DR#2, and DR#3). 4. In section 5, "The process MUST support locally and gracefully traffic movement process among component links. The protocol that facilitates this process between two composite link end points is for further study." Again, this is a requiement and the draft is a framework draft. It is already covered in FR#12 in cl-requirements. 5. Section 6, "Composite Link in Management Plane" contains nothing but new requirements. Every sentence but one has the word MUST in it. Management Plane MUST keep tracking a composite link and its individual composite link status and configuration. Management Plane MUST be able to make any component link in a composite link active and de-activate in order to facilitate operation maintenance task. The routers of a composite link resides MUST perform the redistribution of the traffic flows on a de-activated link to other component links based on the traffic flow TE criteria. Management Plane MUST be able to configure a LSP over a composite link and be able to select a component link for the LSP. Management Plane MUST be able to trace which component link a LSP is assigned to and monitor individual component link and composite link performance. Management Plane MUST be able to ping individual component link within a composite link. Management Plane should build the proper commands to allow operator execute an optimization process. The last sentence has "should" in lower case. It is not clear what this last sentence means. Note that if we have missed a whole block of requirements, then we should pull draft-ietf-rtgwg-cl-requirement out of IESG (if it got that far) or out of AD review and give it another spin, adding the requirements that were missed. Curtis From curtis@occnc.com Tue Apr 5 14:36:13 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B3A3A67E1 for ; Tue, 5 Apr 2011 14:36:13 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char E1 hex): To: Andr\341s Cs\341sz\341r ; Tue, 5 Apr 2011 14:36:12 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 2959B3A67C1 for ; Tue, 5 Apr 2011 14:36:12 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p35LbquQ061587; Tue, 5 Apr 2011 17:37:52 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104052137.p35LbquQ061587@harbor.orleans.occnc.com> To: András Császár From: Curtis Villamizar Subject: Re: fn-transport/ipfrr drafts In-reply-to: Your message of "Tue, 05 Apr 2011 15:12:29 +0200." <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> Date: Tue, 05 Apr 2011 17:37:52 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 05 Apr 2011 21:36:13 -0000 In message <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> András Császár writes: > > Dear All, > > Note that fn-transport already is at version 01. Links to the docs: > > http://tools.ietf.org/html/draft-lu-fn-transport-01 > http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00 > > We'd really appreciate comments and suggestions. > > András Same comment as on the OSPF mailing list. This is attacking a non-problem. Flooding time is not a problem on modern implementations, unless the implementation is badly designed or badly coded. IPFRR is intended to eliminate the need for an SPF and route download and the need to contact any other router in any way to get an initial repair done. That is a different problem. Curtis > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] > > On Behalf Of Jeff Tantsura > > Sent: 2011. március 29. 14:58 > > To: rtgwg@ietf.org > > Subject: fn-transport/ipfrr drafts > > > > Hi rtgwg, > > > > The authors would like to solicit comments from the workgroup. > > > > draft-lu-fn-transport-00 > > draft-csaszar-ipfrr-fn-00 > > > > Thank you in advance! > > > > Regards, > > Jeff From akatlas@gmail.com Tue Apr 5 17:58:40 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3E23A68D2 for ; Tue, 5 Apr 2011 17:58:40 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBPNaRiXWCRk for ; Tue, 5 Apr 2011 17:58:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0FC913A682D for ; Tue, 5 Apr 2011 17:58:37 -0700 (PDT) Received: by iwn39 with SMTP id 39so1153707iwn.31 for ; Tue, 05 Apr 2011 18:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mjHhEQ4iwVOvMf4YAmUpxWPUXVD2R+Mg0kDZMFH2JR0=; b=UUUtHns5V5XPyjaFBp2axqjf/yvigKVDTyeYTNCd1aWeTtDgkXU+aLTRJlyiXtotZk 5qutOSe6wYwC9cIMoCQ7Be0K3TjHWlh+o/scQGYKHQ8QgZBewEiF1KrZZLTwNxJ/4LZc nhdMrLPXZ77t/o/u2bYpm/PcDSIprYZkrvx1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vs+DRlaNDR7CAlUr2WGMwxdWOU5UsJpsEnyUS5ReFvsGPuJgQjmHdYVKm8w88HfbbB aAJmCx6FKlwC79nFv45EXY8Lv/yG3abn5o6+3KHxxEiDQHSTWGyul/gN14Nr5BvDbtdU OPkB4AbukK2Ch2j654nm1U4HE4LK8nHNbajAE= MIME-Version: 1.0 Received: by 10.42.115.73 with SMTP id j9mr535524icq.117.1302051620158; Tue, 05 Apr 2011 18:00:20 -0700 (PDT) Received: by 10.42.76.71 with HTTP; Tue, 5 Apr 2011 18:00:20 -0700 (PDT) In-Reply-To: <201104052137.p35LbquQ061587@harbor.orleans.occnc.com> References: <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> <201104052137.p35LbquQ061587@harbor.orleans.occnc.com> Date: Tue, 5 Apr 2011 21:00:20 -0400 Message-ID: Subject: Re: fn-transport/ipfrr drafts From: Alia Atlas To: curtis@occnc.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.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:58:40 -0000 Curtis, Andras is familiar with the problem IPFRR is trying to solve. As I understand it, there are 3 separate questions: a) Is a multicast distribution mechanism that can report bad news quickly & survive single failures useful? b) Is this useful for an IGP to speed network convergence? c) If one assumes very rapid ( speed of light) delays for remote failures, what pre-computation and FIB installation could be possible? I have not heard requirements and rationale sufficient yet. Security is also a concern - but the first questions are whether any mechanism is desirable. Alia 2011/4/5 Curtis Villamizar : > > In message <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea= .ericsson.se> > Andr=E1s Cs=E1sz=E1r writes: >> >> Dear All, >> >> Note that fn-transport already is at version 01. Links to the docs: >> >> http://tools.ietf.org/html/draft-lu-fn-transport-01 >> http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00 >> >> We'd really appreciate comments and suggestions. >> >> Andr=E1s > > > Same comment as on the OSPF mailing list. =A0This is attacking a > non-problem. > > Flooding time is not a problem on modern implementations, unless the > implementation is badly designed or badly coded. > > IPFRR is intended to eliminate the need for an SPF and route > download and the need to contact any other router in any way to get an > initial repair done. =A0That is a different problem. > > Curtis > > >> > -----Original Message----- >> > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] >> > On Behalf Of Jeff Tantsura >> > Sent: 2011. m=E1rcius 29. 14:58 >> > To: rtgwg@ietf.org >> > Subject: fn-transport/ipfrr drafts >> > >> > Hi rtgwg, >> > >> > The authors would like to solicit comments from the workgroup. >> > >> > draft-lu-fn-transport-00 >> > draft-csaszar-ipfrr-fn-00 >> > >> > Thank you in advance! >> > >> > Regards, >> > Jeff > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > From mshand@cisco.com Wed Apr 6 02:23:33 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9EFB3A68F9 for ; Wed, 6 Apr 2011 02:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SpU7-w8XC-u for ; Wed, 6 Apr 2011 02:23:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7F2153A68E6 for ; Wed, 6 Apr 2011 02:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mshand@cisco.com; l=2557; q=dns/txt; s=iport; t=1302081916; x=1303291516; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=G3ao7pEAa8TQdP+CobZezzuJzMIgZ01QUGkXheGMXhk=; b=RhgRmJAOw+kfS64HtuJ9W0pG5rGh/y8WUv/GwCA8CXe1/6w8DmgqoI0G 49wcWwhdItOal6009YGQ4QQ4dTNyj61yygZEWoJIvyBAhr3Kf8m1sgbNi Z2iIUJH0ExXSJ1/IzHIKTfWjTGGGFluaBbAtwOvky0jJV0jLuEW37+WNl w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAEExnE2Q/khLgWdsb2JhbACYbI0LFAEBFiYlpSucFIVsBI06g2I X-IronPort-AV: E=Sophos;i="4.63,309,1299456000"; d="scan'208";a="82387043" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 06 Apr 2011 09:25:15 +0000 Received: from [10.61.88.192] (ams3-vpn-dhcp6337.cisco.com [10.61.88.192]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p369PENE017871 for ; Wed, 6 Apr 2011 09:25:14 GMT Message-ID: <4D9C317A.7090804@cisco.com> Date: Wed, 06 Apr 2011 10:25:14 +0100 From: mike shand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: fn-transport/ipfrr drafts References: <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> <201104052137.p35LbquQ061587@harbor.orleans.occnc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 09:23:33 -0000 Alia, My quick replies would be a) possibly, but I'm not sure of the application. Certainly not (b). b) I don't think so c) I'd be very concerned about the scaling issues of doing that Mike On 06/04/2011 02:00, Alia Atlas wrote: > Curtis, > > Andras is familiar with the problem IPFRR is trying to solve. > > As I understand it, there are 3 separate questions: > a) Is a multicast distribution mechanism that can report bad news > quickly& survive single failures useful? > b) Is this useful for an IGP to speed network convergence? > c) If one assumes very rapid ( speed of light) delays for remote > failures, what pre-computation and FIB installation could be possible? > > I have not heard requirements and rationale sufficient yet. > Security is also a concern - but the first questions are whether any > mechanism is desirable. > > Alia > > 2011/4/5 Curtis Villamizar: >> In message<8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> >> András Császár writes: >>> Dear All, >>> >>> Note that fn-transport already is at version 01. Links to the docs: >>> >>> http://tools.ietf.org/html/draft-lu-fn-transport-01 >>> http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00 >>> >>> We'd really appreciate comments and suggestions. >>> >>> András >> >> Same comment as on the OSPF mailing list. This is attacking a >> non-problem. >> >> Flooding time is not a problem on modern implementations, unless the >> implementation is badly designed or badly coded. >> >> IPFRR is intended to eliminate the need for an SPF and route >> download and the need to contact any other router in any way to get an >> initial repair done. That is a different problem. >> >> Curtis >> >> >>>> -----Original Message----- >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] >>>> On Behalf Of Jeff Tantsura >>>> Sent: 2011. március 29. 14:58 >>>> To: rtgwg@ietf.org >>>> Subject: fn-transport/ipfrr drafts >>>> >>>> Hi rtgwg, >>>> >>>> The authors would like to solicit comments from the workgroup. >>>> >>>> draft-lu-fn-transport-00 >>>> draft-csaszar-ipfrr-fn-00 >>>> >>>> Thank you in advance! >>>> >>>> Regards, >>>> Jeff >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> >> > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From Andras.Csaszar@ericsson.com Wed Apr 6 04:57:36 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6499F3A691F for ; Wed, 6 Apr 2011 04:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.836 X-Spam-Level: X-Spam-Status: No, score=-5.836 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ9wPMsndPUw for ; Wed, 6 Apr 2011 04:57:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1C7E13A690F for ; Wed, 6 Apr 2011 04:57:34 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-bb-4d9c55964a0f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F1.38.09202.6955C9D4; Wed, 6 Apr 2011 13:59:18 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.133]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 6 Apr 2011 13:59:17 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: "rtgwg@ietf.org" , "curtis@occnc.com" Date: Wed, 6 Apr 2011 13:59:16 +0200 Subject: RE: fn-transport/ipfrr drafts Thread-Topic: fn-transport/ipfrr drafts Thread-Index: Acvz2bnZHLIlUVCBSPOoMR06Gol9WAAamheA Message-ID: <8DCD771BDA4A394E9BCBA8932E83929720E74E4798@ESESSCMS0363.eemea.ericsson.se> References: Your message of "Tue, 05 Apr 2011 15:12:29 +0200." <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> <201104052137.p35LbquQ061587@harbor.orleans.occnc.com> In-Reply-To: <201104052137.p35LbquQ061587@harbor.orleans.occnc.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 11:57:36 -0000 > > http://tools.ietf.org/html/draft-lu-fn-transport-01 > > http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00 > > =20 > > We'd really appreciate comments and suggestions.=20 > > =20 > > Andr=E1s >=20 >=20 > Same comment as on the OSPF mailing list. This is attacking a > non-problem. >=20 > Flooding time is not a problem on modern implementations, unless the > implementation is badly designed or badly coded. >=20 > IPFRR is intended to eliminate the need for an SPF and route > download and the need to contact any other router in any way to get an > initial repair done. That is a different problem. LFA does not need contact with other routers, but it cannot provide full co= verage. We explore the possibility of lifting the existing IPFRR constraint that ex= plicit notification is not allowed. So, instead of saying that explicit notification is not allowed, we think t= hat a fast and lightweight dataplane based notification dissemination proto= col could be a way ahead towards full FRR failure coverage. The questions is then: Can this explicit notification be made quick and sim= ple enough to be feasible? Our answer is yes, this is FN, described in draf= t-lu-fn-transport-01 IPFRR-FN is then the following: Assuming that there exists a fast notificat= ion protocol that can notify each node in the area about any single failure= , could we then let the IGP to pre-calculate and pre-install failure specif= ic backup routes? We think yes. It is clear, though, that we should get back with (more) numbers on practic= al feasibility: - What is amount of information needed to prepare backup routes for differe= nt local and non-local failures? - How does this pre-calculation stress the CP? - How does the CP-to-DP pre-downloading of this backup information stress a= node? - How fast can a linecard in practice change the information in its FIB usi= ng this local backup database? BR, Andr=E1s= From Andras.Csaszar@ericsson.com Wed Apr 6 05:19:06 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2FD3A6921 for ; Wed, 6 Apr 2011 05:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klga8dQwJiVZ for ; Wed, 6 Apr 2011 05:19:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6DF2D3A68BC for ; Wed, 6 Apr 2011 05:19:04 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-31-4d9c5a9fffb1 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1B.4B.09202.F9A5C9D4; Wed, 6 Apr 2011 14:20:47 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.133]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 6 Apr 2011 14:20:46 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: "rtgwg@ietf.org" Date: Wed, 6 Apr 2011 14:20:45 +0200 Subject: RE: fn-transport/ipfrr drafts Thread-Topic: fn-transport/ipfrr drafts Thread-Index: Acv0PIz7Py27y5BDSPSzVqLWgNx/EgAFbcBA Message-ID: <8DCD771BDA4A394E9BCBA8932E83929720E74E47B1@ESESSCMS0363.eemea.ericsson.se> References: <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> <201104052137.p35LbquQ061587@harbor.orleans.occnc.com> <4D9C317A.7090804@cisco.com> In-Reply-To: <4D9C317A.7090804@cisco.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:19:06 -0000 Hi, Probably you are more interested in the opinion of the rest of the communit= y, but anyway: a) yes, especially for those applications that target quick changing of act= ive dataplane routes to alternative routes when something happens in the ne= twork (as for now this could be FRR, where event=3Dfailure). It could be al= so very useful in split DP-CP environments (such as FORCES and OpenFlow), w= here event specific alternative routes could be activated by forwarding ele= ments without consulting the CP. b) I'm not an author of the ospf-fn draft but in my opinion it could be use= ful in those cases when regular OSPF flooding is a noticable part of the ov= erall convergence. This may be the case with modern routers where the exist= ing convergence bottlenecks are greatly reduced (SPF calc is not long anymo= re, RIB-to-FIB download bottleneck is getting optimised by incremental upda= tes and a few updates causing many route updates in the FIB) c) We should come back definitely with more numbers on (copy/pasting from t= he email I just sent responding to Curtis): - What is amount of information needed to prepare backup routes for differe= nt local and non-local failures? - How does this pre-calculation stress the CP? - How does the CP-to-DP pre-downloading of this backup information stress a= node? - How fast can a linecard in practice change the information in its FIB usi= ng this local backup database? Some initial estimations you can find in the Appendix of the ipfrr-fn draft= . An important note: You don't have to download alternative routes for each f= ailure for each destination! Only those that matter: 1. Failure is on shortest path towards the destination 2. Failure results in route change This is much less. Will come back with more numbers. Kind regards, Andr=E1s > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20 > On Behalf Of mike shand > Sent: 2011. =E1prilis 6. 11:25 > To: rtgwg@ietf.org > Subject: Re: fn-transport/ipfrr drafts >=20 > Alia, >=20 > My quick replies would be >=20 > a) possibly, but I'm not sure of the application. Certainly not (b). > b) I don't think so > c) I'd be very concerned about the scaling issues of doing that >=20 > Mike >=20 >=20 > On 06/04/2011 02:00, Alia Atlas wrote: > > Curtis, > > > > Andras is familiar with the problem IPFRR is trying to solve. > > > > As I understand it, there are 3 separate questions: > > a) Is a multicast distribution mechanism that can=20 > report bad news > > quickly& survive single failures useful? > > b) Is this useful for an IGP to speed network convergence? > > c) If one assumes very rapid ( speed of light) delays=20 > for remote > > failures, what pre-computation and FIB installation could=20 > be possible? > > > > I have not heard requirements and rationale sufficient yet. > > Security is also a concern - but the first questions are whether any > > mechanism is desirable. > > > > Alia > > > > 2011/4/5 Curtis Villamizar: > >> In=20 > message<8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS036 > 3.eemea.ericsson.se> > >> Andr=E1s Cs=E1sz=E1r writes: > >>> Dear All, > >>> > >>> Note that fn-transport already is at version 01. Links to=20 > the docs: > >>> > >>> http://tools.ietf.org/html/draft-lu-fn-transport-01 > >>> http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00 > >>> > >>> We'd really appreciate comments and suggestions. > >>> > >>> Andr=E1s > >> > >> Same comment as on the OSPF mailing list. This is attacking a > >> non-problem. > >> > >> Flooding time is not a problem on modern implementations,=20 > unless the > >> implementation is badly designed or badly coded. > >> > >> IPFRR is intended to eliminate the need for an SPF and route > >> download and the need to contact any other router in any=20 > way to get an > >> initial repair done. That is a different problem. > >> > >> Curtis > >> > >> > >>>> -----Original Message----- > >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] > >>>> On Behalf Of Jeff Tantsura > >>>> Sent: 2011. m=E1rcius 29. 14:58 > >>>> To: rtgwg@ietf.org > >>>> Subject: fn-transport/ipfrr drafts > >>>> > >>>> Hi rtgwg, > >>>> > >>>> The authors would like to solicit comments from the workgroup. > >>>> > >>>> draft-lu-fn-transport-00 > >>>> draft-csaszar-ipfrr-fn-00 > >>>> > >>>> Thank you in advance! > >>>> > >>>> Regards, > >>>> Jeff > >> _______________________________________________ > >> rtgwg mailing list > >> rtgwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtgwg > >> > >> > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > = From ppsenak@cisco.com Wed Apr 6 05:41:03 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68013A692E for ; Wed, 6 Apr 2011 05:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEXldxB5CXYm for ; Wed, 6 Apr 2011 05:41:03 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 13C4F3A692C for ; Wed, 6 Apr 2011 05:41:02 -0700 (PDT) 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 p36CZF2J002506; Wed, 6 Apr 2011 14:35:15 +0200 (CEST) Received: from ams3-vpn-dhcp5790.cisco.com (ams3-vpn-dhcp5790.cisco.com [10.61.86.157]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p36CZF64029050; Wed, 6 Apr 2011 14:35:15 +0200 (CEST) Message-ID: <4D9C5E03.3000708@cisco.com> Date: Wed, 06 Apr 2011 14:35:15 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= Subject: Re: fn-transport/ipfrr drafts References: <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> <201104052137.p35LbquQ061587@harbor.orleans.occnc.com> <4D9C317A.7090804@cisco.com> <8DCD771BDA4A394E9BCBA8932E83929720E74E47B1@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <8DCD771BDA4A394E9BCBA8932E83929720E74E47B1@ESESSCMS0363.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:41:03 -0000 András, > An important note: You don't have to download alternative routes for each failure for each destination! Only those that matter: > 1. Failure is on shortest path towards the destination > 2. Failure results in route change the amount of computation and LC storage to cover for all 'interesting' failures and all impacted destinations would likely be still significant. Which is in contrast to a limited gain you get for it, compared to 'traditional' LFA. thanks, Peter From stbryant@cisco.com Wed Apr 6 06:14:56 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7607328C0EA for ; Wed, 6 Apr 2011 06:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-e4iZQWpDbI for ; Wed, 6 Apr 2011 06:14:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6ECD428C162 for ; Wed, 6 Apr 2011 06:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=159; q=dns/txt; s=iport; t=1302095752; x=1303305352; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=VlVOudYg6rQBi7S1nFG+graw0G/4PqwLpm1niOezkB0=; b=QBzjZLBmTMsBw4+VHDKDaoQQurNZ0JYAoxnstPAoCNz+HSJPz8/TKvp2 Vq0qN6GdVIlcJygZElc/k2+JcB5ne5gKyGiiVrotdP/pGGwtQIUNOwgom azxSES2GAWLOtmJYcv5PMJyPBbJSYr9vyRodyqbocMmoLCP3vKUXEUeNO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcHAMBmnE2Q/khNgWdsb2JhbACYa40MFAEBFiYlpRuCcw4BmSuFbASNPA X-IronPort-AV: E=Sophos;i="4.63,310,1299456000"; d="scan'208";a="24660524" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2011 13:15:51 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p36DFpKN012674 for ; Wed, 6 Apr 2011 13:15:51 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p36DFmU03531; Wed, 6 Apr 2011 14:15:49 +0100 (BST) Message-ID: <4D9C6784.2070307@cisco.com> Date: Wed, 06 Apr 2011 14:15:48 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: fn-transport/ipfrr drafts References: <0ED867EB33AB2B45AAB470D5A64CDBF60CAB204D66@EUSAACMS0701.eamcs.ericsson.se> <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 13:14:56 -0000 Andras To make sure that we are not talking at cross purposes, can you let us know what size of network that you anticipate applying this to? Stewart From jdrake@juniper.net Wed Apr 6 08:02:51 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15FBE28C11A for ; Wed, 6 Apr 2011 08:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9YscQ6E40eG for ; Wed, 6 Apr 2011 08:02:50 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 95BF03A69BB for ; Wed, 6 Apr 2011 08:02:49 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTZyA/V6CCKp/7o/mQFMFuEbe+Fq21t6V@postini.com; Wed, 06 Apr 2011 08:04:33 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 6 Apr 2011 08:01:25 -0700 From: John E Drake To: Alia Atlas , "curtis@occnc.com" Date: Wed, 6 Apr 2011 08:03:06 -0700 Subject: RE: fn-transport/ipfrr drafts Thread-Topic: fn-transport/ipfrr drafts Thread-Index: Acvz9cvSpu5eRwsIRUOsfuH8WNMJywAdEQjg Message-ID: <5E893DB832F57341992548CDBB33316399F2CA7904@EMBX01-HQ.jnpr.net> References: <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> <201104052137.p35LbquQ061587@harbor.orleans.occnc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:02:51 -0000 Comments inline Sent from my iPhone > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Alia Atlas > Sent: Tuesday, April 05, 2011 6:00 PM > To: curtis@occnc.com > Cc: rtgwg@ietf.org > Subject: Re: fn-transport/ipfrr drafts >=20 > Curtis, >=20 > Andras is familiar with the problem IPFRR is trying to solve. >=20 > As I understand it, there are 3 separate questions: > a) Is a multicast distribution mechanism that can report bad news > quickly & survive single failures useful? JD: Is IGP flooding a significant contributor to network convergence and i= s a multicast distribution mechanism sufficiently faster to justify the con= trol plane complexity associated with building and maintaining a multicast = tree? Data plane support of multicast, even in hardware, involves packet r= eplication and is seldom line-rate. The drafts' treatment of building and = maintaining a multicast tree in a dynamic network is akin to 'magic happens= '. > b) Is this useful for an IGP to speed network convergence? JD: See above. When we actually did this, nearly twenty years ago, it pro= ved to be of dubious benefit. > c) If one assumes very rapid ( speed of light) delays for remote > failures, what pre-computation and FIB installation could be possible? JD: This is implementation specific and should be outside the scope of the= discussion. >=20 > I have not heard requirements and rationale sufficient yet. > Security is also a concern - but the first questions are whether any > mechanism is desirable. JD: You can probably guess what I think. >=20 > Alia >=20 > 2011/4/5 Curtis Villamizar : > > > > In message > <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson > .se> > > Andr=E1s Cs=E1sz=E1r writes: > >> > >> Dear All, > >> > >> Note that fn-transport already is at version 01. Links to the docs: > >> > >> http://tools.ietf.org/html/draft-lu-fn-transport-01 > >> http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00 > >> > >> We'd really appreciate comments and suggestions. > >> > >> Andr=E1s > > > > > > Same comment as on the OSPF mailing list. =A0This is attacking a > > non-problem. > > > > Flooding time is not a problem on modern implementations, unless the > > implementation is badly designed or badly coded. > > > > IPFRR is intended to eliminate the need for an SPF and route > > download and the need to contact any other router in any way to get > an > > initial repair done. =A0That is a different problem. > > > > Curtis > > > > > >> > -----Original Message----- > >> > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] > >> > On Behalf Of Jeff Tantsura > >> > Sent: 2011. m=E1rcius 29. 14:58 > >> > To: rtgwg@ietf.org > >> > Subject: fn-transport/ipfrr drafts > >> > > >> > Hi rtgwg, > >> > > >> > The authors would like to solicit comments from the workgroup. > >> > > >> > draft-lu-fn-transport-00 > >> > draft-csaszar-ipfrr-fn-00 > >> > > >> > Thank you in advance! > >> > > >> > Regards, > >> > Jeff > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From Andras.Csaszar@ericsson.com Wed Apr 6 08:55:22 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E333A68EC for ; Wed, 6 Apr 2011 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJh-8ZOCG0ND for ; Wed, 6 Apr 2011 08:55:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3972B3A6874 for ; Wed, 6 Apr 2011 08:55:21 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-a3-4d9c8d50d8f6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 94.88.09202.05D8C9D4; Wed, 6 Apr 2011 17:57:04 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.133]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 6 Apr 2011 17:57:04 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: "stbryant@cisco.com" , "rtgwg@ietf.org" Date: Wed, 6 Apr 2011 17:57:02 +0200 Subject: RE: fn-transport/ipfrr drafts Thread-Topic: fn-transport/ipfrr drafts Thread-Index: Acv0XN90FuQoYpW5QGeB4T6zks8mbQAEpUqg Message-ID: <8DCD771BDA4A394E9BCBA8932E83929720E74E496C@ESESSCMS0363.eemea.ericsson.se> References: <0ED867EB33AB2B45AAB470D5A64CDBF60CAB204D66@EUSAACMS0701.eamcs.ericsson.se> <8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS0363.eemea.ericsson.se> <4D9C6784.2070307@cisco.com> In-Reply-To: <4D9C6784.2070307@cisco.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:55:22 -0000 Hi, In the appendix (http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00#appen= dix-A) we started to make some preliminary estimations on how much informat= ion is need to maintain failure specific backups for areas with 200 & 500 n= odes with 500k routes. They were, we think, pretty worst case estimations. We will check for 1000 node area size, too. And we got a suggestion not to = overestimate the network diameter, which will result in much smaller number= s. But it is clear that we need to answer more questions then just the backup = database size. Further questions I mentioned in my previous emails. BR, Andr=E1s > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20 > On Behalf Of Stewart Bryant > Sent: 2011. =E1prilis 6. 15:16 > To: rtgwg@ietf.org > Subject: Re: fn-transport/ipfrr drafts >=20 > Andras >=20 > To make sure that we are not talking at cross purposes, can=20 > you let us=20 > know what size of network that you anticipate applying this to? >=20 > Stewart > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > = From lucy.yong@huawei.com Wed Apr 6 22:48:24 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDFE3A69FB for ; Wed, 6 Apr 2011 22:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mdb2t6QNtKj for ; Wed, 6 Apr 2011 22:48:20 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id D372C28C105 for ; Wed, 6 Apr 2011 22:48:10 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ900D9GPG880@usaga04-in.huawei.com> for rtgwg@ietf.org; Thu, 07 Apr 2011 00:48:09 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LJ900L0OPG6SQ@usaga04-in.huawei.com> for rtgwg@ietf.org; Thu, 07 Apr 2011 00:48:08 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 06 Apr 2011 22:48:01 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.75]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 06 Apr 2011 22:48:06 -0700 Date: Thu, 07 Apr 2011 05:48:06 +0000 From: Lucy yong Subject: RE: draft-so-yong-rtgwg-cl-framework-03 comments In-reply-to: <201104052124.p35LO0ib061406@harbor.orleans.occnc.com> X-Originating-IP: [10.216.44.84] To: "curtis@occnc.com" , "So, Ning" , "McDysan, David E (Dave)" , "Malis, Andrew G (Andy)" , "eosborne@cisco.com" , Tony Li Message-id: <2691CE0099834E4A9C5044EEC662BB9D0495F09C@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: draft-so-yong-rtgwg-cl-framework-03 comments Thread-index: AQHL89fnTfdFuPTaIEG6I5lTbSinbpRR0PAg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <201104052124.p35LO0ib061406@harbor.orleans.occnc.com> Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 05:48:24 -0000 Hi Curtis and All, Thanks the review and comments. Here are my opinions. Please see inline. > > Here are some comments on draft-so-yong-rtgwg-cl-framework-03. > > BTW- We should take this discussion to the WG list so that it is > archived. The author list with a few people added covered most people > that had been active on the list anyway. [LY] Agree in general. We may need to sync up among co-authors regarding the next steps. We have worked on the subject for long and really want to move on to the protocol extension work now. > > These are comments on "what is there". I will have to comment later > on "what is not there". A lot is missing that should be there if this > were to be a reasonably complete framework document. [LY] I am glad that you are one of co-authors who can fill in those missing. > > 1. In a few places the following is specified: "If two unidirectional > LSPs are used to construct a component link, they MUST be > co-routed." > > LSP may be unidirectional, associated bidirectional, or corouted > bidirectional. There is no such thing as a "corouted > unidirectional pair" since a make-before-break reroute, or any > reroute is done on each LSP independently of the other. > > Maybe this could be put in one place and replaced with SHOULD > since MUST is impossible during reroute. A corouted bidirectional > LSP will fail on a make-before-break reroute if one direction > can't come up so it always remains either corouted or down. [LY] Good point. Maybe it is good to only allow a corouted bidirectional LSP as a component link. In my understanding, the term of corouted bidirectional LSP is only in the context of MPLS-TP. In RSVP-TE signaling, is there an indication for associated bidirectional or corouted bidirectional in PATH message? Does a LSP tunnel mean a corouted bidirectional LSP? > > 2. The requiement to make all CL LSP corouted is a new requiement. > Requirments belong in draft-ietf-rtgwg-cl-requirement, so if we've > missed some we SHOULD tell the IESG that we need to respin > cl-requirement already. Otherwise we should drop this from the > framework. No reason is given to require corouted. [LY] A bit clarify on this. Only the LSP that is used as a component link in a composite link needs to be corouted. A LSP over a composite link can be unidirectional, associated bidirectional, or co-routed bidirectional. [LY] I prefer not to respin the cl-requirement. But if majority of co-authors want doing that, I go with. We can state some reason in the framework draft. Basically, the links in IGP are bidirectional. Since a physical link is always corouted bidirectional, it is reasonable to keep this characteristics in a component link that is formed by a LSP. Thus we don't have to differ a physical component link from a LSP based component link. Like to hear operator opinion on this. > > 3. The framework states that "Both LDP [RFC5036] and RSVP-TE > [RFC3209] can be used to signal a LSP over a composite link. The > router of composite link ingress MUST place the LSP on the > component link that meets the LSP criteria indicated in the signal > message." > > This is a framework so we have to say *how* LDP and RSVP-TE will > be used to signal a LSP over a composite link. We should not > define the protocol bits, just describe what information needs to > be exchanged in order for this to happen. > > We can cite the existing LDP requirements in cl-requirements. The > framework needs to take the next step and indicate what is > necessary to meet these requirements (DR#1, DR#2, and DR#3). [LY] Good point. We need to describe these ways. Could you take this action? > > 4. In section 5, "The process MUST support locally and gracefully > traffic movement process among component links. The protocol that > facilitates this process between two composite link end points is > for further study." > > Again, this is a requiement and the draft is a framework draft. It > is already covered in FR#12 in cl-requirements. [LY] Agree. We have some description before, and we were asked to remove it. People think that this is local functions and should not be standardized. However, two end point of composite link may need some sync-up function to facilitate each end local restoration process. The protocol extension may help this task. One example we give is to locally restore a corouted bidirectional LSP on the same component link. [LY] Let's revise the text to reference the requirement draft and make some acceptable text. > > 5. Section 6, "Composite Link in Management Plane" contains nothing > but new requirements. Every sentence but one has the word MUST in > it. > > Management Plane MUST keep tracking a composite link and its > individual composite link status and configuration. > > Management Plane MUST be able to make any component link in a > composite link active and de-activate in order to facilitate > operation maintenance task. > > The routers of a composite link resides MUST perform the > redistribution of the traffic flows on a de-activated link to > other component links based on the traffic flow TE criteria. > > Management Plane MUST be able to configure a LSP over a > composite link and be able to select a component link for the > LSP. > > Management Plane MUST be able to trace which component link a > LSP is assigned to and monitor individual component link and > composite link performance. > > Management Plane MUST be able to ping individual component link > within a composite link. > > Management Plane should build the proper commands to allow > operator execute an optimization process. > > The last sentence has "should" in lower case. It is not clear > what this last sentence means. > > Note that if we have missed a whole block of requirements, then we > should pull draft-ietf-rtgwg-cl-requirement out of IESG (if it got > that far) or out of AD review and give it another spin, adding the > requirements that were missed. [LY] Yes, we don't have management plane requirement in the requirement draft since we split the original draft into the requirement and framework. But, as usual, operator can't use it without management plane functions. It is better for us to have it somewhere. [LY] Again, I prefer not to respin the requirement draft if we can work around here. But if other co-author want to respin, I go with. [LY] We can revise the text to make them not like the requirement. What operation can be done over a composite link. [LY] Regarding the uploading issue. I uploaded CL framework v03 on Feb 22 in silence mode and it was shown on IETF draft announcement on the date of Feb. 23. I did not make an explicit announcement to the RTG group about this update. I'll do it in the future. [LY] I am still in Europe for other business trip this week and next week and have limited time to response this thread. [LY] Thank you, Curtis, very much to work on this quickly. Regards, Lucy > > Curtis From curtis@occnc.com Thu Apr 7 19:14:22 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AEB93A69A0 for ; Thu, 7 Apr 2011 19:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPXnz6dwYhKj for ; Thu, 7 Apr 2011 19:14:21 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id E1D033A6828 for ; Thu, 7 Apr 2011 19:14:20 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p382FRu9099760; Thu, 7 Apr 2011 22:15:28 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104080215.p382FRu9099760@harbor.orleans.occnc.com> To: Lucy yong From: Curtis Villamizar Subject: Re: draft-so-yong-rtgwg-cl-framework-03 comments In-reply-to: Your message of "Thu, 07 Apr 2011 05:48:06 -0000." <2691CE0099834E4A9C5044EEC662BB9D0495F09C@dfweml503-mbx.china.huawei.com> Date: Thu, 07 Apr 2011 22:15:27 -0400 Sender: curtis@occnc.com Cc: "eosborne@cisco.com" , "Malis, Andrew G \(Andy\)" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 02:14:22 -0000 In message <2691CE0099834E4A9C5044EEC662BB9D0495F09C@dfweml503-mbx.china.huawei.com> Lucy yong writes: > > Hi Curtis and All, > > Thanks the review and comments. Here are my opinions. Please see inline. > > > > > Here are some comments on draft-so-yong-rtgwg-cl-framework-03. > > > > BTW- We should take this discussion to the WG list so that it is > > archived. The author list with a few people added covered most people > > that had been active on the list anyway. > > [LY] Agree in general. We may need to sync up among co-authors > regarding the next steps. We have worked on the subject for long and > really want to move on to the protocol extension work now. > > > These are comments on "what is there". I will have to comment later > > on "what is not there". A lot is missing that should be there if this > > were to be a reasonably complete framework document. > > [LY] I am glad that you are one of co-authors who can fill in those missing. > > > 1. In a few places the following is specified: "If two unidirectional > > LSPs are used to construct a component link, they MUST be > > co-routed." > > > > LSP may be unidirectional, associated bidirectional, or corouted > > bidirectional. There is no such thing as a "corouted > > unidirectional pair" since a make-before-break reroute, or any > > reroute is done on each LSP independently of the other. > > > > Maybe this could be put in one place and replaced with SHOULD > > since MUST is impossible during reroute. A corouted bidirectional > > LSP will fail on a make-before-break reroute if one direction > > can't come up so it always remains either corouted or down. > > [LY] Good point. Maybe it is good to only allow a corouted > bidirectional LSP as a component link. In my understanding, the term > of corouted bidirectional LSP is only in the context of MPLS-TP. In > RSVP-TE signaling, is there an indication for associated bidirectional > or corouted bidirectional in PATH message? Does a LSP tunnel mean a > corouted bidirectional LSP? I suggest that we indicate that unidirectional and associated bidirectional MAY be supported and corouted bidirectional MUST be supported. > > 2. The requiement to make all CL LSP corouted is a new requiement. > > Requirments belong in draft-ietf-rtgwg-cl-requirement, so if we've > > missed some we SHOULD tell the IESG that we need to respin > > cl-requirement already. Otherwise we should drop this from the > > framework. No reason is given to require corouted. > > [LY] A bit clarify on this. Only the LSP that is used as a component > link in a composite link needs to be corouted. A LSP over a composite > link can be unidirectional, associated bidirectional, or co-routed > bidirectional. OK. That wasn't clear to me. I'm not sure why the component link MUST be corouted. > [LY] I prefer not to respin the cl-requirement. But if majority of > co-authors want doing that, I go with. We can state some reason in the > framework draft. Basically, the links in IGP are bidirectional. Since > a physical link is always corouted bidirectional, it is reasonable to > keep this characteristics in a component link that is formed by a LSP. > Thus we don't have to differ a physical component link from a LSP > based component link. Like to hear operator opinion on this. While it may seem "nice" that the component link is corouted, I don't think it is strictly necessary. I like the MUST implement for corouted and the MAY implement for others. That way providers are free to choose. > > 3. The framework states that "Both LDP [RFC5036] and RSVP-TE > > [RFC3209] can be used to signal a LSP over a composite link. The > > router of composite link ingress MUST place the LSP on the > > component link that meets the LSP criteria indicated in the signal > > message." > > > > This is a framework so we have to say *how* LDP and RSVP-TE will > > be used to signal a LSP over a composite link. We should not > > define the protocol bits, just describe what information needs to > > be exchanged in order for this to happen. > > > > We can cite the existing LDP requirements in cl-requirements. The > > framework needs to take the next step and indicate what is > > necessary to meet these requirements (DR#1, DR#2, and DR#3). > > [LY] Good point. We need to describe these ways. Could you take this > action? I just added this to my list of actions from IETF (where IETF is somewhere on the list of actions for work in general). For RTG CL I had two actions from the CL authors meeting. One was to produce a list of relevant RFCs and drafts. The second was to produce text saying why they are relevant. The first of those two actions is done (sent to authors only so far). I also promised to review the existing framework and that is this thread. So I now have two open action items including the one above. Just to be sure I'm clear on this: the new action item is to document how we could accomodate LDP. Briefly what had been discussed in the past was to measure LDP traffic and make use of some filtered value based on the measurement as if it were a RSVP-TE reservation. This requires no change to LDP. An alternate would be to have edges measure and have a sum accumulated along the MP2P LDP tree, but that would require an enhancement to LDP signaling. If that is OK (the direct measurement, with no signaling change), I can write that up and indicate that no TE (ie: CRLDP) will be done on LDP traffic under the assumption that any high priority LDP traffic runs over overprovisioned capacity and if there is any overprovision LDP traffic it is BE. I'll write a blurb on this if we agree this is the overall approach (Dave, Ning, Andy, others - opinions?). > > 4. In section 5, "The process MUST support locally and gracefully > > traffic movement process among component links. The protocol that > > facilitates this process between two composite link end points is > > for further study." > > > > Again, this is a requiement and the draft is a framework draft. It > > is already covered in FR#12 in cl-requirements. > > [LY] Agree. We have some description before, and we were asked to > remove it. People think that this is local functions and should not be > standardized. However, two end point of composite link may need some > sync-up function to facilitate each end local restoration process. The > protocol extension may help this task. One example we give is to > locally restore a corouted bidirectional LSP on the same component > link. > > [LY] Let's revise the text to reference the requirement draft and make > some acceptable text. If we need a protocol, then "for further study" is unacceptable. If we don't need a protocol to accomplish this then it can be a local function. If it is a local function it could also be documented but not mandated, allowing other techniques but providing a reference technique. > > 5. Section 6, "Composite Link in Management Plane" contains nothing > > but new requirements. Every sentence but one has the word MUST in > > it. > > > > Management Plane MUST keep tracking a composite link and its > > individual composite link status and configuration. > > > > Management Plane MUST be able to make any component link in a > > composite link active and de-activate in order to facilitate > > operation maintenance task. > > > > The routers of a composite link resides MUST perform the > > redistribution of the traffic flows on a de-activated link to > > other component links based on the traffic flow TE criteria. > > > > Management Plane MUST be able to configure a LSP over a > > composite link and be able to select a component link for the > > LSP. > > > > Management Plane MUST be able to trace which component link a > > LSP is assigned to and monitor individual component link and > > composite link performance. > > > > Management Plane MUST be able to ping individual component link > > within a composite link. > > > > Management Plane should build the proper commands to allow > > operator execute an optimization process. > > > > The last sentence has "should" in lower case. It is not clear > > what this last sentence means. > > > > Note that if we have missed a whole block of requirements, then we > > should pull draft-ietf-rtgwg-cl-requirement out of IESG (if it got > > that far) or out of AD review and give it another spin, adding the > > requirements that were missed. > > [LY] Yes, we don't have management plane requirement in the > requirement draft since we split the original draft into the > requirement and framework. But, as usual, operator can't use it > without management plane functions. It is better for us to have it > somewhere. Maybe we could create a very small CL management requirements draft. That would allow the existing CL requirements to proceed. BTW - I'm not sure that management plane would want to ping anything. Management plane might want to initiate a ping which would then occur in the data plane. > [LY] Again, I prefer not to respin the requirement draft if we can > work around here. But if other co-author want to respin, I go with. This is up to the WG. Authors/editors don't have final say in a WG document. But then again if no one but authors replies, ... > [LY] We can revise the text to make them not like the > requirement. What operation can be done over a composite link. I don't follow what you are suggesting here. I don't think that a requirement with a lower case "must" makes it OK in a framework. > [LY] Regarding the uploading issue. I uploaded CL framework v03 on Feb > 22 in silence mode and it was shown on IETF draft announcement on the > date of Feb. 23. I did not make an explicit announcement to the RTG > group about this update. I'll do it in the future. OK. Thanks. I'm not sure why it was in some places (datatracker, 1id-abstracts) and not others (ftp site). This sounds like a tools problem. > [LY] I am still in Europe for other business trip this week and next > week and have limited time to response this thread. > > [LY] Thank you, Curtis, very much to work on this quickly. Same here. Limited time. Lots of things to keep me busy. > Regards, > Lucy > > > Curtis Regards, Curtis From curtis@occnc.com Thu Apr 7 19:46:17 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3E93A699C for ; Thu, 7 Apr 2011 19:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T++3NCuhdA5 for ; Thu, 7 Apr 2011 19:46:17 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id E83003A6881 for ; Thu, 7 Apr 2011 19:46:16 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p382lxtS000253; Thu, 7 Apr 2011 22:47:59 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104080247.p382lxtS000253@harbor.orleans.occnc.com> To: mike shand From: Curtis Villamizar Subject: Re: fn-transport/ipfrr drafts In-reply-to: Your message of "Wed, 06 Apr 2011 10:25:14 BST." <4D9C317A.7090804@cisco.com> Date: Thu, 07 Apr 2011 22:47:59 -0400 Sender: curtis@occnc.com Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 02:46:17 -0000 In message <4D9C317A.7090804@cisco.com> mike shand writes: > > Alia, > > My quick replies would be > > a) possibly, but I'm not sure of the application. Certainly not (b). > b) I don't think so > c) I'd be very concerned about the scaling issues of doing that > > Mike Agree. BTW - Wording nit: I assume Alia meant "very rapid (speed of light) propogation of the news of remote failures". The failures thenselves are already very fast, so no need to make them faster. :-) Curtis > On 06/04/2011 02:00, Alia Atlas wrote: > > Curtis, > > > > Andras is familiar with the problem IPFRR is trying to solve. > > > > As I understand it, there are 3 separate questions: > > a) Is a multicast distribution mechanism that can report bad news > > quickly& survive single failures useful? > > b) Is this useful for an IGP to speed network convergence? > > c) If one assumes very rapid ( speed of light) delays for remote > > failures, what pre-computation and FIB installation could be possible? > > > > I have not heard requirements and rationale sufficient yet. > > Security is also a concern - but the first questions are whether any > > mechanism is desirable. > > > > Alia From curtis@occnc.com Thu Apr 7 19:51:43 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFC93A69CF for ; Thu, 7 Apr 2011 19:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgTYNog-jCIC for ; Thu, 7 Apr 2011 19:51:41 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 9911F3A6835 for ; Thu, 7 Apr 2011 19:51:40 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p382rNFD000290; Thu, 7 Apr 2011 22:53:23 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104080253.p382rNFD000290@harbor.orleans.occnc.com> To: stbryant@cisco.com From: Curtis Villamizar Subject: Re: fn-transport/ipfrr drafts In-reply-to: Your message of "Wed, 06 Apr 2011 14:15:48 BST." <4D9C6784.2070307@cisco.com> Date: Thu, 07 Apr 2011 22:53:23 -0400 Sender: curtis@occnc.com Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 02:51:43 -0000 In message <4D9C6784.2070307@cisco.com> Stewart Bryant writes: > > Andras > > To make sure that we are not talking at cross purposes, can you let us > know what size of network that you anticipate applying this to? > > Stewart Stewart, Size in number of nodes and links or in delay diameter? Complexity or geography? I could see that datacenter (very small geography) and long haul provider network (large geography) might differ. Curtis From Internet-Drafts@ietf.org Wed Apr 20 08:15:03 2011 Return-Path: X-Original-To: rtgwg@ietfc.amsl.com Delivered-To: rtgwg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 957BDE06AD; Wed, 20 Apr 2011 08:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.75 X-Spam-Level: X-Spam-Status: No, score=-102.75 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJpOiLdILUig; Wed, 20 Apr 2011 08:15:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A5BB7E06B6; Wed, 20 Apr 2011 08:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-rtgwg-ordered-fib-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110420151502.26157.69324.idtracker@ietfc.amsl.com> Date: Wed, 20 Apr 2011 08:15:02 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 15:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : Loop-free convergence using oFIB Author(s) : M. Shand, et al. Filename : draft-ietf-rtgwg-ordered-fib-05.txt Pages : 23 Date : 2011-04-20 This document describes a mechanism for use in conjunction with link state routing protocols which prevents the transient loops which would otherwise occur during topology changes. It does this by correctly sequencing the FIB updates on the routers. This mechanism can be used in the case of non-urgent link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast re-route mechanism which converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described. The technology described in this document has been subject to extensive simulation using real network topologies and costs, and pathological convergence behaviour. A variant of the technology described here has been experimentally deployed in a production network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-ordered-fib-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-rtgwg-ordered-fib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-20080404.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Apr 20 10:30:04 2011 Return-Path: X-Original-To: rtgwg@ietfc.amsl.com Delivered-To: rtgwg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33E4CE0677; Wed, 20 Apr 2011 10:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.746 X-Spam-Level: X-Spam-Status: No, score=-102.746 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X75ppy8yE6cu; Wed, 20 Apr 2011 10:30:03 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 802BFE06A1; Wed, 20 Apr 2011 10:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-rtgwg-ipfrr-notvia-addresses-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110420173003.24537.65364.idtracker@ietfc.amsl.com> Date: Wed, 20 Apr 2011 10:30:03 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 17:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : IP Fast Reroute Using Not-via Addresses Author(s) : M. Shand, et al. Filename : draft-ietf-rtgwg-ipfrr-notvia-addresses-07.txt Pages : 28 Date : 2011-04-20 This draft describes a mechanism that provides fast reroute in an IP network through encapsulation to "not-via" addresses. A single level of encapsulation is used. The mechanism protects unicast, multicast and LDP traffic against link, router and shared risk group failure, regardless of network topology and metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-ipfrr-notvia-addresses-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-rtgwg-ipfrr-notvia-addresses-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-20102428.I-D@ietf.org> --NextPart--