From Andras.Csaszar@ericsson.com Fri Jun 1 00:33:56 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 2AD2821F8621 for ; Fri, 1 Jun 2012 00:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.949 X-Spam-Level: X-Spam-Status: No, score=-6.949 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGVR88diJ4Um for ; Fri, 1 Jun 2012 00:33:55 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAFD21F8620 for ; Fri, 1 Jun 2012 00:33:55 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-77-4fc87061df74 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A3.BA.11869.16078CF4; Fri, 1 Jun 2012 09:33:53 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.227]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 1 Jun 2012 09:33:54 +0200 From: =?utf-8?B?QW5kcsOhcyBDc8Ohc3rDoXI=?= To: "stbryant@cisco.com" Date: Fri, 1 Jun 2012 09:33:52 +0200 Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0/GTU1kgMbdMc8TMW32qinrmCu0gArdxSA Message-ID: <8DCD771BDA4A394E9BCBA8932E839297783CF64CF0@ESESSCMS0363.eemea.ericsson.se> References: <8DCD771BDA4A394E9BCBA8932E839297783CF647D0@ESESSCMS0363.eemea.ericsson.se> <31979_1338453231_4FC72CEF_31979_8499_3_4FC3556A36EE3646A09DAA60429F533508612770@PUEXCBL0.nanterre.francetelecom.fr> <4FC74998.70104@cisco.com> In-Reply-To: <4FC74998.70104@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvrW5iwQl/gx/vrS0+PbzEbHHhzW9m i3NP5zA6MHtM+b2R1WPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyug5+pK1oIuz4mDrP6YG xjccXYycHBICJhJHj/xig7DFJC7cWw9kc3EICZxilNh64jYzhLOAUeJ280JmkCo2AQ+J+9f/ gtkiAroSszfcYASxmQVcJX4tPsjexcjBwSKgIvHpQSBIWFjAU2L94eNsEOVeEsu2fIBqNZI4 8q6dCcTmFQiX+HemmQXEFhLYxCRxZkE9iM0poC7xa8VXVpCRjAKyEg/XWkBsEpe49WQ+E8TN AhJL9pxnhrBFJV4+/scKYjMKyEh8WHqIDaSVWUBTYv0ufYhWRYkp3Q/ZIbYKSpyc+YRlAqPY LCRTZyF0zELSMQtJxwJGllWMwrmJmTnp5UZ6qUWZycXF+Xl6xambGIGRdHDLb9UdjHfOiRxi lOZgURLntd66x19IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo43Wzpa57z4cdFwmNCfyxCKp jdc6/c8ZJQhM3qISetXx7h6z9FtSbe1nvuyesspgxzKtAn2nUo7VUs+W/F38aIJl75M3s9WW vOpiOF7ru3pCcMJZ44UNb6b6c1ar/2JQ2/azMz2nV6Zp5162gN74nZzGpXW8eZqSOwr/xuh/ VMpVsnn5aYv3YiWW4oxEQy3mouJEAFyIez1yAgAA Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 07:33:56 -0000 SGkgU3Rld2FydCwNCg0KPj4NCkkgdGhpbmsgdGhhdCB5b3Ugb21pdHRlZCB0byBub3RlIHRoYXQg UkxGQSBzdXBwb3J0cyBpbmNyZW1lbnRhbCBkZXBsb3ltZW50DQp3ZWxsLCBhbmQgaW4gcGFydGlj dWxhciBuZWVkcyBubyBuZXcgcHJvdG9jb2xzLiBUaGlzIGlzIGluIGNvbnRyYXN0IHRvIGFsbA0K b2YgdGhlIGFsdGVybmF0aXZlcyB0aGF0IGhhdmUgYmVlbiBwdXQgb24gdGhlIHRhYmxlLCB3aGlj aCByZXF1aXJlIHRoZQ0Kb24tcmVwYWlyLXBhdGggbm9kZXMgdG8gY2hhbmdlLg0KPDwNCg0KW0Fu ZHLDoXNdIEkgZGlkbuKAmXQgb21pdCBpdCwganVzdCBkaWRu4oCZdCBnaXZlIGl0IGEgbGlzdCBs ZXR0ZXIuIOKYuiBJIHBlcmZlY3RseSBhZ3JlZSB3aXRoIHlvdSwgYW5kIEkgaGFkIHRoZSBmb2xs b3dpbmcgcXVlc3Rpb24gYWJvdXQgdGhpczogDQoNCj4+IE5laXRoZXIgTEZBLCBub3IgUkxGQSBk byBub3QgcmVxdWlyZSBhbnkgc29ydCBvZiBjb29wZXJhdGlvbiB3aXRoIGFueSBvdGhlciBlbnRp dHk6IHdoYXQgbmVlZHMgdG8gYmUgYSBzdGFuZGFyZCBpbiB0aGVpciBjYXNlcz8gQm90aCBzb3Vu ZCBsaWtlIGEgbm9kZS1pbnRlcm5hbCBmZWF0dXJlIG9yIGEgYmVzdCBwcmFjdGljZSBvciBzb21l dGhpbmcgbGlrZSB0aGF0Ljw8DQoNCkl0IG5vdCBvbmx5IG5lZWRzIG5vIG5ldyBwcm90b2NvbHMs IGl0IG5lZWRzIG5vIG5ldyBmb3JtcyBvZiBjb29wZXJhdGlvbiB3aXRoIGFueSBvdGhlciBlbnRp dHkuIE90aGVyIG5vZGVzIG5lZWQgdG8gc3VwcG9ydCBJUCBlbmNhcHMvZGVjYXBzLCBMRFAgYW5k IFRMRFAsIGJ1dCB0aGVzZSBhcmUgb3RoZXIgUkZDcy4NCg0KDQpBbmRyw6FzDQoNCg== From gabor.sandor.enyedi@ericsson.com Fri Jun 1 01:34:43 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 EE9C821F8656 for ; Fri, 1 Jun 2012 01:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSsaWn7BFSiS for ; Fri, 1 Jun 2012 01:34:42 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E2B4F21F8658 for ; Fri, 1 Jun 2012 01:34:41 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-ac-4fc87ea0fa09 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 69.DE.00702.0AE78CF4; Fri, 1 Jun 2012 10:34:40 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.186]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 1 Jun 2012 10:34:40 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: Alia Atlas , "rtgwg@ietf.org" Date: Fri, 1 Jun 2012 10:34:38 +0200 Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0+hYIDtV+mp3tPSx6Gz7QYpsjsPABSW/dA Message-ID: References: In-Reply-To: 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: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre6CuhP+Bk8eWVt8eniJ2eLCm9/M DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGr/lrWQsmc1d8a21kaWCcy9nFyMkhIWAi 8eXeFDYIW0ziwr31YLaQwClGiWubZLsYuYDsBYwSh9qaWEASbALBEtsfbAArEhFwlfjV/YUd xGYRUJFYc/47M4gtLOApsf7wcagaL4llWz4wQ9hGEl/bpjOB2LwC4RJXjv9kgVgWIDFldh9Y PadAoMStieeA4hwcjAKyEg/XWoCEmQXEJW49mc8EcaeAxJI955khbFGJl4//sYLYjAIyEh+W HmKDqNeTuDF1CpStLbFs4WtmiLWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG4dzEzJz0 cnO91KLM5OLi/Dy94tRNjMAIObjlt8EOxk33xQ4xSnOwKInz6qnu9xcSSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXAaND19mP3xrwwrgWZTFYFjxcuksm+5u4pE6saM+FFq+2/SIvdd5iuHNJl keZ7d2GVwORpi2V2r+Ha5v20J3mXede9DWW3GAznZDCdtH4r1yIxMzhMQLr3bcps8V96n12C JrbUqf789vNMo9iSqUo79pSJL1366IEtz8oHKxZGFVuuKvncFm8tosRSnJFoqMVcVJwIAO0u D/FeAgAA X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 08:34:43 -0000 I conditionally support it. I think we need several further studies; e.g. w= hat are the RLFA friendly topologies, how can I improve my network to keep = up full coverage (and what extra cost that has), what is the bidirectional = coverage of RLFA (if path cannot be protected in either directions, the rou= te is not protected), how many targeted LDP sessions are needed when the ne= twork is not the one operated by Stephane Litkowski, what is the coverage w= hen there was a failure in our network previously and so on. Gabor -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lia Atlas Sent: Wednesday, May 30, 2012 6:59 PM To: rtgwg@ietf.org Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft draft-shand-remote-lfa was presented favorably this last IETF. There is kn= own IPR associated with it on file ( https://datatracker.ietf.org/ipr/1770/= ) This draft presents a solution for IP/LDP fast-reroute that does not gu= arantee 100% coverage but can substantially improve coverage over LFAs. We would like to initiate a WG poll to determine whether to adopt draft-sha= nd-remote-lfa. We are, of course, interested in opinions and reasoning rather than simple = yes/no. Thanks, Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From stbryant@cisco.com Fri Jun 1 01:50: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 0B23D21F85C5 for ; Fri, 1 Jun 2012 01:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.23 X-Spam-Level: X-Spam-Status: No, score=-111.23 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, 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 ELWAkM9dKUXU for ; Fri, 1 Jun 2012 01:50:41 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6E921F8627 for ; Fri, 1 Jun 2012 01:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1196; q=dns/txt; s=iport; t=1338540640; x=1339750240; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sS+Cc/wfTrwjqfvn0fc8poxf3DEBx62PhyJ7XhZtwdI=; b=ZIwZrjUP3f9yR7YSl3THH3RO5gR89eul5HmqQ75ZdRZ6c5dZ16lg0i6/ zgSduFVjWahirjkcDsFQ0BxD+09hplwP5u+Vffv0ORREVls16u+XshRiO 2sqPmokGWXKDA4PqSwEAbV+XkPg7TVRmSKJO5SnA0DiMZTlEc+9UMDtQZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABKCyE+Q/khR/2dsb2JhbABEhU6rF4NPgQeCGAEBAQQSAQIODwEFQRALGAICBSECAg8CRgYNAQcBAR6HaZhBg0cQiT+SUYEjiWyEY4ESA5UZjg+BBGKCYQ X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="73907430" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 01 Jun 2012 08:50:39 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q518odQd031543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2012 08:50:39 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q518objd002224; Fri, 1 Jun 2012 09:50:38 +0100 (BST) Message-ID: <4FC8825D.60405@cisco.com> Date: Fri, 01 Jun 2012 09:50:37 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?QW5kcsOhcyBDc8Ohc3rDoXI=?= Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft References: <8DCD771BDA4A394E9BCBA8932E839297783CF647D0@ESESSCMS0363.eemea.ericsson.se> <31979_1338453231_4FC72CEF_31979_8499_3_4FC3556A36EE3646A09DAA60429F533508612770@PUEXCBL0.nanterre.francetelecom.fr> <4FC74998.70104@cisco.com> <8DCD771BDA4A394E9BCBA8932E839297783CF64CF0@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <8DCD771BDA4A394E9BCBA8932E839297783CF64CF0@ESESSCMS0363.eemea.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtgwg@ietf.org" 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: Fri, 01 Jun 2012 08:50:42 -0000 On 01/06/2012 08:33, András Császár wrote: > Hi Stewart, > > I think that you omitted to note that RLFA supports incremental deployment > well, and in particular needs no new protocols. This is in contrast to all > of the alternatives that have been put on the table, which require the > on-repair-path nodes to change. > << > > [András] I didn’t omit it, just didn’t give it a list letter. ☺ I perfectly agree with you, and I had the following question about this: > >>> Neither LFA, nor RLFA do not require any sort of cooperation with any other entity: what needs to be a standard in their cases? Both sound like a node-internal feature or a best practice or something like that.<< > It not only needs no new protocols, it needs no new forms of cooperation with any other entity. Other nodes need to support IP encaps/decaps, LDP and TLDP, but these are other RFCs. > > > András > Hi Andras I think we are in sync here. As to what track to put this on, that is not obvious and is something that we should discuss with Adrian (who is the AD responsible for the draft) Stewart Note BTW that WRT this draft I am recused and speak only as an author. From retvari@tmit.bme.hu Fri Jun 1 02:32:58 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 D9A3021F863E for ; Fri, 1 Jun 2012 02:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.004 X-Spam-Level: X-Spam-Status: No, score=-4.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8aic2oNyiSi for ; Fri, 1 Jun 2012 02:32:58 -0700 (PDT) Received: from mail.bme.hu (mail.bme.hu [152.66.115.60]) by ietfa.amsl.com (Postfix) with ESMTP id BC9A021F8636 for ; Fri, 1 Jun 2012 02:32:57 -0700 (PDT) Received: from weber.localnet ([152.66.244.61]) by mail.bme.hu (Lotus Domino Release 8.5.2FP3) with ESMTP id 2012060111322807-286372 ; Fri, 1 Jun 2012 11:32:28 +0200 From: Gabor Retvari To: rtgwg@ietf.org, Alia Atlas Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft Date: Fri, 1 Jun 2012 11:32:51 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-2-686-pae; KDE/4.7.4; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <201206011132.51544.retvari@tmit.bme.hu> X-MIMETrack: Itemize by SMTP Server on BME_NOTES_1/BME(Release 8.5.2FP3|July 10, 2011) at 06/01/2012 11:32:28 AM, Serialize by Router on BME_NOTES_1/BME(Release 8.5.2FP3|July 10, 2011) at 06/01/2012 11:32:29 AM, Serialize complete at 06/01/2012 11:32:29 AM X-TNEFEvaluated: 1 Content-Transfer-Encoding: quoted-printable Content-Type: Text/Plain; charset="iso-8859-1" Cc: Levente Csikor X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 09:32:59 -0000 On Friday, June 01, 2012 10:34:38 G=E1bor S=E1ndor Enyedi wrote: > I conditionally support it. I think we need several further studies; e.g. > what are the RLFA friendly topologies, how can I improve my network to > keep up full coverage (and what extra cost that has), what is the > bidirectional coverage of RLFA (if path cannot be protected in either > directions, the route is not protected) Just coincidentally, we have been doing some research on precisely these questions for some time now. So far, we only have had preliminary results, valid only for graphs with unit-costs.=20 Interestingly, we found that if the graph of the network (disregarding LANs, SRLGs, etc. for now) is symmetric, 2-edge-connected, and each link is set to the same administrative cost, then RLFA provides full coverage again= st single link failures. The argument goes on as follows: =2D if some router 's' has an RLFA to the next-hop 'n' towards some destina= tion prefix 'd', then 's' has an RLFA to 'd' (with respect to the failure of link '(s,n)'); =2D if a graph is 2-edge-connected, every edge is contained in at least one ring, so '(s,n)' is also contained in a ring; =2D consider the shortest ring amongst the rings that contain '(s,n)' and suppose that the ring consists of even number of nodes: then, the same reasoning as in the RLFA draft (draft-shand-remote-lfa-00, see Fig. 1) wi= ll show that the intersection of the extended P-space of 's' and the Q-space of 'n' is not empty; =2D so 's' has an RLFA to the next-hop 'n', and so, by the first point, it = has an RLFA to any 'd' reachable through 'n'; =2D the same applies to the case when the shortest ring that contains '(s,n= )' is an odd-ring; =2D since the above holds for any 's-d' pair, we conclude that we have full RLFA coverage. Our initial numerical studies seem to support the above claims, but please, don't hesitate to correct me if I'm wrong. The rest of our investigations are concerned with "unextended RLFA" (i.e., the one without the extended P-space option) to see whether we really need this complexity in RLFA. We found that in 2-node-connected networks "unextended RLFA" coverage can go down to 50%, and in the 2-edge-connected case this can be as low as 33%, so the "extended" option is indeed importan= t. We have a rudimentary draft paper ready. If the need arises, we're happily disclose it. Gabor =2D-=20 G=E1bor R=E9tv=E1ri, Ph.D. Research Fellow, BME-TMIT Phone: +36-1-463-1060 =46ax: +36-1-463-1763 From gabor.sandor.enyedi@ericsson.com Fri Jun 1 02:50:41 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 1320B21F85A2 for ; Fri, 1 Jun 2012 02:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XYRHjBbFUEX for ; Fri, 1 Jun 2012 02:50:40 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E047821F8503 for ; Fri, 1 Jun 2012 02:50:35 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-f3-4fc8906a340a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9B.9A.00702.A6098CF4; Fri, 1 Jun 2012 11:50:35 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.186]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 1 Jun 2012 11:50:34 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: Gabor Retvari , "rtgwg@ietf.org" , Alia Atlas Date: Fri, 1 Jun 2012 11:50:33 +0200 Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0/2Yqvf6wKXLrrSLSYfVbRht4CkAAALHfg Message-ID: References: <201206011132.51544.retvari@tmit.bme.hu> In-Reply-To: <201206011132.51544.retvari@tmit.bme.hu> 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: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+JvrW72hBP+BofPsFh8eniJ2eLP7s+M Fg8nnme2uPDmN7MDi8fOWXfZPZYs+cnksezZPNYA5igum5TUnMyy1CJ9uwSujAOLrAteSFWc abrL3sB4QrSLkZNDQsBE4t66h8wQtpjEhXvr2boYuTiEBE4xSlx6f4AZwlnAKLHq6WMWkCo2 gWCJ7Q82sIHYIgI5EnNe32PsYuTgYBZQl5izWBskzCKgIvH/wwVWEFtYwFNi/eHjUOVeEsu2 fGCGsI0kpnb9AmvlFQiXuLrICWLVSUaJw1t/gq3iFDCVaF1/hQ2khlFAVuLhWguQMLOAuMSt J/OZIG4WkFiy5zzU/aISLx//A1vLKCAj8WHpITaIej2JG1OnQNnaEssWvgar5xUQlDg58wnL BEaxWUjGzkLSMgtJyywkLQsYWVYxCucmZuakl5vrpRZlJhcX5+fpFaduYgRG1cEtvw12MG66 L3aIUZqDRUmcV091v7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRokT381+TZOtlnJfVXwu Pu7S6cC6w1mBwSFTfy/19Jbc2Pb0alPYXek4re1KreXSty/N3ng8IvfDS7+XSU8ad7AfjGHX Xay+2nnZnb2FU9ME8nUrLJ8wLb2uPP/Trd5Xnll/WOQuxs322Ckh7HHBX6zfT/5JQapW3PRg D22vkJg2q1dW4YZWSizFGYmGWsxFxYkAYVEyK3gCAAA= Cc: Levente Csikor X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 09:50:41 -0000 Actually, I'm not really surprised about the 100% coverage. But that is tru= e only for link failures and uniform link costs, right? Isn't that possible= to extend this reasoning to non-uniform link costs to find out what rings = are not useable in that case? Moreover, can't we extend the same reasoning = for node failures? There is simmilar cycle for s and its next-next-hop, whe= n the network is 2-connected... Gabor -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of G= abor Retvari Sent: Friday, June 01, 2012 11:33 AM To: rtgwg@ietf.org; Alia Atlas Cc: Levente Csikor Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft On Friday, June 01, 2012 10:34:38 G=E1bor S=E1ndor Enyedi wrote: > I conditionally support it. I think we need several further studies; e.g. > what are the RLFA friendly topologies, how can I improve my network to=20 > keep up full coverage (and what extra cost that has), what is the=20 > bidirectional coverage of RLFA (if path cannot be protected in either=20 > directions, the route is not protected) Just coincidentally, we have been doing some research on precisely these qu= estions for some time now. So far, we only have had preliminary results, va= lid only for graphs with unit-costs.=20 Interestingly, we found that if the graph of the network (disregarding LANs= , SRLGs, etc. for now) is symmetric, 2-edge-connected, and each link is set= to the same administrative cost, then RLFA provides full coverage against = single link failures. The argument goes on as follows: - if some router 's' has an RLFA to the next-hop 'n' towards some destinati= on prefix 'd', then 's' has an RLFA to 'd' (with respect to the failure of link '(s,n)'); - if a graph is 2-edge-connected, every edge is contained in at least one ring, so '(s,n)' is also contained in a ring; - consider the shortest ring amongst the rings that contain '(s,n)' and suppose that the ring consists of even number of nodes: then, the same reasoning as in the RLFA draft (draft-shand-remote-lfa-00, see Fig. 1) wi= ll show that the intersection of the extended P-space of 's' and the Q-space of 'n' is not empty; - so 's' has an RLFA to the next-hop 'n', and so, by the first point, it ha= s an RLFA to any 'd' reachable through 'n'; - the same applies to the case when the shortest ring that contains '(s,n)' is an odd-ring; - since the above holds for any 's-d' pair, we conclude that we have full RLFA coverage. Our initial numerical studies seem to support the above claims, but please,= don't hesitate to correct me if I'm wrong. The rest of our investigations are concerned with "unextended RLFA" (i.e., = the one without the extended P-space option) to see whether we really need = this complexity in RLFA. We found that in 2-node-connected networks "unext= ended RLFA" coverage can go down to 50%, and in the 2-edge-connected case t= his can be as low as 33%, so the "extended" option is indeed important. We have a rudimentary draft paper ready. If the need arises, we're happily = disclose it. Gabor -- G=E1bor R=E9tv=E1ri, Ph.D. Research Fellow, BME-TMIT Phone: +36-1-463-1060 Fax: +36-1-463-1763 _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From pierre.francois@imdea.org Fri Jun 1 03:26: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 BDB8221F866A for ; Fri, 1 Jun 2012 03:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 MURC3ymQ5Nle for ; Fri, 1 Jun 2012 03:26:46 -0700 (PDT) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 11EB221F8668 for ; Fri, 1 Jun 2012 03:26:44 -0700 (PDT) Received: from localhost (estafeta22.imdea.org [172.17.99.146]) by estafeta22.imdea.org (Postfix) with ESMTP id F26DB26381E; Fri, 1 Jun 2012 12:26:41 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.146]) by localhost (estafeta22.imdea.org [172.17.99.146]) (amavisd-new, port 10024) with ESMTP id YbUFWlSgyuWS; Fri, 1 Jun 2012 12:26:41 +0200 (CEST) Received: from pierre.networks.imdea.org (unknown [193.145.14.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta22.imdea.org (Postfix) with ESMTP id B661A26381D; Fri, 1 Jun 2012 12:26:41 +0200 (CEST) Message-ID: <4FC898E1.6030002@imdea.org> Date: Fri, 01 Jun 2012 12:26:41 +0200 From: Pierre Francois User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Gabor Retvari Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft References: <201206011132.51544.retvari@tmit.bme.hu> In-Reply-To: <201206011132.51544.retvari@tmit.bme.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Levente Csikor , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 10:26:47 -0000 Gabor, Your analysis is right. It is a strong assumption to consider that all links have the same metric, though. You can get rid of that assumption if you consider PQ with directed forwarding. I had proved that in my thesis when I was young ;-) biblio.info.ucl.ac.be/2007/457147.pdf (page 59) Pierre. On 6/1/12 11:32 AM, Gabor Retvari wrote: > On Friday, June 01, 2012 10:34:38 Gábor Sándor Enyedi wrote: >> I conditionally support it. I think we need several further studies; e.g. >> what are the RLFA friendly topologies, how can I improve my network to >> keep up full coverage (and what extra cost that has), what is the >> bidirectional coverage of RLFA (if path cannot be protected in either >> directions, the route is not protected) > Just coincidentally, we have been doing some research on precisely these > questions for some time now. So far, we only have had preliminary results, > valid only for graphs with unit-costs. > > Interestingly, we found that if the graph of the network (disregarding LANs, > SRLGs, etc. for now) is symmetric, 2-edge-connected, and each link is > set to the same administrative cost, then RLFA provides full coverage against > single link failures. > > The argument goes on as follows: > > - if some router 's' has an RLFA to the next-hop 'n' towards some destination > prefix 'd', then 's' has an RLFA to 'd' (with respect to the failure of > link '(s,n)'); > > - if a graph is 2-edge-connected, every edge is contained in at least one > ring, so '(s,n)' is also contained in a ring; > > - consider the shortest ring amongst the rings that contain '(s,n)' and > suppose that the ring consists of even number of nodes: then, the same > reasoning as in the RLFA draft (draft-shand-remote-lfa-00, see Fig. 1) will > show that the intersection of the extended P-space of 's' and the Q-space > of 'n' is not empty; > > - so 's' has an RLFA to the next-hop 'n', and so, by the first point, it has > an RLFA to any 'd' reachable through 'n'; > > - the same applies to the case when the shortest ring that contains '(s,n)' > is an odd-ring; > > - since the above holds for any 's-d' pair, we conclude that we have full > RLFA coverage. > > Our initial numerical studies seem to support the above claims, but please, > don't hesitate to correct me if I'm wrong. > > The rest of our investigations are concerned with "unextended RLFA" (i.e., > the one without the extended P-space option) to see whether we really need > this complexity in RLFA. We found that in 2-node-connected networks > "unextended RLFA" coverage can go down to 50%, and in the 2-edge-connected > case this can be as low as 33%, so the "extended" option is indeed important. > > We have a rudimentary draft paper ready. If the need arises, we're happily > disclose it. > > Gabor > From stbryant@cisco.com Fri Jun 1 03:35:27 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 5E67521F8613 for ; Fri, 1 Jun 2012 03:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.31 X-Spam-Level: X-Spam-Status: No, score=-110.31 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 izCQyiuPA8am for ; Fri, 1 Jun 2012 03:35:26 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6099321F84DF for ; Fri, 1 Jun 2012 03:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2153; q=dns/txt; s=iport; t=1338546926; x=1339756526; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8IG/04wSOxUvPzZ+7xITjIZj0GX0DdvJreyy8AMpun0=; b=X/S9KfrAkjvdTGHhIubt/z0ejQAlyb8RjxiZSoh/2mvTyWW0/zpazdPo sCC6AcMjWMB1xnGtL0rOxSuH6A9Z+SEIXbluh4AKR/zvLcRs+ApKMYzwO 7BpeFfm1FtOljv/nBtEFu0Hu3RsfbjcPbnBXLqwm0p6hR8iuJqr/wB5Jc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIuZyE+Q/khN/2dsb2JhbABEtDaBB4IYAQEBBAEBAQ8BAgMaAQU2CgEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBARcHh2kLmEKDRxCcF4sPhXUDlRmOD4EEYoJh X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="73913667" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Jun 2012 10:35:25 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q51AZO1h032661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2012 10:35:25 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q51AZNhU009012; Fri, 1 Jun 2012 11:35:24 +0100 (BST) Message-ID: <4FC89AEB.5070803@cisco.com> Date: Fri, 01 Jun 2012 11:35:23 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft References: In-Reply-To: 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.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: Fri, 01 Jun 2012 10:35:27 -0000 Gabor Those are very reasonable questions, however it is quite a difficult problem to address since we need real topologies and these are only available under non-disclosure from network operators. This has historically been a particular problem for the academic IPFRR researchers. Section 7.3 of the draft is a survey of a number of operational networks that we have analyzed. Stewart (as author) On 01/06/2012 09:34, Gábor Sándor Enyedi wrote: > I conditionally support it. I think we need several further studies; e.g. what are the RLFA friendly topologies, how can I improve my network to keep up full coverage (and what extra cost that has), what is the bidirectional coverage of RLFA (if path cannot be protected in either directions, the route is not protected), how many targeted LDP sessions are needed when the network is not the one operated by Stephane Litkowski, what is the coverage when there was a failure in our network previously and so on. > > Gabor > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Wednesday, May 30, 2012 6:59 PM > To: rtgwg@ietf.org > Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft > > draft-shand-remote-lfa was presented favorably this last IETF. There is known IPR associated with it on file ( https://datatracker.ietf.org/ipr/1770/ ) This draft presents a solution for IP/LDP fast-reroute that does not guarantee 100% coverage but can substantially improve coverage over LFAs. > > We would like to initiate a WG poll to determine whether to adopt draft-shand-remote-lfa. > We are, of course, interested in opinions and reasoning rather than simple yes/no. > > Thanks, > Alia > _______________________________________________ > 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 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From gabor.sandor.enyedi@ericsson.com Fri Jun 1 03:47:29 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 1498521F8642 for ; Fri, 1 Jun 2012 03:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5L1bokOlCX3 for ; Fri, 1 Jun 2012 03:47:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D268E21F85E4 for ; Fri, 1 Jun 2012 03:47:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-a0-4fc89dbe1d15 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DF.15.28636.EBD98CF4; Fri, 1 Jun 2012 12:47:27 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.186]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 1 Jun 2012 12:47:26 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: "stbryant@cisco.com" Date: Fri, 1 Jun 2012 12:47:24 +0200 Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0/4kHYytWBUhtUR5GJ12idsb2dnwAAFrCQ Message-ID: References: <4FC89AEB.5070803@cisco.com> In-Reply-To: <4FC89AEB.5070803@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: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvre7+uSf8DTY0MFt8eniJ2eLCm9/M FueezmF0YPaY8nsjq8fOWXfZPZYs+ckUwBzFZZOSmpNZllqkb5fAlfFm52r2gptiFev/7mRs YLwo1MXIySEhYCLxqecJK4QtJnHh3nq2LkYuDiGBU4wSV/ZMYoRwFjBKnNr0nQ2kik0gWGL7 gw1gtoiArsTsDTcYQWxmAVeJX4sPsoPYLAIqEjvf/2EBsYUFPCXWHz4OVe8lsWzLB2YI20ji ysYFYDavQLjEs//bmSCW7WWU+PH/PdggTgFNiet73wIN4uBgFJCVeLjWAmKXuMStJ/OZIK4W kFiy5zwzhC0q8fLxP7BvGAVkJD4sPcQGUa8ncWPqFChbW2LZwtdQewUlTs58wjKBUWwWkrGz kLTMQtIyC0nLAkaWVYzCuYmZOenlhnqpRZnJxcX5eXrFqZsYgRF1cMtv3R2Mp86JHGKU5mBR EuflStrvLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRevfri/Nv1rs47SgT/FavvWzZRocH bfKyNkKlbkKneM49D/lkbq0194/upvNsxrNOfP+x7M/Hu8+sODSvMTj52c6M+rrmlMZej0VH Z8q+ijjM+KaTh5XJvyDp4t93k36sX2bM77Ftkaxlz+KNf1VDL7zcWS+5uO55z2kVQZ47fk5b ly9n9f8tpMRSnJFoqMVcVJwIADfTK8t2AgAA Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 10:47:29 -0000 Yes, I know that, we have the same problem. However, considering your resul= ts in section 7.3, I'm not sure what coverage is presented there. Is that t= he coverage of link or node protection? If that is only link protection, ca= n you please add the same for node protection? Did you take into considerat= ion that we almost always need bidirectional connection? That would be nice= to add this information to the draft. Gabor -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Friday, June 01, 2012 12:35 PM To: G=E1bor S=E1ndor Enyedi Cc: Alia Atlas; rtgwg@ietf.org Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft Gabor Those are very reasonable questions, however it is quite a difficult proble= m to address since we need real topologies and these are only available und= er non-disclosure from network operators. This has historically been a particular problem for the academic IPFRR rese= archers. Section 7.3 of the draft is a survey of a number of operational networks th= at we have analyzed. Stewart (as author) On 01/06/2012 09:34, G=E1bor S=E1ndor Enyedi wrote: > I conditionally support it. I think we need several further studies; e.g.= what are the RLFA friendly topologies, how can I improve my network to kee= p up full coverage (and what extra cost that has), what is the bidirectiona= l coverage of RLFA (if path cannot be protected in either directions, the r= oute is not protected), how many targeted LDP sessions are needed when the = network is not the one operated by Stephane Litkowski, what is the coverage= when there was a failure in our network previously and so on. > > Gabor > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf=20 > Of Alia Atlas > Sent: Wednesday, May 30, 2012 6:59 PM > To: rtgwg@ietf.org > Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft > > draft-shand-remote-lfa was presented favorably this last IETF. There is = known IPR associated with it on file ( https://datatracker.ietf.org/ipr/177= 0/ ) This draft presents a solution for IP/LDP fast-reroute that does not = guarantee 100% coverage but can substantially improve coverage over LFAs. > > We would like to initiate a WG poll to determine whether to adopt draft-s= hand-remote-lfa. > We are, of course, interested in opinions and reasoning rather than simpl= e yes/no. > > Thanks, > Alia > _______________________________________________ > 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 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From eosborne@cisco.com Fri Jun 1 04:37:33 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 7E45721F85B6 for ; Fri, 1 Jun 2012 04:37:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0u7iXZFSks9Z for ; Fri, 1 Jun 2012 04:37:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6673B21F8615 for ; Fri, 1 Jun 2012 04:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=962; q=dns/txt; s=iport; t=1338550652; x=1339760252; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Zk7V8J6eVqvKDSO2uOXINWBt7acxHTV5jN4RxufEO4Y=; b=RNNIzlm/iJHMC6YsagVsy0h5bej/w1oMAD7LU2Pz+jg8HM/FtR9yaFqN la/RSMtkpjeaMdOyHffKknL6IzGEGOMxmiUOdWZrJgoaMCgXmiwcHh4S1 rMPhm23FU61uUOg6a87DyxtiSboIIgksTfSeLkZ7FUK5CADMkL1+LnFYX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHioyE+tJXG9/2dsb2JhbABEtDaBB4IYAQEBBAEBAQ8BHQo0FwQCAQgOAwQBAQsGFwEGASYfCQgBAQQBEggTB4dpC5gtn28Eiw+FFWADiECaaIFmgn4 X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="88618651" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 01 Jun 2012 11:37:32 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q51BbVx9030811; Fri, 1 Jun 2012 11:37:31 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jun 2012 06:37:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Date: Fri, 1 Jun 2012 06:37:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0+hYLRQqx/Oy2QTl22sAUAHqeGhgBZWlQw References: From: "Eric Osborne (eosborne)" To: "Alia Atlas" , X-OriginalArrivalTime: 01 Jun 2012 11:37:31.0851 (UTC) FILETIME=[EE6B29B0:01CD3FEA] X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 11:37:33 -0000 Support eric > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Alia Atlas > Sent: Wednesday, May 30, 2012 12:59 PM > To: rtgwg@ietf.org > Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft >=20 > draft-shand-remote-lfa was presented favorably this last IETF. There > is known IPR > associated with it on file ( https://datatracker.ietf.org/ipr/1770/ ) > This draft presents > a solution for IP/LDP fast-reroute that does not guarantee 100% > coverage but can substantially > improve coverage over LFAs. >=20 > We would like to initiate a WG poll to determine whether to adopt > draft-shand-remote-lfa. > We are, of course, interested in opinions and reasoning rather than > simple yes/no. >=20 > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From robert@raszuk.net Fri Jun 1 05:43:32 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 CA0C711E834C for ; Fri, 1 Jun 2012 05:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 Ofj2RUbVZsqI for ; Fri, 1 Jun 2012 05:43:32 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E7CA311E831F for ; Fri, 1 Jun 2012 05:43:30 -0700 (PDT) Received: (qmail 11792 invoked by uid 399); 1 Jun 2012 12:43:28 -0000 Received: from unknown (HELO ?100.231.105.64?) (pbs:robert@raszuk.net@208.54.44.197) by mail1310.opentransfer.com with ESMTPM; 1 Jun 2012 12:43:28 -0000 X-Originating-IP: 208.54.44.197 To: eosborne@cisco.com, "=?utf-8?B?QWxpYSBBdGxhcw==?=" , rtgwg@ietf.org From: "=?utf-8?B?cm9iZXJ0QHJhc3p1ay5uZXQ=?=" Subject: =?utf-8?B?UmU6IG9waW5pb25zIG9uIGFkb3B0aW9uIG9mIGRyYWZ0LXNoYW5kLXJlbW90ZS1s?= =?utf-8?B?ZmEgYXMgYSBXRyBkcmFmdA==?= Date: Fri, 01 Jun 2012 14:43:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1338554609719" Message-Id: <20120601124330.E7CA311E831F@ietfa.amsl.com> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 12:43:32 -0000 ------=_Part_0_1338554609719 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U3VwcG9ydApSLgoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiRXJpYyBPc2Jvcm5l IChlb3Nib3JuZSkiIDxlb3Nib3JuZUBjaXNjby5jb20+ClRvOiAiQWxpYSBBdGxhcyIgPGFrYXRs YXNAZ21haWwuY29tPiwgPHJ0Z3dnQGlldGYub3JnPgpTdWJqZWN0OiBvcGluaW9ucyBvbiBhZG9w dGlvbiBvZiBkcmFmdC1zaGFuZC1yZW1vdGUtbGZhIGFzIGEgV0cgZHJhZnQKRGF0ZTogRnJpLCBK dW4gMSwgMjAxMiAxMzozNwoKClN1cHBvcnQKCgoKCmVyaWMKCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0KPiBGcm9tOiBydGd3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRnd2ctYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmCk9mCj4gQWxpYSBBdGxhcwo+IFNlbnQ6IFdlZG5lc2Rh eSwgTWF5IDMwLCAyMDEyIDEyOjU5IFBNCj4gVG86IHJ0Z3dnQGlldGYub3JnCj4gU3ViamVjdDog b3BpbmlvbnMgb24gYWRvcHRpb24gb2YgZHJhZnQtc2hhbmQtcmVtb3RlLWxmYSBhcyBhIFdHIGRy YWZ0Cj4gCj4gZHJhZnQtc2hhbmQtcmVtb3RlLWxmYSB3YXMgcHJlc2VudGVkIGZhdm9yYWJseSB0 aGlzIGxhc3QgSUVURi4gIFRoZXJlCj4gaXMga25vd24gSVBSCj4gYXNzb2NpYXRlZCB3aXRoIGl0 IG9uIGZpbGUgKCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xNzcwLyApCj4gIFRo aXMgZHJhZnQgcHJlc2VudHMKPiBhIHNvbHV0aW9uIGZvciBJUC9MRFAgZmFzdC1yZXJvdXRlIHRo YXQgZG9lcyBub3QgZ3VhcmFudGVlIDEwMCUKPiBjb3ZlcmFnZSBidXQgY2FuIHN1YnN0YW50aWFs bHkKPiBpbXByb3ZlIGNvdmVyYWdlIG92ZXIgTEZBcy4KPiAKPiBXZSB3b3VsZCBsaWtlIHRvIGlu aXRpYXRlIGEgV0cgcG9sbCB0byBkZXRlcm1pbmUgd2hldGhlciB0byBhZG9wdAo+IGRyYWZ0LXNo YW5kLXJlbW90ZS1sZmEuCj4gV2UgYXJlLCBvZiBjb3Vyc2UsIGludGVyZXN0ZWQgaW4gb3Bpbmlv bnMgYW5kIHJlYXNvbmluZyByYXRoZXIgdGhhbgo+IHNpbXBsZSB5ZXMvbm8uCj4gCj4gVGhhbmtz LAo+IEFsaWEKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+IHJ0Z3dnIG1haWxpbmcgbGlzdAo+IHJ0Z3dnQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3ZwpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpydGd3ZyBtYWlsaW5nIGxpc3QKcnRnd2dAaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zwo= ------=_Part_0_1338554609719 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U3VwcG9ydDxicj5SLjxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAm cXVvdDtFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSZxdW90OyAmbHQ7ZW9zYm9ybmVAY2lzY28uY29t Jmd0Ozxicj5UbzogJnF1b3Q7QWxpYSBBdGxhcyZxdW90OyAmbHQ7YWthdGxhc0BnbWFpbC5jb20m Z3Q7LCAmbHQ7cnRnd2dAaWV0Zi5vcmcmZ3Q7PGJyPlN1YmplY3Q6IG9waW5pb25zIG9uIGFkb3B0 aW9uIG9mIGRyYWZ0LXNoYW5kLXJlbW90ZS1sZmEgYXMgYSBXRyBkcmFmdDxicj5EYXRlOiBGcmks IEp1biAxLCAyMDEyIDEzOjM3PGJyPjxicj48YnI+U3VwcG9ydDxicj48YnI+PGJyPjxicj48YnI+ ZXJpYzxicj48YnI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206 IHJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGY8YnI+T2Y8YnI+Jmd0OyBBbGlhIEF0bGFzPGJyPiZndDsgU2VudDogV2VkbmVzZGF5 LCBNYXkgMzAsIDIwMTIgMTI6NTkgUE08YnI+Jmd0OyBUbzogcnRnd2dAaWV0Zi5vcmc8YnI+Jmd0 OyBTdWJqZWN0OiBvcGluaW9ucyBvbiBhZG9wdGlvbiBvZiBkcmFmdC1zaGFuZC1yZW1vdGUtbGZh IGFzIGEgV0cgZHJhZnQ8YnI+Jmd0OyA8YnI+Jmd0OyBkcmFmdC1zaGFuZC1yZW1vdGUtbGZhIHdh cyBwcmVzZW50ZWQgZmF2b3JhYmx5IHRoaXMgbGFzdCBJRVRGLiAmbmJzcDtUaGVyZTxicj4mZ3Q7 IGlzIGtub3duIElQUjxicj4mZ3Q7IGFzc29jaWF0ZWQgd2l0aCBpdCBvbiBmaWxlICggaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMTc3MC8gKTxicj4mZ3Q7ICZuYnNwO1RoaXMgZHJh ZnQgcHJlc2VudHM8YnI+Jmd0OyBhIHNvbHV0aW9uIGZvciBJUC9MRFAgZmFzdC1yZXJvdXRlIHRo YXQgZG9lcyBub3QgZ3VhcmFudGVlIDEwMCU8YnI+Jmd0OyBjb3ZlcmFnZSBidXQgY2FuIHN1YnN0 YW50aWFsbHk8YnI+Jmd0OyBpbXByb3ZlIGNvdmVyYWdlIG92ZXIgTEZBcy48YnI+Jmd0OyA8YnI+ Jmd0OyBXZSB3b3VsZCBsaWtlIHRvIGluaXRpYXRlIGEgV0cgcG9sbCB0byBkZXRlcm1pbmUgd2hl dGhlciB0byBhZG9wdDxicj4mZ3Q7IGRyYWZ0LXNoYW5kLXJlbW90ZS1sZmEuPGJyPiZndDsgV2Ug YXJlLCBvZiBjb3Vyc2UsIGludGVyZXN0ZWQgaW4gb3BpbmlvbnMgYW5kIHJlYXNvbmluZyByYXRo ZXIgdGhhbjxicj4mZ3Q7IHNpbXBsZSB5ZXMvbm8uPGJyPiZndDsgPGJyPiZndDsgVGhhbmtzLDxi cj4mZ3Q7IEFsaWE8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4mZ3Q7IHJ0Z3dnIG1haWxpbmcgbGlzdDxicj4mZ3Q7IHJ0Z3dnQGlldGYu b3JnPGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zzxi cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5ydGd3 ZyBtYWlsaW5nIGxpc3Q8YnI+cnRnd2dAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGd3Zzxicj4= ------=_Part_0_1338554609719-- From russw@riw.us Fri Jun 1 05:51:21 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 3669A11E8140 for ; Fri, 1 Jun 2012 05:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012] 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 gflp2U15zL38 for ; Fri, 1 Jun 2012 05:51:20 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCA811E819B for ; Fri, 1 Jun 2012 05:51:20 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SaRK4-0007m5-3g for rtgwg@ietf.org; Fri, 01 Jun 2012 05:51:20 -0700 Message-ID: <4FC8BACA.3030108@riw.us> Date: Fri, 01 Jun 2012 08:51:22 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft References: <4126_1338459866_4FC746DA_4126_7369_1_53C29892C857584299CBF5D05346208A08B03B@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <4126_1338459866_4FC746DA_4126_7369_1_53C29892C857584299CBF5D05346208A08B03B@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 12:51:21 -0000 Support. Russ On 5/31/2012 6:24 AM, bruno.decraene@orange.com wrote: > Alia, Alvaro, > > I support adoption. > > As requested, below some (quickly written) opinions: > > Positive: > ++ Incremental deployment with incremental benefits. > (Eventually some focused deployments may be enough to solve the main LFA limitations.) > + Relatively easy understanding (and possibly control) for the network operator of the path taken by the traffic. Useful for capacity planning, network manageability and respect of design rules (e.g. don't use a PE to backup a P) > + Relative simplicity > + Can provide 100% coverage in some real networks. (at least one I am aware of) > > > Negative: > - "esthetic": some "random" (from human design perspective) mesh of control plane sessions. May have an impact on the management/monitoring. (e.g. how many T-LDP sessions am I supposed on have on node XT6 ? Is one missing?). > - lacks 100% guaranteed coverage. Could eventually be worked on (e.g. studies, addition of (virtual TE) links) but requires work :-) > > > Positive definitely outweighs the negative. > IMHO will be deployed, with or without the IETF. I would prefer with the IETF review and standardization. > > Regards, > Bruno > >>From Alia Atlas >Sent: Wednesday, May 30, 2012 6:59 PM >> Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft >> >> draft-shand-remote-lfa was presented favorably this last IETF. There >> is known IPR >> associated with it on file ( https://datatracker.ietf.org/ipr/1770/ ) >> This draft presents >> a solution for IP/LDP fast-reroute that does not guarantee 100% >> coverage but can substantially >> improve coverage over LFAs. >> >> We would like to initiate a WG poll to determine whether to adopt >> draft-shand-remote-lfa. >> We are, of course, interested in opinions and reasoning rather than >> simple yes/no. >> >> Thanks, >> Alia >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > 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 authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg -- <>< riwhite@verisign.com russw@riw.us From retvari@tmit.bme.hu Fri Jun 1 06:42:52 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 3A6C411E81A6 for ; Fri, 1 Jun 2012 06:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.004 X-Spam-Level: X-Spam-Status: No, score=-4.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v8XJs7L4sGg for ; Fri, 1 Jun 2012 06:42:51 -0700 (PDT) Received: from mail.bme.hu (mail.bme.hu [152.66.115.60]) by ietfa.amsl.com (Postfix) with ESMTP id 66C6111E81AB for ; Fri, 1 Jun 2012 06:42:51 -0700 (PDT) Received: from weber.localnet ([152.66.244.61]) by mail.bme.hu (Lotus Domino Release 8.5.2FP3) with ESMTP id 2012060115422138-288781 ; Fri, 1 Jun 2012 15:42:21 +0200 From: Gabor Retvari To: rtgwg@ietf.org Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft Date: Fri, 1 Jun 2012 15:42:46 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-2-686-pae; KDE/4.7.4; i686; ; ) References: <201206011132.51544.retvari@tmit.bme.hu> In-Reply-To: <201206011132.51544.retvari@tmit.bme.hu> MIME-Version: 1.0 Message-Id: <201206011542.46720.retvari@tmit.bme.hu> X-MIMETrack: Itemize by SMTP Server on BME_NOTES_1/BME(Release 8.5.2FP3|July 10, 2011) at 06/01/2012 03:42:21 PM, Serialize by Router on BME_NOTES_1/BME(Release 8.5.2FP3|July 10, 2011) at 06/01/2012 03:42:23 PM, Serialize complete at 06/01/2012 03:42:23 PM X-TNEFEvaluated: 1 Content-Transfer-Encoding: 7bit Content-Type: Text/Plain; charset="iso-8859-1" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:42:52 -0000 On Friday, June 01, 2012 11:32:51 Gabor Retvari wrote: > Just coincidentally, we have been doing some research on precisely these > questions for some time now. So far, we only have had preliminary results, > valid only for graphs with unit-costs. [...] > We have a rudimentary draft paper ready. If the need arises, we're happily > disclose it. Dear all, Some people have asked the draft privately, so we made it available online: http://qosip.tmit.bme.hu/~retvari/publications/rndm_2012.pdf Please, keep it private as much as possible. We are open to any comments, corrections, etc. Best regards, Gabor From stbryant@cisco.com Fri Jun 1 06:44:40 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 B1F2711E8197 for ; Fri, 1 Jun 2012 06:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.467 X-Spam-Level: X-Spam-Status: No, score=-110.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 0POJO0IoZV20 for ; Fri, 1 Jun 2012 06:44:40 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id C13C911E81AB for ; Fri, 1 Jun 2012 06:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1828; q=dns/txt; s=iport; t=1338558279; x=1339767879; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FwqqJXUZ7mZtcS5lWFa+1EVQVEshNt3nKdxy355BFcE=; b=MRWV3MdgDC+TztCTRNs/KO5ps/P2U4/DVNuu6HO2D62CI/p0IZFXEIA7 zalFFv4oJyTxyhl81ZSu4XEQC0nyjfSpL72L5E7gGyDFhW1cxjMy6eQxl O1F+xmTSuqD0XJDobHWODyQl0a4NV1+s8ulwAJU7E0HUehbkunUcUW6cr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEzGyE+Q/khN/2dsb2JhbABFtDeBB4IYAQEBBAEBAQ8BAiM2CwwECxEEAQEBCR4HDwIWHwkIEwEFAgEBFweHaQuYH4NHEJwiiw+CX4MWA5UZjg+BBGKCYYFe X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="5265577" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 01 Jun 2012 13:44:30 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q51DiU5o021893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2012 13:44:30 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q51DiTC5021356; Fri, 1 Jun 2012 14:44:30 +0100 (BST) Message-ID: <4FC8C73D.10507@cisco.com> Date: Fri, 01 Jun 2012 14:44:29 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft References: <014401cd3f38$34e231d0$9ea69570$@olddog.co.uk> In-Reply-To: <014401cd3f38$34e231d0$9ea69570$@olddog.co.uk> 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 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: Fri, 01 Jun 2012 13:44:40 -0000 I have refreshed the draft. A couple of minor changes, that will not impact the review: 1) Fixed Mike's affiliation and email address 2) Fixed Ning's email address (need to fix his affiliation when I know what to put in) 3) Fixed a formatting error (section 8 was not shown as a proper section) Any other changes are an error caused in the process of recovering the correct XML. Stewart (as duty editor) On 31/05/2012 15:18, Adrian Farrel wrote: > Just a personal (non AD comment). > > I would prefer that polls were conducted on extant I-Ds, not ones that have > expired. > > Cheers, > Adrian > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of >> Alia Atlas >> Sent: 30 May 2012 17:59 >> To: rtgwg@ietf.org >> Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft >> >> draft-shand-remote-lfa was presented favorably this last IETF. There >> is known IPR >> associated with it on file ( https://datatracker.ietf.org/ipr/1770/ ) >> This draft presents >> a solution for IP/LDP fast-reroute that does not guarantee 100% >> coverage but can substantially >> improve coverage over LFAs. >> >> We would like to initiate a WG poll to determine whether to adopt >> draft-shand-remote-lfa. >> We are, of course, interested in opinions and reasoning rather than >> simple yes/no. >> >> Thanks, >> Alia >> _______________________________________________ >> 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 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From curtis@occnc.com Fri Jun 1 08:36:58 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 B042911E8143 for ; Fri, 1 Jun 2012 08:36:58 -0700 (PDT) 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 f-59OhCTD0HP for ; Fri, 1 Jun 2012 08:36:57 -0700 (PDT) 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 5B01311E8135 for ; Fri, 1 Jun 2012 08:36:57 -0700 (PDT) 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 q51Fal7I082882; Fri, 1 Jun 2012 08:36:47 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206011536.q51Fal7I082882@gateway.ipv6.occnc.com> To: Iftekhar Hussain From: Curtis Villamizar Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) In-reply-to: Your message of "Thu, 24 May 2012 21:47:11 -0000." Date: Fri, 01 Jun 2012 11:36:47 -0400 Cc: "rtgwg@ietf.org" 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: Fri, 01 Jun 2012 15:36:58 -0000 Iftekhar, In response to your comment: > I also think, it would be a good idea to indicate the consequences > of such load balancing change (if this event is going to cause > service disruption). FR#4 and FR#12 might be relevant. The only thing we could do to make this more clear is to put in a cross reference any where that "minimally disruptive" is mentioned and maybe even put "minimally disruptive" and "delay discontinuity" in the Definitions section. The proposed text so far is: [FR#N] Load balancing MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction. As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. The network operator when configuring a network for power reduction should weight the benefit of power reduction against the disadvantage of a minimal disruption. I could change the cautioning paragraph to: As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive (See FR#12). Typically the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. The network operator when configuring a network for power reduction should weight the benefit of power reduction against the disadvantage of a minimal disruption. Note that the only change is (See FR#12). I really can't see how this could be more clear. I also can't see how "The network operator when configuring a network for power reduction should weight the benefit of power reduction against the disadvantage of a minimal disruption" could be more clear about the operator having a choice as to whether to enable this feature and in configuring it. What follows is more background on the use of the term "minimally disruptive", though I think we've been through this before. Minimally disruptive is the term we use to describe the impact of a load balancing event. The implication of "minimally disruptive" is a very small disruption, as small as practical. Given that there is more than two decades of experience with this type of load balancing technique, what we mean by "minimally disruptive" is well known by those who have experience with multipath (ECMP, LAG, etc) and by those who carefully read what has been written in the set of three documents and in the references (the latter may be the null set or close to it). Lets start with experience with this technique on the big Internet (service provider core networks). Briefly: 1987 - T1 NSFNET - load balancing was done due to inability of PC-RT to process traffic at full data rate (we know that is pathetic) 1990 - T3 NSFNET - anyone not needing a T3/DS3 (45 Mb/s) could make use of multiple T1/DS1 circuits at a lower cost than commercial pricing for fractional T3/DS3. 1994 - Use of parallel T3/DS3 before OC3 was available and/or priced within reason. 1996-2000 - use of parallel OC3, then OC12, then OC48 as Internet growth consistently outpaced available circuits on commercial market and/or router blades. 2001-present - exhaustive use of parallel OC192, then 10GbE. Note that OC192 and OC768 router blades are much more expensive than 10GbE and therefore 40 Gb/s has not overtaken 10 Gb/s. Today both are carried over OTN in many transport networks but this is referring to the IP/MPLS interfaces in use. Note that I am not including Ethernet Link Aggregation above, though it too is now extensively used in conjunction with ECMP. Look in draft-symmvo-rtgwg-cl-use-cases (Composite Link Use Cases) at Appendix B "Existing Multipath Standards and Techniques" for some details on the techniques used in the past and present. We had discussed what minimally disruptive means in a prior thread. draft-ietf-rtgwg-cl-requirement Composite Link Requirements 4.3. Parallel Component Links with Different Characteristics Page 8 FR#12 When a traffic flow is moved from one component link to another in the same composite link between a set of nodes (or sites), it MUST be done so in a minimally disruptive manner. When a flow is moved from a current link to a target link with different latency, reordering can occur if the target link latency is less than that of the current or clumping can occur if target link latency is greater than that of the current. Therefore, some flows (e.g., timing distribution, PW circuit emulation) are quite sensitive to these effects, which may be specified in an NPO or are needed to meet a user experience objective (e.g. jitter buffer under/overrun). draft-so-yong-rtgwg-cl-framework Composite Link Framework 2.2. Composite Link in Control Plane Page 10 Individual component link may fail independently. Upon component link failure, a composite link MUST support a minimally disruptive local repair, preempting any LSP which can no longer be supported. Available capacity in other component links MUST be used to carry impacted traffic. The available bandwidth after failure MUST be advertised immediately to avoid looped crankback. When a composite link is not able to transport all LSP, it preempts some LSP based upon local management configuration and informs the control plane on these preempted LSP. The composite link MUST support soft preemption [RFC5712]. This action ensures the remaining traffic is transported properly. FR#10 requires that the traffic be restored. FR#12 requires that any change be minimally disruptive. These two requirements are interpreted to include preemption among the types of changes that must be minimally disruptive. 4.2.2. Very Large Microflows Page 20 Some techniques are susceptible to statistical collisions where an algorithm to distribute traffic is unable to disambiguate traffic among two or more very large microflow where their sum is in excess of the capacity of any single component. Hash based algorithms which use too small a hash space are particularly susceptible and require a change in hash seed in the event that this were to occur. A change in hash seed is highly disruptive, causing traffic reordering among all traffic flows over which the hash function is applied. 7.2.9. Minimally Disruption Load Balance Page 29 The behavior of hash methods used in classic multipath needs to be described in terms of FR#12 which calls for minimally disruptive load adjustments. For example, reseeding the hash violates FR#12. Using modulo operations is significantly disruptive if a link comes or goes down, as pointed out in [RFC2992]. In addition, backwards compatibility with older hardware needs to be accommodated. In past email we agreed to introduce the term "delay discontinuity" which has been used for close to two decades to describe the one time delay change that is referred to in FR#12. I think we have been fairly clear about what "minimally disruptive" means today in practice. It means a "delay discontinuity" with zero packet loss. If the delay is reduced, then a brief period of reordering can occur, where the duration of the period of reordering is the difference in the delay (ie: typically a few milliseconds). Curtis In message Iftekhar Hussain writes: Curtis, I also think, it would be a good idea to indicate the consequences of such load balancing change (if this event is going to cause service disruption). FR#4 and FR#12 might be relevant. Regards, Iftekhar -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, May 24, 2012 2:33 PM To: Kireeti Kompella Cc: curtis@occnc.com; Iftekhar Hussain; rtgwg@ietf.org Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) In message Kireeti Kompella writes: > On May 24, 2012, at 10:56 , Curtis Villamizar wrote: > > > In the discussion of the CL framework, a suggestion was made to > > change the requirements. Please comment on this suggestion. > > > > The following would be added somewhere. > > > > Load balancing MAY be used during sustained low traffic periods to > > reduce the number of active component links for the purpose of power > > reduction. > > Is the intent: > > Load balancing MAY be _changed_ during sustained low traffic > periods to reduce the number of active component links ... > > ? > > If so, a warning ("this may result in some packets being reordered, > and a change in delay and jitter of some flows") should probably be > added. > > Kireeti. Kireeti, You are correct that any change would be minimally disruptive. In the example I gave there could be no more than one change in 20 minutes, but still more than zero. I personally don't think a warning is needed here, but if you and/or others feel it is needed I have no objections to adding it. The text would then be: [FR#N] Load balancing MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction. As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. The network operator when configuring a network for power reduction should weight the benefit of power reduction against the disadvantage of a minimal disruption. The first paragraph is a requirement. The second paragraph is discussion and should not appear within a numbered list of requirements. I would like comments from you and others. Do we need to add this requirement? If so do we need to add this warning? Curtis From jeff.tantsura@ericsson.com Fri Jun 1 14:29:52 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 801C421F889A for ; Fri, 1 Jun 2012 14:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 015wn+xCXBMs for ; Fri, 1 Jun 2012 14:29:52 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id AB12D21F87F3 for ; Fri, 1 Jun 2012 14:29:50 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q51LTkP3020734; Fri, 1 Jun 2012 16:29:47 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.31]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 1 Jun 2012 17:29:41 -0400 From: Jeff Tantsura To: John E Drake , Alia Atlas , "rtgwg@ietf.org" Date: Fri, 1 Jun 2012 17:29:39 -0400 Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0+hYWOV4jpzD3AQfWdIJeaBZ6DVwA23AtgADcmoqA= Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6218E43BD00@EUSAACMS0701.eamcs.ericsson.se> References: <5E893DB832F57341992548CDBB333163A578C238D5@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A578C238D5@EMBX01-HQ.jnpr.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 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 21:29:52 -0000 Hi Alia, Support for exactly these reasons. Regards, Jeff -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Thursday, May 31, 2012 12:27 PM To: Alia Atlas; rtgwg@ietf.org Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Alia, I support the WG adopting draft-shand-remote-lfa. It provides a straightfo= rward, low cost, and effective extension to LFAs. Thanks, John Sent from my iPhone >-----Original Message----- >From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf=20 >Of Alia Atlas >Sent: Wednesday, May 30, 2012 9:59 AM >To: rtgwg@ietf.org >Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft > >draft-shand-remote-lfa was presented favorably this last IETF. There=20 >is known IPR associated with it on file (=20 >https://datatracker.ietf.org/ipr/1770/ ) This draft presents a=20 >solution for IP/LDP fast-reroute that does not guarantee 100% coverage=20 >but can substantially improve coverage over LFAs. > >We would like to initiate a WG poll to determine whether to adopt=20 >draft- shand-remote-lfa. >We are, of course, interested in opinions and reasoning rather than=20 >simple yes/no. > >Thanks, >Alia >_______________________________________________ >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 Sat Jun 2 08:37:08 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 2FBB821F855E for ; Sat, 2 Jun 2012 08:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5EJiCwxQSjZ for ; Sat, 2 Jun 2012 08:37:07 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A0A9521F8523 for ; Sat, 2 Jun 2012 08:37:05 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-d7-4fca3320d71d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 97.68.00702.0233ACF4; Sat, 2 Jun 2012 17:37:04 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.227]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Sat, 2 Jun 2012 17:36:51 +0200 From: =?utf-8?B?QW5kcsOhcyBDc8Ohc3rDoXI=?= To: "stephane.litkowski@orange.com" , Alia Atlas , "rtgwg@ietf.org" Date: Sat, 2 Jun 2012 17:36:49 +0200 Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0+hYIIou84HfCjSlGKLgbxE3lNkwAcwfDQAAMBo0AAdCME0A== Message-ID: <8DCD771BDA4A394E9BCBA8932E839297783CFF1C7E@ESESSCMS0363.eemea.ericsson.se> References: <8DCD771BDA4A394E9BCBA8932E839297783CF647D0@ESESSCMS0363.eemea.ericsson.se> <31979_1338453231_4FC72CEF_31979_8499_3_4FC3556A36EE3646A09DAA60429F533508612770@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <31979_1338453231_4FC72CEF_31979_8499_3_4FC3556A36EE3646A09DAA60429F533508612770@PUEXCBL0.nanterre.francetelecom.fr> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvra6C8Sl/gyXTlSw+PbzEbHHhzW9m i697H7I6MHvsnHWX3WPJkp9MHi3PTrIFMEdx2aSk5mSWpRbp2yVwZdyd28RaMMO+YtbXhawN jCdsuxg5OSQETCT6NqxmgrDFJC7cW8/WxcjFISRwilGiaeotJghnAaPEtJlf2EGq2AQ8JO5f /8sMkhAR6GCUWDSxjbWLkYODRUBFYtbJFJAaYQFPifWHj7OB2CICXhLLtnxghrCdJLaeuA4W 5xUIlzgzbwIjxIKpTBLzL2wH28Yp0Mgo8WnbCrChjAKyEg/XWoA0MAuIS9x6Mh/qVAGJJXvO M0PYohIvH/9jBbEZBWQkPiw9xAbSyiygKbF+lz5Eq6LElO6H7BB7BSVOznzCMoFRdBaSqbMQ OmYh6ZiFpGMBI8sqRuHcxMyc9HJzvdSizOTi4vw8veLUTYzAuDm45bfBDsZN98UOMUpzsCiJ 8+qp7vcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJglqdQcV3LlQUtMrILC9cSZkxP+3XgX H9/Z9u689k2/3V9166cfnVTaf9WszfTUlfteWjrSngF3zs2r4ru8eIPe5wOyv797nLh+89wt p8WXCiKehdpVKCwwrmL4erbuyrZlZ0/f/7QsX9L3QXPQypeBzC+n5E7tuc2q6bMvRlDgu7K/ 9rrfGjFKLMUZiYZazEXFiQC4enICaQIAAA== 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: Sat, 02 Jun 2012 15:37:08 -0000 SGkgU3RlcGhhbmUgYW5kIEFsaWEsDQoNCkkgYWdyZWUgdGhhdCB0aGVzZSBjb25jZXJucyBjYW4g YmUgcmVtZWRpZWQsIGV2ZW4gZHVyaW5nIFdHIGRvYyBwaGFzZSwgYW5kIHRoZXJlIGFyZSByZXN1 bHRzIGFuZCBzb3VyY2VzIHRvIG1ha2UgaXQgcG9zc2libGUuDQoNCkFsc28sIGFzIHNvbWVvbmUg c2FpZCBhbHJlYWR5LCB0aGUgS0lTUyBiZWF1dHkgOi0pIG9mIHRoZSBzb2x1dGlvbiBhbnl3YXkg b3V0d2VpZ2hzIHRoZSBjb25jZXJucywgc28NCg0KSSBzdXBwb3J0IHRoZSBkb2MgdG8gYmVjb21l IGEgV0cgZG9jIGFuZCBldmVudHVhbGx5IGFuIFJGQy4NCg0KV2Ugc2hvdWxkIGNvbnNpZGVyIHBy b2JhYmx5IHdoYXQgdHJhY2ssIGJ1dCB0aGF0J3MgYW5vdGhlciBxdWVzdGlvbi4NCg0KQW5kcsOh cw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb20NCj4gW21haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNv bV0NCj4gU2VudDogMjAxMi4gbcOhanVzIDMxLiAxMDozMw0KPiBUbzogQW5kcsOhcyBDc8Ohc3rD oXI7IEFsaWEgQXRsYXM7IHJ0Z3dnQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBvcGluaW9ucyBv biBhZG9wdGlvbiBvZiBkcmFmdC1zaGFuZC1yZW1vdGUtbGZhIGFzIGEgV0cNCj4gZHJhZnQNCj4g DQo+IFNvbWUgZmVlZGJhY2sgOg0KPiANCj4gDQo+ID4gKEQpIFBvdGVudGlhbGx5IGJpZyBudW1i ZXIgb2YgdGFyZ2V0ZWQgTERQIHNlc3Npb25zDQo+IFtTTEldIEJhc2VkIG9uIG91ciBzaW11bGF0 aW9uLCBvbmx5IDQgVC1MRFAgc2Vzc2lvbnMgYXQgbWF4IGlzIG5lZWRlZA0KPiAoZm9yIG91ciBj YXNlKSwgMiBvciAxIG9ubHkgaW4gbW9zdCBjYXNlcy4gKG5vdyByb3V0ZXJzIGFyZSBhYmxlIHRv DQo+IGhhbmRsZSBodW5kcmVkcyBvZiBMRFAgc2Vzc2lvbnMgd2l0aG91dCBpc3N1ZSwgc28gYWRk aW5nIGZldyBpcyBub3QgYQ0KPiBiaWcgZGVhbCkNCj4gDQo+ID4gKEUpIEluYWJpbGl0eSB0byBw cm92aWRlIDEwMCUgY292ZXJhZ2Ugd2l0aCBhcmJpdHJhcnkgY29zdCBzdHJ1Y3R1cmUNCj4gW1NM SV0gV2hhdCBkbyB5b3UgbWVhbiBleGFjdGx5ID8gRG8geW91IG1lYW4gdGhhdCB3aXRoIHNvbWUg dG9wb2xvZ3ksDQo+IHlvdSBhcmUgdW5hYmxlIHRvIGhhdmUgMTAwJSBjb3ZlcmFnZSA/IFllcywg ZmV3IHRvcG9sb2dpZXMgY2FuJ3Qgd29yaw0KPiB3aXRoIHJMRkEgYXMgZm9yIExGQSAuLi4gQnV0 IGlzIGl0IHJlYWxseSBhbiBpc3N1ZSA/IEknbSBhbHdheXMgdHJ5aW5nDQo+IHRvIHNlZSBzaW1w bGljaXR5IHZzIGdhaW4gLi4uIEFzIHlvdSBtZW50aW9uIHJMRkEgaXMgc3RpbGwgYW4gZWFzeQ0K PiBtZWNoYW5pc20gKGFzIExGQSBpcyAuLi4pLCBpdCB3b3VsZCBwcm92aWRlIHlvdSBzdHJvbmcg Y292ZXJhZ2UNCj4gZXh0ZW5zaW9uLg0KPiBOb3RlIHRoYXQgYXMgYWxyZWFkeSBtZW50aW9ubmVk IGluIHRoZSBkcmFmdCAoYW5kIEknbSBjdXJyZW50bHkgd3JpdGluZw0KPiBzb21lIG1vcmUgZGV0 YWlsIHN0dWZmIG9uIHRoaXMpLCBpdCBpcyBzdGlsbCBwb3NzaWJsZSB0byBhY2hpZXZlIDEwMCUN Cj4gY292ZXJhZ2UgYnV0IHlvdSBzaG91bGQgYWRkIGV4cGxpY2l0IFRFIHR1bm5lbCAoaW1wbGVt ZW50YXRpb24gbWF5IGJlDQo+IGFibGUgdG8gcHJvcG9zZSB0byBlc3RhYmxpc2ggaXQgZHluYW1p Y2FsbHkgaWYgaXQgYmVjb21lcyBhIG5lZWQpLg0KPiANCj4gKEYpIFByZXNlbnRlZCBjb3ZlcmFn ZSB2YWx1ZXMgYXJlIG5vdCBmdWxseSBjb252aW5jaW5nIGR1ZSB0byBzZXZlcmFsDQo+IHJlYXNv bnMgKGlmIEkgd2FzIGp1c3QgbWlzc2luZyByZXN1bHRzLCB0aGVuIHNvcnJ5ISk6DQo+IA0KPiAg IChGMSkgT25seSByZWxhdGl2ZWx5IGRlbnNlIGNvcmUtbGlrZSB0b3BvbG9naWVzIGhhdmUgYmVl bg0KPiBpbnZlc3RpZ2F0ZWQsIHdoZXJlIExGQSBpcyBtb3N0bHkgZ29vZCBlbm91Z2ggYW55d2F5 LiBIb3dldmVyLCBJUC9NUExTDQo+IGlzIGdldHRpbmcgcHVzaGVkIHRvIHRoZSBhZ2dyZWdhdGlv bi9hY2Nlc3MsIHdoZXJlIHRoZSB0b3BvbG9neSBpcyBmYXINCj4gZnJvbSBiZWluZyB0aGF0IHNw YXJzZSwgdGhlcmUgQVJFIHJpbmdzIGFuZCB0aGVyZSBhcmUgKHNwYXJzZSkgdHJlZS1saWtlDQo+ IHRvcG9sb2dpZXMgd2hpY2ggYXJlIGV4dGVuZGVkIHdpdGggYSBmZXcgbGlua3MgaGVyZSBhbmQg dGhlcmUgdG8gYm9vc3QNCj4gcmVkdW5kYW5jeS4gSG93IGRvZXMgaXQgd29yayBpbiBzdWNoIHJl bGF0aXZlbHkgc3BhcnNlIHRvcG9zPw0KPiANCj4gW1NMSV0gSXQgaXMgYWxyZWFkeSBwbGFubmVk IGFzIGZhciBhcyBJIGtub3cgdG8gYWRkIG5ldyB1c2UgY2FzZXMgd2l0aGluDQo+IHRoZSBkb2Mu IEkgY2FuIGFscmVhZHkgc2F5IHRoYXQgckxGQSB3b3JrcyB2ZXJ5IHdlbGwgd2l0aCByaW5ncy4g V2UgaGF2ZQ0KPiBwbGVudHkgdmFyaWV0eSBvZiByaW5ncyB3aXRoIGRpZmZlcmVudCBtZXRyaWMg cGF0dGVybnMsIGRpZmZlcmVudCBzaXplDQo+IG9mIHJpbmcsIGFuZCBMRkEgcHJvdmlkZXMgMTAw JSBjb3ZlcmFnZSBpbiBhbGwgb2YgdGhlc2UgY2FzZXMNCj4gKGJpZGlyZWN0aW9uYWwpLg0KPiAN Cj4gDQo+ICAgKEYzKSBFdmVuIGlmIGFuIG9wZXJhdG9yIHR1bmVzIGl0cyB0b3BvIHRvIGhhdmUg aGlnaCBSTEZBIGNvdmVyYWdlLCBhDQo+IHRvcG8gY2hhbmdlIG1pZ2h0IHJ1aW4gaXQgKGUuZy4g ZmFpbHVyZXMsIGV0Yy4pLiBTbywgd2hhdCB3b3VsZCBiZSB2ZXJ5DQo+IHVzZWZ1bCBpcyB0byBz ZWUgbnVtYmVycyBvbiB2YXJpb3VzIHRvcG9sb2dpZXMgaG93IGEgaGlnaCBjb3ZlcmFnZSB2YWx1 ZQ0KPiBjaGFuZ2VzIHdpdGggYSBzbWFsbCBtb2RpZmljYXRpb24gb2YgdGhlIHRvcG9sb2d5IChl LmcuIG9uZSBvciB0d28NCj4gZmFpbHVyZXMuLi4pDQo+IA0KPiBbU0xJXSBUaGlzIGlzIGNsZWFy bHkgYSBnb29kIHBvaW50LCBJIHRoaW5rIG1vc3QgcGVvcGxlIGFyZSBhbHJlYWR5DQo+IGF3YXJl IG9mIChJIGhvcGUgOikgKSwgYXMgaXQgY29uY2VybnMgYWxyZWFkeSBMRkEgLi4uIElmIHlvdSBo YXZlIGEgZ29vZA0KPiBjb3ZlcmFnZSB3aXRoIHlvdXIgbm9taW5hbCB0b3BvLCBhIGJhY2t1cCB0 b3BvbG9neSBtYXkgbm90IGhhdmUgYSBnb29kDQo+IGNvdmVyYWdlIC4uLg0KPiANCj4gKEcpIEhh dmUgbm90IHlldCBzZWVuIHBhcGVycy9ndWlkZWxpbmVzIGhvdyB0byB0dW5lIHRoZSBuZXR3b3Jr IHRvIGJlDQo+IG1vcmUgUkxGQSBmcmllbmRseSAod2hpY2ggaXMgcG9zc2libGUsIHNlZSBlLmcu IChCKSkNCj4gDQo+IFtTTEldIHRoaXMgcG9pbnQgY291bGQgYmUgYWRkcmVzc2VkIGVhc2lseSAu Li4NCj4gDQo+IA0KPiANCj4gSSBkbyB1bmRlcnN0YW5kIHRoYXQgYWNjZXB0aW5nIGl0IGFzIGEg V0cgaXRlbSBzdGlsbCBsZWF2ZXMgdGhlDQo+IG9wcG9ydHVuaXR5IHRvIGFuc3dlciBzb21lIG9m IHRoZXNlIGNvbmNlcm5zLg0KPiBJZiB3ZSBhZG9wdCBpdCwgSSB0aGluayB3ZSBzaG91bGQgZ2l2 ZSBndWlkZWxpbmVzIG9uIHRoZSBSTEZBIGZyaWVuZGx5DQo+IHRvcG9sb2dpZXMgYW5kIGNvc3Qg c3RydWN0dXJlcy4NCj4gDQo+IFtTTEldIERvYWJsZSBlYXNpbHkgYW5kIG5lY2Vzc2FyeSA7KSAo SSBhbHJlYWR5IHRhbGtlZCBhYm91dCB0aGlzIHdpdGgNCj4gQ2xhcmVuY2UgRi4pDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogcnRnd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZg0KPiA+IE9mIEFsaWEgQXRsYXMNCj4gPiBTZW50OiAyMDEyLiBtw6FqdXMg MzAuIDE4OjU5DQo+ID4gVG86IHJ0Z3dnQGlldGYub3JnDQo+ID4gU3ViamVjdDogb3BpbmlvbnMg b24gYWRvcHRpb24gb2YgZHJhZnQtc2hhbmQtcmVtb3RlLWxmYSBhcyBhIFdHIGRyYWZ0DQo+ID4N Cj4gPiBkcmFmdC1zaGFuZC1yZW1vdGUtbGZhIHdhcyBwcmVzZW50ZWQgZmF2b3JhYmx5IHRoaXMg bGFzdCBJRVRGLiAgVGhlcmUNCj4gPiBpcyBrbm93biBJUFIgYXNzb2NpYXRlZCB3aXRoIGl0IG9u IGZpbGUgKA0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE3NzAvICkgIFRo aXMgZHJhZnQgcHJlc2VudHMgYQ0KPiA+IHNvbHV0aW9uIGZvciBJUC9MRFAgZmFzdC1yZXJvdXRl IHRoYXQgZG9lcyBub3QgZ3VhcmFudGVlIDEwMCUgY292ZXJhZ2UNCj4gPiBidXQgY2FuIHN1YnN0 YW50aWFsbHkgaW1wcm92ZSBjb3ZlcmFnZSBvdmVyIExGQXMuDQo+ID4NCj4gPiBXZSB3b3VsZCBs aWtlIHRvIGluaXRpYXRlIGEgV0cgcG9sbCB0byBkZXRlcm1pbmUgd2hldGhlciB0byBhZG9wdA0K PiA+IGRyYWZ0LSBzaGFuZC1yZW1vdGUtbGZhLg0KPiA+IFdlIGFyZSwgb2YgY291cnNlLCBpbnRl cmVzdGVkIGluIG9waW5pb25zIGFuZCByZWFzb25pbmcgcmF0aGVyIHRoYW4NCj4gPiBzaW1wbGUg eWVzL25vLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IEFsaWENCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHJ0Z3dnIG1haWxpbmcgbGlzdA0K PiA+IHJ0Z3dnQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGd3Zw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBydGd3ZyBtYWlsaW5nIGxpc3QNCj4gcnRnd2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zw0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g DQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucw0KPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywNCj4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXINCj4gZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzDQo+IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMNCj4gZCdhbHRlcmF0aW9uLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlDQo+IG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4gDQo+IFRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkDQo+ IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5v dCBiZQ0KPiBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u Lg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kDQo+IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvcg0KPiBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4NCg0K From curtis@occnc.com Sat Jun 2 20:26:40 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 7908711E8080 for ; Sat, 2 Jun 2012 20:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=-1.280, BAYES_50=0.001, J_CHICKENPOX_13=0.6, 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 CmoP2zMeAsdc for ; Sat, 2 Jun 2012 20:26:38 -0700 (PDT) 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 DE16F21F84A1 for ; Sat, 2 Jun 2012 20:26:37 -0700 (PDT) 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 q533QK1f035648; Sat, 2 Jun 2012 20:26:20 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206030326.q533QK1f035648@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: draft-ietf-rtgwg-cl-requirement-06-preview1 - part 1 - changes From: Curtis Villamizar Date: Sat, 02 Jun 2012 23:26:20 -0400 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: Sun, 03 Jun 2012 03:26:40 -0000 Hi RTGWG, Thanks to Iftekhar for detailed comments on CL Requirements. Thanks also to comments from Iftekhar on CL Framework and followup from Iftekhar and Kireeti that identified a new requirement. This is in three parts to keep within the 40K file size limit. Please respond to this email and use the others are reference files. This email is part 1. I've includes partial diffs of XML source below with some annotations. In the next email (part 2) I'll send the full diffs of the XML source. In the final email (part 3) I'll send the text file draft-ietf-rtgwg-cl-requirement-06-preview1.txt Please review the diffs. I will submit a new version of draft-ietf-rtgwg-cl-requirement aka Composite Link Requirements shortly if there are no comments or if comments are resolved quickly. Curtis Annotations to the diffs start with "===>". Note that XML comments have no impact on the generated text document and were used in the past as a way to pass notes amoung co-authors to look at changes. Index: draft-ietf-rtgwg-cl-requirement.xml =================================================================== RCS file: /home/cvs/CVS-occnc/customers/ietf/rtg-cl/draft-ietf-rtgwg-cl-requirement.xml,v retrieving revision 1.2 diff -u -w -r1.2 draft-ietf-rtgwg-cl-requirement.xml --- draft-ietf-rtgwg-cl-requirement.xml 30 Jan 2012 23:50:59 -0000 1.2 +++ draft-ietf-rtgwg-cl-requirement.xml 2 Jun 2012 22:37:04 -0000 ==> added some ENTITY definitions for use in the references. [...] @@ -47,14 +54,112 @@ - + docName="draft-ietf-rtgwg-cl-requirement-06-preview1"> @@ -123,39 +228,6 @@ </address> </author> ==> Removed commented out prior authors. Note that only five are allowed. Frederic and Yuji contributed to early versions of this document and are thanked in the acknowledgement section. - - -<!-- - <author - fullname="Frederic Jounay" initials="F." surname="Jounay"> - <organization>France Telecom</organization> - <address> - <postal> - <street>2, avenue Pierre-Marzin</street> - <code>22307</code> - <city>Lannion Cedex</city> - <country>France</country> - </postal> - <email>frederic.jounay@orange-ftgroup.com</email> - </address> - </author> - - <author - fullname="Yuji Kamite" initials="Y." surname="Kamite"> - <organization>NTT Communications Corporation</organization> - <address> - <postal> - <street>Granpark Tower</street> - <street>3-4-1 Shibaura, Minato-ku</street> - <city>Tokyo</city> - <code>108-8118</code> - <country>Japan</country> - </postal> - <email>y.kamite@ntt.com</email> - </address> - </author> - --> - <date day="30" month="January" year="2012" /> <!-- Meta-data Declarations --> ==> The change below is due to removing Appendix A and Appendix B and moving them to the CL Use Cases draft. This is as agreed to in the Quebec IETF. The citations (xref) changed from the appendices to the external document. @@ -207,14 +279,9 @@ functional requirements that are as independent as possible of protocol specifications (<xref target="FR" />). For certain functional requirements this document describes a set of - derived protocol requirements (<xref target="DR" />). Three - appendices provide supporting details as a summary of - existing/prior operator approaches (<xref - target="network-operator-practices" />), a summary of - implementation techniques and relevant protocol standards - (<xref target="multipath-bcp" />), and a summary of G.800 - terminology used to define a composite link (<xref - target="G.800-Definitions" />). + derived protocol requirements (<xref target="DR" />). <xref + target="G.800-Definitions" /> provides a summary of G.800 + terminology used to define a composite link. </t> <section title="Requirements Language"> ==> The change below addressed an outstanding comment from Tony Li asking for additional references. We cite MPLS Encaps, RSVP-TE base document, LDP, MPLS-TP Framework, and PW Framework. The abbreviations pt-pt, pt-mpt, and mpt-mpt appear no where else, so they are expanded. @@ -236,12 +303,14 @@ target="RFC4762">RFC 4762</xref>) and VPMS <xref target="I-D.ietf-l2vpn-vpms-frmwk-requirements">VPMS Framework</xref>), Internet traffic encapsulated by at least - one MPLS label, and dynamically signaled MPLS or MPLS-TP LSPs - and pseudowires. The MPLS LSPs supporting these services may - be pt-pt, pt-mpt, or mpt-mpt. + one MPLS label (<xref target="RFC3032">RFC 3032</xref>), and + dynamically signaled MPLS (<xref target="RFC3209">RFC + 3209</xref> or <xref target="RFC5036">RFC 5036</xref>) or + MPLS-TP LSPs (<xref target="RFC5921">RFC 5921</xref>) and + pseudowires (<xref target="RFC3985">RFC 3985</xref>). The MPLS + LSPs supporting these services may be point-to-point, + point-to-multipoint, or multipoint-to-multipoint. </t> - <!-- Tony Li Comment: Need many references here. Lucy provided - ones for services, do we need ones for signaled MPLS and MPLS-TP?--> <t> The locations in a network where these requirements apply are a Label Edge Router (LER) or a Label Switch Router (LSR) as ==> This is a comment that Dave added noting an objection to negative requirements. I'm fairly sure that we discussed this explicitly among authors and decided to keep it. Last chance to object before -06. @@ -252,8 +321,6 @@ requires Diffserv transparency (see <xref target="RFC4031">RFC 4031 5.5.2</xref>), and in general network operators do not rely on the DSCP of Internet packets. -<!-- DM: I recall that a comment from the list proposing deletion of - "negative" requirements. It is duplicated in Appendix A. --> </t> </section> ==> As indicated in the terse comment, this is item #1 from the list of action items that resulted from the mail from Iftekhar. For brevity I'll call this "Iftekhar's list". The request was to clarify physical link vs logical link. The lines starting with "+" contain the full new text. This is in the definition of "Component Link". @@ -280,23 +347,25 @@ is allowed. </t> <t hangText="Component Link:"> - A point-to-point physical or logical link that - preserves ordering in the steady state. A component - link may have transient out of order events, but such - events must not exceed the network's specific NPO. - Examples of a physical link are: Lambda, Ethernet PHY, - and OTN. Examples of a logical link are: MPLS LSP, - Ethernet VLAN, and MPLS-TP LSP. + A point-to-point physical link (including one or more + link layer) or a logical link that preserves ordering + in the steady state. A component link may have + transient out of order events, but such events must + not exceed the network's specific NPO. Examples of a + physical link are: any set of link layers over a WDM + wavelength or any supportable combination of Ethernet + PHY, PPP, SONET or OTN over a physical link. Examples + of a logical link are: MPLS LSP, Ethernet VLAN, + MPLS-TP LSP. A set of link layers supported over + pseudowire is a logical link that appears to the + client to be a physical link. + <!-- This is action item #1 --> </t> </list> </t> ==> I think at least among co-authors and to a lesser extent on list or at the meetings we beat the definition of flow to death. The comment reflecting distant past discussion was removed. <t hangText="Flow:"> A sequence of packets that must be transferred in order on one component link. -<!-- should we add "in order to maintain packet order"? DM: Reordering - is either not allowed or allowed subject to a specified frequency - in the requirements and stating only the first case as a - definition woud be inconsistent.--> </t> <t hangText="Flow identification:"> The label stack and other information that uniquely ==> The next two changes below change citations from an appendix moved to the CL Use Cases draft to a citation to the external document. @@ -311,7 +380,7 @@ <t hangText="Network Performance Objective (NPO):"> Numerical values for performance measures, principally availability, latency, and delay variation. See <xref - target="network-operator-practices" /> for more details. + target="I-D.symmvo-rtgwg-cl-use-cases" /> for more details. </t> </list> </t> @@ -331,7 +400,7 @@ service disrupting event and the convergence of the routing and/or signaling protocols MUST occur within a time frame specified by NPO values. - <xref target="network-operator-practices" /> provides + <xref target="I-D.symmvo-rtgwg-cl-use-cases" /> provides references and a summary of service types requiring a range of restoration times. <list counter="fr" hangIndent="4" style="format FR#%d"> ==> Removed two comments from Dave to other authors asking to look at his change. These comments are from the distant past. @@ -378,15 +447,19 @@ MUST be means to control the frequency of changing the component link over which a flow is placed. </t> -<!-- need to mention minimized reordering somewhere DM: OK Now?--> <t> Management and diagnostic protocols MUST be able to operate over composite links. </t> -<!-- if you mean MPLS-TP OAM, then please say so DM: This came from - NTT, I think scope is broader.--> </list> </t> ==> This is item #2 from "Iftekhar's list". The request was to add a reference to CL Framework where detailed discussion of scalability and stability can be found. That sort of discussion does not belong in CL Requirements, but this single paragraph may help. + <t> + Existing scaling techniques used in MPLS networks apply to + MPLS networks which support Composite Links. Scalability + and stability are covered in more detail in <xref + target="I-D.so-yong-rtgwg-cl-framework" />. + <!-- This is action item #2. --> + </t> </section> <section anchor="layering" title="Component Links Provided by Lower Layer ==> The requirement wording below didn't sit well with a few people for a lot of time but no one suggested new wording. Looking at a distant past email, I think the change below better reflects the intent. Last chance to object before -06. @@ -413,7 +486,9 @@ communicate latency to the higher layer client network. </t> <t> - The precision of latency reporting SHOULD be at least 10% + The precision of latency reporting SHOULD be + configurable. A reasonable default SHOULD be provided. + Implementations SHOULD support precision of at least 10% of the one way latencies for latency of 1 ms or more. </t> <t> ==> The change below was item #3 from "Iftekhar's list". The request was to add some information about what types of delays were considered, particularly queuing delay, and briefly give reasoning. This is not in the requirements list, but rather appears as a discussion paragraph after the requirements list that includes latency and jitter requirements. @@ -439,6 +514,18 @@ </t> </list> </t> + <t> + The intent is to measure the predominant latency in + uncongested service provider networks, where geographic + delay dominates and is on the order of milliseconds or more. + The argument for including queuing delay is that it reflects + the delay experienced by applications. The argument against + including queuing delay is that it if used in routing + decisions it can result in routing instability. This + tradeoff is discussed in detail in <xref + target="I-D.so-yong-rtgwg-cl-framework" />. + </t> + <!-- This is action item #3. --> </section> <section anchor="multipath-diff" title="Parallel Component Links with Different Characteristics"> ==> In the change below two big comment blocks are removed. These are discusion between myself and Dave from long ago that is resolved. Added after this is a new sentence that points the reader to CL Use Cases for descriptions of "existing techniques" and supporting references. This was item #4 on "Iftekhar's list". @@ -452,15 +539,12 @@ that connect the same pair of nodes. When the path for a flow can be chosen from a set of candidate nodes connected via composite links, other techniques have been developed. -<!-- The following sections break the requirements into three cases - determined by the connectivity of the component links: a) same - pair of nodes or sites, b) same pair of nodes only, c) component - links connecting multiple pairs of nodes in a pair of sites. --> -<!-- The set of case a, b, c above doesn't make sense. Case a seems - to be the superset of case b and c. If that is the intent, then - the text needs to be clear about it. DM: That was the idea, case - a applies to both b and c to reduce amount of text. Rewrote this - however. --> + Refer to the Appendices in <xref + target="I-D.symmvo-rtgwg-cl-use-cases" /> for a + description of existing techniques and a set of references. + <!-- This is action item #4. --> + </t> + <t> <list counter="fr" hangIndent="4" style="format FR#%d"> <t> The solution SHALL measure traffic on a labeled traffic ==> This is a deletion of discussion that was embedded in the requirements. That discussion was to a paragraph below the list of requirements, hopefully making it more clear that this discussion is a clarification about what "minimally disruptive" is intended to mean and not part of the requirements. @@ -473,21 +557,8 @@ When a traffic flow is moved from one component link to another in the same composite link between a set of nodes (or sites), it MUST be done so in a minimally - disruptive manner. <vspace blankLines="1" /> When a - flow is moved from a current link to a target link with - different latency, reordering can occur if the target - link latency is less than that of the current or - clumping can occur if target link latency is greater - than that of the current. Therefore, some flows (e.g., - timing distribution, PW circuit emulation) are quite - sensitive to these effects, which may be specified in an - NPO or are needed to meet a user experience objective - (e.g. jitter buffer under/overrun). - </t> -<!-- There are a few erros in the above paragraph. New delay greater - than old delay results in a gap. New delay less than old delay - results in reorder. It is not practical to put playback buffers - in the network core. DM: Good catch. OK Now? --> + disruptive manner. + </t> <t> The solution SHALL provide a means to identify flows whose rearrangement frequency needs to be bounded by a ==> Two stale comments, both long ago resolved, are now removed. @@ -500,7 +571,6 @@ means to indicate the flow identification field(s) which can be used along the flow path which can be used to perform this function. -<!-- does not parse - reword. makes sense but grammar error. DM: OK Now?--> </t> <t> The solution SHALL provide a means to indicate that a @@ -512,7 +582,6 @@ traffic flow shall select a component link with a maximum acceptable latency value as specified by protocol. -<!-- or a targer latency? DM: Same as Max acceptable from Ning?--> </t> <t> The solution SHALL provide a means to indicate that a ==> Below the discussion about what "minimally disruptive" means is added. As described in the annotation above, this was moved from within the list of requirements and placed after the list. The term "delay discontinuity" is used to explain the type of "minimally disruptive" that occurs with current techniques, for which there is no practical remedy. This expanded discussion is item #5 on "Iftekhar's list". @@ -558,6 +627,31 @@ </t> </list> </t> + <t> + A minimally disruptive change implies that as little + disruption as is practical occurs. Such a change can be + achieved with zero packet loss. A delay discontinuity may + occur, which is considered to be a minimally disruptive + event for most services if this type of event is + sufficiently rare. A delay discontinuity is an example of a + minimally disruptive behavior corresponding to current + techniques. + </t> + <t> + A delay discontinuity is an isolated event which may greatly + exceed the normal delay variation (jitter). A delay + discontinuity has the following effect. When a flow is + moved from a current link to a target link with lower + latency, reordering can occur. When a flow is moved from a + current link to a target link with a higher latency, a time + gap can occur. Some flows (e.g., timing distribution, PW + circuit emulation) are quite sensitive to these effects. A + delay discontinuity can also cause a jitter buffer underrun + or overrun affecting user experience in real time voice + services (causing an audible click). These sensitivities + may be specified in an NPO. + </t> + <!-- This is action item #5. --> </section> </section> ==> The entertaining comment below accompanies some discussion within a requirement that was commented out long ago. So far no one has missed that discussion. @@ -571,13 +665,6 @@ The solution SHOULD attempt to extend existing protocols wherever possible, developing a new protocol only if this adds a significant set of capabilities. -<!-- This is not a requirement. It is a religious manifesto - - <vspace blankLines="1" /> The vast majority of network - operators have provisioned L3VPN services over LDP. Many - have deployed L2VPN services over LDP as well. TE - extensions to IGP and RSVP-TE are viewed as being overly - complex by some operators. - --> </t> <t> A solution SHOULD extend LDP capabilities to meet ==> Erroneous capitalization down-cased. After that a stale comment is removed. @@ -601,7 +688,7 @@ rely on extensions to the IGP. </t> <t> - The Solution SHOULD support composite link IGP + The solution SHOULD support composite link IGP advertisement that results in convergence time better than that of advertising the individual component links. The solution SHALL be designed so that it represents the range @@ -624,7 +711,6 @@ duration of unavailability. The resignaling time of the solution MUST not increase significantly as compared with current methods. -<!-- Same here. Some rewording is needed. DM: Better now?--> </t> </list> </t> ==> This is item #6 on "Iftekhar's list". Somewhere we needed to say that the many statements that are worded in the form of "A solution MUST do the following" means that the implementation MUST support it, the implementation MUST make it optional and SHOULD in most cases disable it by default, and the provider MAY decide to enable it. This is added to the Management Requirements section. @@ -665,6 +751,17 @@ Management Plane SHOULD provide the means for an operator to initiate an optimization process. </t> + <t> + Any statement which requires the solution to support some + new functionality through use of the words new + functionality, SHOULD be interpretted as follows. The + implementation either MUST or SHOULD support the new + functionality depending on the use of either MUST or + SHOULD in the requirements statement. The implementation + SHOULD in most or all cases allow any new functionality to + be individually enabled or disabled through configuration. + </t> + <!-- This is item #6. --> </list> </t> ==> This is an addition to the Acknowledgements section. @@ -687,10 +784,15 @@ the RTGWG mailing list that are reflected in versions following the IETF77 meeting. </t> + <t> + Iftekhar Hussain and Kireeti Kompella made comments on the + RTGWG mailing list after IETF82 that identified a new + requirement. Iftekhar Hussain made numerous valuable comments + on the RTGWG mailing list that resulted in improvements to + document clarity. + </t> </section> - <!-- Possibly a 'Contributors' section ... --> - <section anchor="IANA" title="IANA Considerations"> <t>This memo includes no request to IANA.</t> </section> ==> Some references were added. So references with no citations in the document body were removed. @@ -727,20 +829,20 @@ <references title="Informative References"> [...] @@ -749,10 +851,16 @@ [...] @@ -769,57 +877,6 @@ </references> - <references title="Appendix References"> - <!-- add diffserv framework --> [...] - </references> ==> The last remnants of the two appendices that were moved to the Use Cases draft are now gone. - <section anchor="network-operator-practices" - title="Existing Network Operator Practices and Protocol Usage"> - - <t> - 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. - </t> - - </section> - - <section anchor="multipath-bcp" - title="Existing Multipath Standards and Techniques"> - - <t> - 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. - </t> - - </section> - <section anchor="G.800-Definitions" title="ITU-T G.800 Composite Link Definitions and Terminology"> <t> ==> A few more stale comments in the XML were removed. @@ -860,22 +917,17 @@ A set of one or more nodes (i.e., LER or LSR) and links. As a special case it can represent a site comprised of multiple nodes. -<!-- this should be listed as a special case of a subnet DM: OK? --> </t> <t hangText="Forwarding Relationship:"> Configured forwarding between ports on a subnetwork. It may be connectionless (e.g., IP, not considered in this draft), or connection oriented (e.g., MPLS signaled or configured). -<!-- conflict with prior statement that limits scope to MPLS with a CP - DM: OK now?--> </t> <t hangText="Component Link:"> A topolological relationship between subnetworks (i.e., a connection between nodes), which may be a wavelength, circuit, virtual circuit or an MPLS LSP. -<!-- do we really mean subnetwork here or site? DM: Site is special - case of subnet. If subnet, ECMP? DM: Question unclear. --> </t> </list> </t> From curtis@occnc.com Sat Jun 2 20:26:56 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ED111E8089 for <rtgwg@ietfa.amsl.com>; Sat, 2 Jun 2012 20:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 wR4p6XBwfgb0 for <rtgwg@ietfa.amsl.com>; Sat, 2 Jun 2012 20:26:54 -0700 (PDT) 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 80C0621F84A7 for <rtgwg@ietf.org>; Sat, 2 Jun 2012 20:26:53 -0700 (PDT) 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 q533QbgN035661; Sat, 2 Jun 2012 20:26:37 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206030326.q533QbgN035661@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: draft-ietf-rtgwg-cl-requirement-06-preview1 - part 2 - full diffs From: Curtis Villamizar <curtis@occnc.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <35656.1338693990.0@newharbor.ipv6.occnc.com> Date: Sat, 02 Jun 2012 23:26:37 -0400 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 03 Jun 2012 03:26:56 -0000 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35656.1338693990.1@newharbor.ipv6.occnc.com> This is part 2 of 3 parts. Please send responses as replies to part 1. ------- =_aaaaaaaaaa0 Content-Type: text/plain; filename="draft-ietf-rtgwg-cl-requirement.xml-diffs"; charset="us-ascii" Content-ID: <35656.1338693990.2@newharbor.ipv6.occnc.com> Index: draft-ietf-rtgwg-cl-requirement.xml =================================================================== RCS file: /home/cvs/CVS-occnc/customers/ietf/rtg-cl/draft-ietf-rtgwg-cl-requirement.xml,v retrieving revision 1.2 diff -u -w -r1.2 draft-ietf-rtgwg-cl-requirement.xml --- draft-ietf-rtgwg-cl-requirement.xml 30 Jan 2012 23:50:59 -0000 1.2 +++ draft-ietf-rtgwg-cl-requirement.xml 2 Jun 2012 22:37:04 -0000 @@ -14,9 +14,12 @@ <!ENTITY RFC2991 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2991.xml"> <!ENTITY RFC2992 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2992.xml"> <!ENTITY RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml"> + <!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml"> + <!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"> + <!ENTITY RFC3260 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3260.xml"> <!ENTITY RFC3468 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3468.xml"> <!ENTITY RFC3809 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3809.xml"> - <!ENTITY RFC3260 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3260.xml"> + <!ENTITY RFC3985 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3985.xml"> <!ENTITY RFC4031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4031.xml"> <!ENTITY RFC4201 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4201.xml"> <!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml"> @@ -28,11 +31,15 @@ <!ENTITY RFC4762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4762.xml"> <!ENTITY RFC4797 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4797.xml"> <!ENTITY RFC4928 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4928.xml"> + <!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml"> <!ENTITY RFC5254 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5254.xml"> + <!ENTITY RFC5921 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5921.xml"> -<!ENTITY I-D.ietf-pwe3-fat-pw SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pwe3-fat-pw-03.xml"> -<!ENTITY I-D.ietf-l2vpn-vpms-frmwk-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-l2vpn-vpms-frmwk-requirements-03.xml"> +<!ENTITY I-D.ietf-l2vpn-vpms-frmwk-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-l2vpn-vpms-frmwk-requirements-04"> +<!ENTITY I-D.symmvo-rtgwg-cl-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-symmvo-rtgwg-cl-use-cases-00"> + +<!ENTITY I-D.so-yong-rtgwg-cl-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-so-yong-rtgwg-cl-framework-05"> ]> @@ -47,14 +54,112 @@ <?rfc comments="yes"?> <?rfc inline="yes" ?> -<!-- we have lost some comments and some changes based on email message: +<!-- + + Recent changes in response to email. + + These email messages were very old but there was a comment in the + XML source that we may have missed chages from them. Two changes + result from these. + Message-ID: 201004110429.o3B4TEmM096179@harbor.orleans.occnc.com + + > FR: The precision of latency reporting should be at least 10% of + > the one way latency for latency of 1 ms or more. + + Can we just state that it be configurable and that the default be + ... [as stated]. + + [...] + + If you are considering keeping the text as is, then change "overload" + to something more meaningful, like maybe "congestion and queueing + delay" and make the last sentence a sentence (grammar doesn't parse). + + Message-ID: 793F49BA1FC821409F99F10862A0E4DB06827EA1@FHDP1LUMXCV14.us.one.verizon.com + + This email was a followup to the prior email. Most of the places + where changes were suggested could not be found in the current text. + + These are more recent emails. + + 05/06 Curtis Villamizar Re: Ref: Composite link drafts update and reques + Message-Id: <201205061602.q46G2JMW089507@gateway.ipv6.occnc.com> + + This was the last in a thread started by Iftekhar Hussain. These + were six action items identified. + + #1 Some rewording is needed in Section 3 to clarify MPLS based + component vs physical link component, the latter inclucing the + link layer. + + #2 Add a cross reference to CL framework in Section 4.1. + + #3 Add cross reference to CL framework near FR#8 and FR#9 regarding + delay metric granularity and inclusion of queuing delay and the + potential impacts on performance, oscillations, and stability. + + #4 Add a cross reference to CL Use Cases in Section 4.3 to point + toward the brief description and references that support the + statement "Many techniques have been developed to balance the + distribution of flows across component links that connect the + same pair of nodes" and "...via composite links, other + techniques have been developed." + + #5 Briefly explain the "delay discontinuity" that occurs when load + balancing puts traffic on a new path and clarify what is meant + by "minimally disruptive". + + #6 It may help in some cases to clarify that something must be + implemented but must, should, or may be configurable and + therefore may be optionally deployed. Doing so may require a + small change to many requirements as in most cases we have only + indicated where something must be implemented. + + 05/24 Curtis Villamizar change to requirements (was Re: draft-so-yong-rt + Message-Id: <201205241756.q4OHuqIV042399@gateway.ipv6.occnc.com> + + 05/24 Kireeti Kompella Re: change to requirements (was Re: draft-so-yon + Message-ID: <EE08A25D-CD59-4D8D-B573-19B059654099@juniper.net> + + 05/24 Kireeti Kompella Re: change to requirements (was Re: draft-so-yon + Message-ID: <E4124166-83DE-4748-8763-47EF4AA5AF17@juniper.net> + + 05/24 Curtis Villamizar Re: change to requirements (was Re: draft-so-yon + Message-Id: <201205241956.q4OJu4JF046481@gateway.ipv6.occnc.com> + + 05/24 Kireeti Kompella Re: change to requirements (was Re: draft-so-yon + Message-ID: <DFAB0F00-3794-48A3-99F7-7147CD246538@juniper.net> + + 05/24 Curtis Villamizar Re: change to requirements (was Re: draft-so-yon + Message-Id: <201205242133.q4OLXPg2049546@gateway.ipv6.occnc.com> + + 05/24 Iftekhar Hussain RE: change to requirements (was Re: draft-so-yon + Message-ID: <D7D7AB44C06A2440B716F1F1F5E70AE534655FF8@SV-EXDB-PROD1.infinera.com> + + 06/01 Curtis Villamizar Re: change to requirements (was Re: draft-so-yon + Message-Id: <201206011536.q51Fal7I082882@gateway.ipv6.occnc.com> + + The suggested text from these was: + + [FR#N] Load balancing MAY be used during sustained low traffic + periods to reduce the number of active component links for + the purpose of power reduction. + + As with any load balancing change, a change initiated for the + purpose of power reduction may be minimally disruptive. Typically + the disruption is limited to a change in delay characteristics and + the potential for a very brief period with traffic reordering. The + network operator when configuring a network for power reduction + should weight the benefit of power reduction against the + disadvantage of a minimal disruption. + --> <rfc category="info" ipr="trust200902" - docName="draft-ietf-rtgwg-cl-requirement-05"> + docName="draft-ietf-rtgwg-cl-requirement-06-preview1"> <front> <title abbrev="Composite Link Requirements"> @@ -123,39 +228,6 @@ </address> </author> - - -<!-- - <author - fullname="Frederic Jounay" initials="F." surname="Jounay"> - <organization>France Telecom</organization> - <address> - <postal> - <street>2, avenue Pierre-Marzin</street> - <code>22307</code> - <city>Lannion Cedex</city> - <country>France</country> - </postal> - <email>frederic.jounay@orange-ftgroup.com</email> - </address> - </author> - - <author - fullname="Yuji Kamite" initials="Y." surname="Kamite"> - <organization>NTT Communications Corporation</organization> - <address> - <postal> - <street>Granpark Tower</street> - <street>3-4-1 Shibaura, Minato-ku</street> - <city>Tokyo</city> - <code>108-8118</code> - <country>Japan</country> - </postal> - <email>y.kamite@ntt.com</email> - </address> - </author> - --> - <date day="30" month="January" year="2012" /> <!-- Meta-data Declarations --> @@ -207,14 +279,9 @@ functional requirements that are as independent as possible of protocol specifications (<xref target="FR" />). For certain functional requirements this document describes a set of - derived protocol requirements (<xref target="DR" />). Three - appendices provide supporting details as a summary of - existing/prior operator approaches (<xref - target="network-operator-practices" />), a summary of - implementation techniques and relevant protocol standards - (<xref target="multipath-bcp" />), and a summary of G.800 - terminology used to define a composite link (<xref - target="G.800-Definitions" />). + derived protocol requirements (<xref target="DR" />). <xref + target="G.800-Definitions" /> provides a summary of G.800 + terminology used to define a composite link. </t> <section title="Requirements Language"> @@ -236,12 +303,14 @@ target="RFC4762">RFC 4762</xref>) and VPMS <xref target="I-D.ietf-l2vpn-vpms-frmwk-requirements">VPMS Framework</xref>), Internet traffic encapsulated by at least - one MPLS label, and dynamically signaled MPLS or MPLS-TP LSPs - and pseudowires. The MPLS LSPs supporting these services may - be pt-pt, pt-mpt, or mpt-mpt. + one MPLS label (<xref target="RFC3032">RFC 3032</xref>), and + dynamically signaled MPLS (<xref target="RFC3209">RFC + 3209</xref> or <xref target="RFC5036">RFC 5036</xref>) or + MPLS-TP LSPs (<xref target="RFC5921">RFC 5921</xref>) and + pseudowires (<xref target="RFC3985">RFC 3985</xref>). The MPLS + LSPs supporting these services may be point-to-point, + point-to-multipoint, or multipoint-to-multipoint. </t> - <!-- Tony Li Comment: Need many references here. Lucy provided - ones for services, do we need ones for signaled MPLS and MPLS-TP?--> <t> The locations in a network where these requirements apply are a Label Edge Router (LER) or a Label Switch Router (LSR) as @@ -252,8 +321,6 @@ requires Diffserv transparency (see <xref target="RFC4031">RFC 4031 5.5.2</xref>), and in general network operators do not rely on the DSCP of Internet packets. -<!-- DM: I recall that a comment from the list proposing deletion of - "negative" requirements. It is duplicated in Appendix A. --> </t> </section> @@ -280,23 +347,25 @@ is allowed. </t> <t hangText="Component Link:"> - A point-to-point physical or logical link that - preserves ordering in the steady state. A component - link may have transient out of order events, but such - events must not exceed the network's specific NPO. - Examples of a physical link are: Lambda, Ethernet PHY, - and OTN. Examples of a logical link are: MPLS LSP, - Ethernet VLAN, and MPLS-TP LSP. + A point-to-point physical link (including one or more + link layer) or a logical link that preserves ordering + in the steady state. A component link may have + transient out of order events, but such events must + not exceed the network's specific NPO. Examples of a + physical link are: any set of link layers over a WDM + wavelength or any supportable combination of Ethernet + PHY, PPP, SONET or OTN over a physical link. Examples + of a logical link are: MPLS LSP, Ethernet VLAN, + MPLS-TP LSP. A set of link layers supported over + pseudowire is a logical link that appears to the + client to be a physical link. + <!-- This is action item #1 --> </t> </list> </t> <t hangText="Flow:"> A sequence of packets that must be transferred in order on one component link. -<!-- should we add "in order to maintain packet order"? DM: Reordering - is either not allowed or allowed subject to a specified frequency - in the requirements and stating only the first case as a - definition woud be inconsistent.--> </t> <t hangText="Flow identification:"> The label stack and other information that uniquely @@ -311,7 +380,7 @@ <t hangText="Network Performance Objective (NPO):"> Numerical values for performance measures, principally availability, latency, and delay variation. See <xref - target="network-operator-practices" /> for more details. + target="I-D.symmvo-rtgwg-cl-use-cases" /> for more details. </t> </list> </t> @@ -331,7 +400,7 @@ service disrupting event and the convergence of the routing and/or signaling protocols MUST occur within a time frame specified by NPO values. - <xref target="network-operator-practices" /> provides + <xref target="I-D.symmvo-rtgwg-cl-use-cases" /> provides references and a summary of service types requiring a range of restoration times. <list counter="fr" hangIndent="4" style="format FR#%d"> @@ -378,15 +447,19 @@ MUST be means to control the frequency of changing the component link over which a flow is placed. </t> -<!-- need to mention minimized reordering somewhere DM: OK Now?--> <t> Management and diagnostic protocols MUST be able to operate over composite links. </t> -<!-- if you mean MPLS-TP OAM, then please say so DM: This came from - NTT, I think scope is broader.--> </list> </t> + <t> + Existing scaling techniques used in MPLS networks apply to + MPLS networks which support Composite Links. Scalability + and stability are covered in more detail in <xref + target="I-D.so-yong-rtgwg-cl-framework" />. + <!-- This is action item #2. --> + </t> </section> <section anchor="layering" title="Component Links Provided by Lower Layer @@ -413,7 +486,9 @@ communicate latency to the higher layer client network. </t> <t> - The precision of latency reporting SHOULD be at least 10% + The precision of latency reporting SHOULD be + configurable. A reasonable default SHOULD be provided. + Implementations SHOULD support precision of at least 10% of the one way latencies for latency of 1 ms or more. </t> <t> @@ -439,6 +514,18 @@ </t> </list> </t> + <t> + The intent is to measure the predominant latency in + uncongested service provider networks, where geographic + delay dominates and is on the order of milliseconds or more. + The argument for including queuing delay is that it reflects + the delay experienced by applications. The argument against + including queuing delay is that it if used in routing + decisions it can result in routing instability. This + tradeoff is discussed in detail in <xref + target="I-D.so-yong-rtgwg-cl-framework" />. + </t> + <!-- This is action item #3. --> </section> <section anchor="multipath-diff" title="Parallel Component Links with Different Characteristics"> @@ -452,15 +539,12 @@ that connect the same pair of nodes. When the path for a flow can be chosen from a set of candidate nodes connected via composite links, other techniques have been developed. -<!-- The following sections break the requirements into three cases - determined by the connectivity of the component links: a) same - pair of nodes or sites, b) same pair of nodes only, c) component - links connecting multiple pairs of nodes in a pair of sites. --> -<!-- The set of case a, b, c above doesn't make sense. Case a seems - to be the superset of case b and c. If that is the intent, then - the text needs to be clear about it. DM: That was the idea, case - a applies to both b and c to reduce amount of text. Rewrote this - however. --> + Refer to the Appendices in <xref + target="I-D.symmvo-rtgwg-cl-use-cases" /> for a + description of existing techniques and a set of references. + <!-- This is action item #4. --> + </t> + <t> <list counter="fr" hangIndent="4" style="format FR#%d"> <t> The solution SHALL measure traffic on a labeled traffic @@ -473,21 +557,8 @@ When a traffic flow is moved from one component link to another in the same composite link between a set of nodes (or sites), it MUST be done so in a minimally - disruptive manner. <vspace blankLines="1" /> When a - flow is moved from a current link to a target link with - different latency, reordering can occur if the target - link latency is less than that of the current or - clumping can occur if target link latency is greater - than that of the current. Therefore, some flows (e.g., - timing distribution, PW circuit emulation) are quite - sensitive to these effects, which may be specified in an - NPO or are needed to meet a user experience objective - (e.g. jitter buffer under/overrun). - </t> -<!-- There are a few erros in the above paragraph. New delay greater - than old delay results in a gap. New delay less than old delay - results in reorder. It is not practical to put playback buffers - in the network core. DM: Good catch. OK Now? --> + disruptive manner. + </t> <t> The solution SHALL provide a means to identify flows whose rearrangement frequency needs to be bounded by a @@ -500,7 +571,6 @@ means to indicate the flow identification field(s) which can be used along the flow path which can be used to perform this function. -<!-- does not parse - reword. makes sense but grammar error. DM: OK Now?--> </t> <t> The solution SHALL provide a means to indicate that a @@ -512,7 +582,6 @@ traffic flow shall select a component link with a maximum acceptable latency value as specified by protocol. -<!-- or a targer latency? DM: Same as Max acceptable from Ning?--> </t> <t> The solution SHALL provide a means to indicate that a @@ -558,6 +627,31 @@ </t> </list> </t> + <t> + A minimally disruptive change implies that as little + disruption as is practical occurs. Such a change can be + achieved with zero packet loss. A delay discontinuity may + occur, which is considered to be a minimally disruptive + event for most services if this type of event is + sufficiently rare. A delay discontinuity is an example of a + minimally disruptive behavior corresponding to current + techniques. + </t> + <t> + A delay discontinuity is an isolated event which may greatly + exceed the normal delay variation (jitter). A delay + discontinuity has the following effect. When a flow is + moved from a current link to a target link with lower + latency, reordering can occur. When a flow is moved from a + current link to a target link with a higher latency, a time + gap can occur. Some flows (e.g., timing distribution, PW + circuit emulation) are quite sensitive to these effects. A + delay discontinuity can also cause a jitter buffer underrun + or overrun affecting user experience in real time voice + services (causing an audible click). These sensitivities + may be specified in an NPO. + </t> + <!-- This is action item #5. --> </section> </section> @@ -571,13 +665,6 @@ The solution SHOULD attempt to extend existing protocols wherever possible, developing a new protocol only if this adds a significant set of capabilities. -<!-- This is not a requirement. It is a religious manifesto - - <vspace blankLines="1" /> The vast majority of network - operators have provisioned L3VPN services over LDP. Many - have deployed L2VPN services over LDP as well. TE - extensions to IGP and RSVP-TE are viewed as being overly - complex by some operators. - --> </t> <t> A solution SHOULD extend LDP capabilities to meet @@ -601,7 +688,7 @@ rely on extensions to the IGP. </t> <t> - The Solution SHOULD support composite link IGP + The solution SHOULD support composite link IGP advertisement that results in convergence time better than that of advertising the individual component links. The solution SHALL be designed so that it represents the range @@ -624,7 +711,6 @@ duration of unavailability. The resignaling time of the solution MUST not increase significantly as compared with current methods. -<!-- Same here. Some rewording is needed. DM: Better now?--> </t> </list> </t> @@ -665,6 +751,17 @@ Management Plane SHOULD provide the means for an operator to initiate an optimization process. </t> + <t> + Any statement which requires the solution to support some + new functionality through use of the words new + functionality, SHOULD be interpretted as follows. The + implementation either MUST or SHOULD support the new + functionality depending on the use of either MUST or + SHOULD in the requirements statement. The implementation + SHOULD in most or all cases allow any new functionality to + be individually enabled or disabled through configuration. + </t> + <!-- This is item #6. --> </list> </t> @@ -687,10 +784,15 @@ the RTGWG mailing list that are reflected in versions following the IETF77 meeting. </t> + <t> + Iftekhar Hussain and Kireeti Kompella made comments on the + RTGWG mailing list after IETF82 that identified a new + requirement. Iftekhar Hussain made numerous valuable comments + on the RTGWG mailing list that resulted in improvements to + document clarity. + </t> </section> - <!-- Possibly a 'Contributors' section ... --> - <section anchor="IANA" title="IANA Considerations"> <t>This memo includes no request to IANA.</t> </section> @@ -727,20 +829,20 @@ <references title="Informative References"> - &RFC2702; - &RFC3031; + &RFC3032; + + &RFC3209; + &RFC3468; - &RFC3809; + &RFC3985; &RFC4031; &RFC4364; - &RFC4665; - &RFC4664; &RFC4761; @@ -749,10 +851,16 @@ &RFC4797; - &RFC5254; + &RFC5036; + + &RFC5921; &I-D.ietf-l2vpn-vpms-frmwk-requirements; + &I-D.symmvo-rtgwg-cl-use-cases; + + &I-D.so-yong-rtgwg-cl-framework; + <reference anchor="ITU-T.G.800" target="http://www.itu.int/rec/T-REC-G/recommendation.asp?parent=T-REC-G.800"> <front> @@ -769,57 +877,6 @@ </references> - <references title="Appendix References"> - <!-- add diffserv framework --> - - &RFC1717; - - &RFC2475; - - &RFC2615; - - &RFC2991; - - &RFC2992; - - &RFC3260; - - &RFC4201; - - &RFC4301; - - &RFC4385; - - &RFC4928; - - &I-D.ietf-pwe3-fat-pw; - - </references> - - <section anchor="network-operator-practices" - title="Existing Network Operator Practices and Protocol Usage"> - - <t> - 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. - </t> - - </section> - - <section anchor="multipath-bcp" - title="Existing Multipath Standards and Techniques"> - - <t> - 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. - </t> - - </section> - <section anchor="G.800-Definitions" title="ITU-T G.800 Composite Link Definitions and Terminology"> <t> @@ -860,22 +917,17 @@ A set of one or more nodes (i.e., LER or LSR) and links. As a special case it can represent a site comprised of multiple nodes. -<!-- this should be listed as a special case of a subnet DM: OK? --> </t> <t hangText="Forwarding Relationship:"> Configured forwarding between ports on a subnetwork. It may be connectionless (e.g., IP, not considered in this draft), or connection oriented (e.g., MPLS signaled or configured). -<!-- conflict with prior statement that limits scope to MPLS with a CP - DM: OK now?--> </t> <t hangText="Component Link:"> A topolological relationship between subnetworks (i.e., a connection between nodes), which may be a wavelength, circuit, virtual circuit or an MPLS LSP. -<!-- do we really mean subnetwork here or site? DM: Site is special - case of subnet. If subnet, ECMP? DM: Question unclear. --> </t> </list> </t> ------- =_aaaaaaaaaa0-- From curtis@occnc.com Sat Jun 2 21:24:05 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1850C11E808A for <rtgwg@ietfa.amsl.com>; Sat, 2 Jun 2012 21:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 0rWfxpZFOIGE for <rtgwg@ietfa.amsl.com>; Sat, 2 Jun 2012 21:24:03 -0700 (PDT) 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 28C9511E8089 for <rtgwg@ietf.org>; Sat, 2 Jun 2012 21:24:01 -0700 (PDT) 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 q533QsJX035673; Sat, 2 Jun 2012 20:26:54 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206030326.q533QsJX035673@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: draft-ietf-rtgwg-cl-requirement-06-preview1 - text file From: Curtis Villamizar <curtis@occnc.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <35671.1338694012.0@newharbor.ipv6.occnc.com> Date: Sat, 02 Jun 2012 23:26:53 -0400 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 03 Jun 2012 04:24:05 -0000 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35671.1338694012.1@newharbor.ipv6.occnc.com> This is part 3 of 3 parts. Please send responses as replies to part 1. ------- =_aaaaaaaaaa0 Content-Type: text/plain; filename="draft-ietf-rtgwg-cl-requirement-06-preview1.txt"; charset="us-ascii" Content-ID: <35671.1338694012.2@newharbor.ipv6.occnc.com> RTGWG C. Villamizar, Ed. Internet-Draft OCCNC, LLC Intended status: Informational D. McDysan, Ed. Expires: August 2, 2012 S. Ning A. Malis Verizon L. Yong Huawei USA January 30, 2012 Requirements for MPLS Over a Composite Link draft-ietf-rtgwg-cl-requirement-06-preview1 Abstract 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. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Villamizar, et al. Expires August 2, 2012 [Page 1] Internet-Draft Composite Link Requirements January 2012 This Internet-Draft will expire on August 2, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Villamizar, et al. Expires August 2, 2012 [Page 2] Internet-Draft Composite Link Requirements January 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Network Operator Functional Requirements . . . . . . . . . . . 5 4.1. Availability, Stability and Transient Response . . . . . . 5 4.2. Component Links Provided by Lower Layer Networks . . . . . 6 4.3. Parallel Component Links with Different Characteristics . 8 5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 10 6. Management Requirements . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. ITU-T G.800 Composite Link Definitions and Terminology . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Villamizar, et al. Expires August 2, 2012 [Page 3] Internet-Draft Composite Link Requirements January 2012 1. Introduction The purpose of this document is to describe why network operators require certain functions in order to solve certain business problems (Section 2). The intent is to first describe why things need to be done in terms of functional requirements that are as independent as possible of protocol specifications (Section 4). For certain functional requirements this document describes a set of derived protocol requirements (Section 5). Appendix A provides a summary of G.800 terminology used to define a composite link. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Assumptions The services supported include L3VPN RFC 4364 [RFC4364], RFC 4797 [RFC4797]L2VPN RFC 4664 [RFC4664] (VPWS, VPLS (RFC 4761 [RFC4761], RFC 4762 [RFC4762]) and VPMS VPMS Framework [I-D.ietf-l2vpn-vpms-frmwk-requirements]), Internet traffic encapsulated by at least one MPLS label (RFC 3032 [RFC3032]), and dynamically signaled MPLS (RFC 3209 [RFC3209] or RFC 5036 [RFC5036]) or MPLS-TP LSPs (RFC 5921 [RFC5921]) and pseudowires (RFC 3985 [RFC3985]). The MPLS LSPs supporting these services may be point-to- point, point-to-multipoint, or multipoint-to-multipoint. The locations in a network where these requirements apply are a Label Edge Router (LER) or a Label Switch Router (LSR) as defined in RFC 3031 [RFC3031]. The IP DSCP cannot be used for flow identification since L3VPN requires Diffserv transparency (see RFC 4031 5.5.2 [RFC4031]), and in general network operators do not rely on the DSCP of Internet packets. 3. Definitions ITU-T G.800 Based Composite and Component Link Definitions: Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite and component links as summarized in Appendix A. The following definitions for composite and component links are derived from and intended to be consistent with the cited ITU-T G.800 terminology. Villamizar, et al. Expires August 2, 2012 [Page 4] Internet-Draft Composite Link Requirements January 2012 Composite Link: A composite link is a logical link composed of a set of parallel point-to-point component links, where all links in the set share the same endpoints. A composite link may itself be a component of another composite link, but only a strict hierarchy of links is allowed. Component Link: A point-to-point physical link (including one or more link layer) or a logical link that preserves ordering in the steady state. A component link may have transient out of order events, but such events must not exceed the network's specific NPO. Examples of a physical link are: any set of link layers over a WDM wavelength or any supportable combination of Ethernet PHY, PPP, SONET or OTN over a physical link. Examples of a logical link are: MPLS LSP, Ethernet VLAN, MPLS-TP LSP. A set of link layers supported over pseudowire is a logical link that appears to the client to be a physical link. Flow: A sequence of packets that must be transferred in order on one component link. Flow identification: The label stack and other information that uniquely identifies a flow. Other information in flow identification may include an IP header, PW control word, Ethernet MAC address, etc. Note that an LSP may contain one or more Flows or an LSP may be equivalent to a Flow. Flow identification is used to locally select a component link, or a path through the network toward the destination. Network Performance Objective (NPO): Numerical values for performance measures, principally availability, latency, and delay variation. See [I-D.symmvo-rtgwg-cl-use-cases] for more details. 4. Network Operator Functional Requirements The Functional Requirements in this section are grouped in subsections starting with the highest priority. 4.1. Availability, Stability and Transient Response Limiting the period of unavailability in response to failures or transient events is extremely important as well as maintaining stability. The transient period between some service disrupting event and the convergence of the routing and/or signaling protocols MUST occur within a time frame specified by NPO values. [I-D.symmvo-rtgwg-cl-use-cases] provides references and a summary of Villamizar, et al. Expires August 2, 2012 [Page 5] Internet-Draft Composite Link Requirements January 2012 service types requiring a range of restoration times. FR#1 The solution SHALL provide a means to summarize some routing advertisements regarding the characteristics of a composite link such that the routing protocol converges within the timeframe needed to meet the network performance objective. A composite link CAN be announced in conjunction with detailed parameters about its component links, such as bandwidth and latency. The composite link SHALL behave as a single IGP adjacency. FR#2 The solution SHALL ensure that all possible restoration operations happen within the timeframe needed to meet the NPO. The solution may need to specify a means for aggregating signaling to meet this requirement. FR#3 The solution SHALL provide a mechanism to select a path for a flow across a network that contains a number of paths comprised of pairs of nodes connected by composite links in such a way as to automatically distribute the load over the network nodes connected by composite links while meeting all of the other mandatory requirements stated above. The solution SHOULD work in a manner similar to that of current networks without any composite link protocol enhancements when the characteristics of the individual component links are advertised. FR#4 If extensions to existing protocols are specified and/or new protocols are defined, then the solution SHOULD provide a means for a network operator to migrate an existing deployment in a minimally disruptive manner. FR#5 Any automatic LSP routing and/or load balancing solutions MUST not oscillate such that performance observed by users changes such that an NPO is violated. Since oscillation may cause reordering, there MUST be means to control the frequency of changing the component link over which a flow is placed. FR#6 Management and diagnostic protocols MUST be able to operate over composite links. Existing scaling techniques used in MPLS networks apply to MPLS networks which support Composite Links. Scalability and stability are covered in more detail in [I-D.so-yong-rtgwg-cl-framework]. 4.2. Component Links Provided by Lower Layer Networks Case 3 as defined in [ITU-T.G.800] involves a component link supporting an MPLS layer network over another lower layer network Villamizar, et al. Expires August 2, 2012 [Page 6] Internet-Draft Composite Link Requirements January 2012 (e.g., circuit switched or another MPLS network (e.g., MPLS-TP)). The lower layer network may change the latency (and/or other performance parameters) seen by the MPLS layer network. Network Operators have NPOs of which some components are based on performance parameters. Currently, there is no protocol for the lower layer network to inform the higher layer network of a change in a performance parameter. Communication of the latency performance parameter is a very important requirement. Communication of other performance parameters (e.g., delay variation) is desirable. FR#7 In order to support network NPOs and provide acceptable user experience, the solution SHALL specify a protocol means to allow a lower layer server network to communicate latency to the higher layer client network. FR#8 The precision of latency reporting SHOULD be configurable. A reasonable default SHOULD be provided. Implementations SHOULD support precision of at least 10% of the one way latencies for latency of 1 ms or more. FR#9 The solution SHALL provide a means to limit the latency on a per LSP basis between nodes within a network to meet an NPO target when the path between these nodes contains one or more pairs of nodes connected via a composite link. The NPOs differ across the services, and some services have different NPOs for different QoS classes, for example, one QoS class may have a much larger latency bound than another. Overload can occur which would violate an NPO parameter (e.g., loss) and some remedy to handle this case for a composite link is required. FR#10 If the total demand offered by traffic flows exceeds the capacity of the composite link, the solution SHOULD define a means to cause the LSPs for some traffic flows to move to some other point in the network that is not congested. These "preempted LSPs" may not be restored if there is no uncongested path in the network. The intent is to measure the predominant latency in uncongested service provider networks, where geographic delay dominates and is on the order of milliseconds or more. The argument for including queuing delay is that it reflects the delay experienced by applications. The argument against including queuing delay is that it if used in routing decisions it can result in routing instability. This tradeoff is discussed in detail in [I-D.so-yong-rtgwg-cl-framework]. Villamizar, et al. Expires August 2, 2012 [Page 7] Internet-Draft Composite Link Requirements January 2012 4.3. Parallel Component Links with Different Characteristics Corresponding to Case 1 of [ITU-T.G.800], as one means to provide high availability, network operators deploy a topology in the MPLS network using lower layer networks that have a certain degree of diversity at the lower layer(s). Many techniques have been developed to balance the distribution of flows across component links that connect the same pair of nodes. When the path for a flow can be chosen from a set of candidate nodes connected via composite links, other techniques have been developed. Refer to the Appendices in [I-D.symmvo-rtgwg-cl-use-cases] for a description of existing techniques and a set of references. FR#11 The solution SHALL measure traffic on a labeled traffic flow and dynamically select the component link on which to place this flow in order to balance the load so that no component link in the composite link between a pair of nodes is overloaded. FR#12 When a traffic flow is moved from one component link to another in the same composite link between a set of nodes (or sites), it MUST be done so in a minimally disruptive manner. FR#13 The solution SHALL provide a means to identify flows whose rearrangement frequency needs to be bounded by a configured value. FR#14 The solution SHALL provide a means that communicates whether the flows within an LSP can be split across multiple component links. The solution SHOULD provide a means to indicate the flow identification field(s) which can be used along the flow path which can be used to perform this function. FR#15 The solution SHALL provide a means to indicate that a traffic flow shall select a component link with the minimum latency value. FR#16 The solution SHALL provide a means to indicate that a traffic flow shall select a component link with a maximum acceptable latency value as specified by protocol. FR#17 The solution SHALL provide a means to indicate that a traffic flow shall select a component link with a maximum acceptable delay variation value as specified by protocol. Villamizar, et al. Expires August 2, 2012 [Page 8] Internet-Draft Composite Link Requirements January 2012 FR#18 The solution SHALL provide a means local to a node that automatically distributes flows across the component links in the composite link such that NPOs are met. FR#19 The solution SHALL provide a means to distribute flows from a single LSP across multiple component links to handle at least the case where the traffic carried in an LSP exceeds that of any component link in the composite link. As defined in section 3, a flow is a sequence of packets that must be transferred on one component link. FR#20 The solution SHOULD support the use case where a composite link itself is a component link for a higher order composite link. For example, a composite link comprised of MPLS-TP bi- directional tunnels viewed as logical links could then be used as a component link in yet another composite link that connects MPLS routers. FR#21 The solution MUST support an optional means for LSP signaling to bind an LSP to a particular component link within a composite link. If this option is not exercised, then an LSP that is bound to a composite link may be bound to any component link matching all other signaled requirements, and different directions of a bidirectional LSP can be bound to different component links. FR#22 The solution MUST support a means to indicate that both directions of co-routed bidirectional LSP MUST be bound to the same component link. A minimally disruptive change implies that as little disruption as is practical occurs. Such a change can be achieved with zero packet loss. A delay discontinuity may occur, which is considered to be a minimally disruptive event for most services if this type of event is sufficiently rare. A delay discontinuity is an example of a minimally disruptive behavior corresponding to current techniques. A delay discontinuity is an isolated event which may greatly exceed the normal delay variation (jitter). A delay discontinuity has the following effect. When a flow is moved from a current link to a target link with lower latency, reordering can occur. When a flow is moved from a current link to a target link with a higher latency, a time gap can occur. Some flows (e.g., timing distribution, PW circuit emulation) are quite sensitive to these effects. A delay discontinuity can also cause a jitter buffer underrun or overrun affecting user experience in real time voice services (causing an audible click). These sensitivities may be specified in an NPO. Villamizar, et al. Expires August 2, 2012 [Page 9] Internet-Draft Composite Link Requirements January 2012 5. Derived Requirements This section takes the next step and derives high-level requirements on protocol specification from the functional requirements. DR#1 The solution SHOULD attempt to extend existing protocols wherever possible, developing a new protocol only if this adds a significant set of capabilities. DR#2 A solution SHOULD extend LDP capabilities to meet functional requirements (without using TE methods as decided in [RFC3468]). DR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported on a composite link. Other functional requirements should be supported as independently of signaling protocol as possible. DR#4 When the nodes connected via a composite link are in the same MPLS network topology, the solution MAY define extensions to the IGP. DR#5 When the nodes are connected via a composite link are in different MPLS network topologies, the solution SHALL NOT rely on extensions to the IGP. DR#6 The solution SHOULD support composite link IGP advertisement that results in convergence time better than that of advertising the individual component links. The solution SHALL be designed so that it represents the range of capabilities of the individual component links such that functional requirements are met, and also minimizes the frequency of advertisement updates which may cause IGP convergence to occur. Examples of advertisement update triggering events to be considered include: LSP establishment/release, changes in component link characteristics (e.g., latency, up/down state), and/or bandwidth utilization. DR#7 When a worst case failure scenario occurs, the number of RSVP-TE LSPs to be resignaled will cause a period of unavailability as perceived by users. The resignaling time of the solution MUST meet the NPO objective for the duration of unavailability. The resignaling time of the solution MUST not increase significantly as compared with current methods. Villamizar, et al. Expires August 2, 2012 [Page 10] Internet-Draft Composite Link Requirements January 2012 6. Management Requirements MR#1 Management Plane MUST support polling of the status and configuration of a composite link and its individual composite link and support notification of status change. MR#2 Management Plane MUST be able to activate or de-activate any component link in a composite link in order to facilitate operation maintenance tasks. The routers at each end of a composite link MUST redistribute traffic to move traffic from a de-activated link to other component links based on the traffic flow TE criteria. MR#3 Management Plane MUST be able to configure a LSP over a composite link and be able to select a component link for the LSP. MR#4 Management Plane MUST be able to trace which component link a LSP is assigned to and monitor individual component link and composite link performance. MR#5 Management Plane MUST be able to verify connectivity over each individual component link within a composite link. MR#6 Management Plane SHOULD provide the means for an operator to initiate an optimization process. MR#7 Any statement which requires the solution to support some new functionality through use of the words new functionality, SHOULD be interpretted as follows. The implementation either MUST or SHOULD support the new functionality depending on the use of either MUST or SHOULD in the requirements statement. The implementation SHOULD in most or all cases allow any new functionality to be individually enabled or disabled through configuration. 7. Acknowledgements Frederic Jounay of France Telecom and Yuji Kamite of NTT Communications Corporation co-authored a version of this document. A rewrite of this document occurred after the IETF77 meeting. Dimitri Papadimitriou, Lou Berger, Tony Li, the WG chairs John Scuder and Alex Zinin, and others provided valuable guidance prior to and at the IETF77 RTGWG meeting. Tony Li and John Drake have made numerous valuable comments on the Villamizar, et al. Expires August 2, 2012 [Page 11] Internet-Draft Composite Link Requirements January 2012 RTGWG mailing list that are reflected in versions following the IETF77 meeting. Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG mailing list after IETF82 that identified a new requirement. Iftekhar Hussain made numerous valuable comments on the RTGWG mailing list that resulted in improvements to document clarity. 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations This document specifies a set of requirements. The requirements themselves do not pose a security threat. If these requirements are met using MPLS signaling as commonly practiced today with authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP, then the requirement to provide additional information in this communication presents additional information that could conceivably be gathered in a man-in-the-middle confidentiality breach. Such an attack would require a capability to monitor this signaling either through a provider breach or access to provider physical transmission infrastructure. A provider breach already poses a threat of numerous tpes of attacks which are of far more serious consequence. Encrption of the signaling can prevent or render more difficult any confidentiality breach that otherwise might occur by means of access to provider physical transmission infrastructure. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., and L. Jin, "Framework and Requirements for Virtual Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms-frmwk-requirements-04 (work in progress), July 2011. Villamizar, et al. Expires August 2, 2012 [Page 12] Internet-Draft Composite Link Requirements January 2012 [I-D.so-yong-rtgwg-cl-framework] So, N., McDysan, D., Osborne, E., Yong, L., and C. Villamizar, "Composite Link Framework in Multi Protocol Label Switching (MPLS)", draft-so-yong-rtgwg-cl-framework-05 (work in progress), March 2012. [I-D.symmvo-rtgwg-cl-use-cases] Malis, A., Villamizar, C., McDysan, D., Yong, L., and N. So, "Composite Link USe Cases and Design Considerations", draft-symmvo-rtgwg-cl-use-cases-00 (work in progress), February 2012. [ITU-T.G.800] ITU-T, "Unified functional architecture of transport networks", 2007, <http://www.itu.int/rec/T-REC-G/ recommendation.asp?parent=T-REC-G.800>. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", Villamizar, et al. Expires August 2, 2012 [Page 13] Internet-Draft Composite Link Requirements January 2012 RFC 4761, January 2007. [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [RFC4797] Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks", RFC 4797, January 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. Appendix A. ITU-T G.800 Composite Link Definitions and Terminology Composite Link: Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite link in terms of three cases, of which the following two are relevant (the one describing inverse (TDM) multiplexing does not apply). Note that these case definitions are taken verbatim from section 6.9, "Layer Relationships". Case 1: "Multiple parallel links between the same subnetworks can be bundled together into a single composite link. Each component of the composite link is independent in the sense that each component link is supported by a separate server layer trail. The composite link conveys communication information using different server layer trails thus the sequence of symbols crossing this link may not be preserved. This is illustrated in Figure 14." Case 3: "A link can also be constructed by a concatenation of component links and configured channel forwarding relationships. The forwarding relationships must have a 1:1 correspondence to the link connections that will be provided by the client link. In this case, it is not possible to fully infer the status of the link by observing the server layer trails visible at the ends of the link. This is illustrated in Figure 16." Villamizar, et al. Expires August 2, 2012 [Page 14] Internet-Draft Composite Link Requirements January 2012 Subnetwork: A set of one or more nodes (i.e., LER or LSR) and links. As a special case it can represent a site comprised of multiple nodes. Forwarding Relationship: Configured forwarding between ports on a subnetwork. It may be connectionless (e.g., IP, not considered in this draft), or connection oriented (e.g., MPLS signaled or configured). Component Link: A topolological relationship between subnetworks (i.e., a connection between nodes), which may be a wavelength, circuit, virtual circuit or an MPLS LSP. Authors' Addresses Curtis Villamizar (editor) OCCNC, LLC Email: curtis@occnc.com Dave McDysan (editor) Verizon 22001 Loudoun County PKWY Ashburn, VA 20147 Email: dave.mcdysan@verizon.com So Ning Verizon 2400 N. Glenville Ave. Richardson, TX 75082 Phone: +1 972-729-7905 Email: ning.so@verizonbusiness.com Andrew Malis Verizon 117 West St. Waltham, MA 02451 Phone: +1 781-466-2362 Email: andrew.g.malis@verizon.com Villamizar, et al. Expires August 2, 2012 [Page 15] Internet-Draft Composite Link Requirements January 2012 Lucy Yong Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 469-229-5387 Email: lucyyong@huawei.com Villamizar, et al. Expires August 2, 2012 [Page 16] ------- =_aaaaaaaaaa0-- From curtis@occnc.com Sun Jun 3 08:28:32 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F35621F8642 for <rtgwg@ietfa.amsl.com>; Sun, 3 Jun 2012 08:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.475, 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 k6piExqBFQws for <rtgwg@ietfa.amsl.com>; Sun, 3 Jun 2012 08:28:31 -0700 (PDT) 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 7A4AB21F8639 for <rtgwg@ietf.org>; Sun, 3 Jun 2012 08:28:31 -0700 (PDT) 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 q53FSQfD063701; Sun, 3 Jun 2012 08:28:26 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206031528.q53FSQfD063701@gateway.ipv6.occnc.com> To: curtis@occnc.com From: Curtis Villamizar <curtis@occnc.com> Subject: Re: draft-ietf-rtgwg-cl-requirement-06-preview1 - part 1 - changes In-reply-to: Your message of "Sat, 02 Jun 2012 23:26:20 EDT." <201206030326.q533QK1f035648@gateway.ipv6.occnc.com> Date: Sun, 03 Jun 2012 11:28:26 -0400 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 03 Jun 2012 15:28:32 -0000 In message <201206030326.q533QK1f035648@gateway.ipv6.occnc.com> Curtis Villamizar writes: > > Hi RTGWG, > > Thanks to Iftekhar for detailed comments on CL Requirements. Thanks > also to comments from Iftekhar on CL Framework and followup from > Iftekhar and Kireeti that identified a new requirement. And Lucy Yong was in on this discussion. > This is in three parts to keep within the 40K file size limit. Please > respond to this email and use the others are reference files. > > This email is part 1. I've includes partial diffs of XML source below > with some annotations. > > In the next email (part 2) I'll send the full diffs of the XML source. > > In the final email (part 3) I'll send the text file > draft-ietf-rtgwg-cl-requirement-06-preview1.txt > > Please review the diffs. I will submit a new version of > draft-ietf-rtgwg-cl-requirement aka Composite Link Requirements > shortly if there are no comments or if comments are resolved quickly. > > Curtis > > > > [ ... annotated diffs deleted ... ] Oops - missed something. We should acknowledge John Scudder, Alex Zinin, Papadimitriou Dimitri, Lou Berger, Alia Atlas, John Drake, and Eric Osborne for valuable comments. In the interest of full disclosure of affiliation --- Ning So's affiliation needs to change. IMHO Verizon should be acknowledged for support of Ning's work while at Verizon. Infinera would like to be acknowledged for their support of my work while at Infinera and continued support. Small diffs for these later. Curtis From ietf-ipr@ietf.org Tue Jun 5 10:32:06 2012 Return-Path: <ietf-ipr@ietf.org> 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 8034C21F87C0; Tue, 5 Jun 2012 10:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 BmGOQ34AnPWr; Tue, 5 Jun 2012 10:32:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54E221F86DA; Tue, 5 Jun 2012 10:32:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat <ietf-ipr@ietf.org> To: stbryant@cisco.com, sprevidi@cisco.com, imc.shand@googlemail.com Subject: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-rtgwg-ipfrr-notvia-addresses-08 X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120605173205.5927.76457.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2012 10:32:05 -0700 Cc: adrian@olddog.co.uk, stbryant@cisco.com, ipr-announce@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 05 Jun 2012 17:32:06 -0000 Dear Stewart Bryant, Stefano Previdi, Mike Shand: An IPR disclosure that pertains to your Internet-Draft entitled "IP Fast Reroute Using Not-via Addresses" (draft-ietf-rtgwg-ipfrr-notvia-addresses) = was submitted to the IETF Secretariat on 2012-06-04 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1794/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-rtgwg-ipfrr-notvia- addresses-08.""); The IETF Secretariat From internet-drafts@ietf.org Thu Jun 7 04:26:14 2012 Return-Path: <internet-drafts@ietf.org> 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 8995221F8655; Thu, 7 Jun 2012 04:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 3Gq1xKmsUX6p; Thu, 7 Jun 2012 04:26:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181C721F8638; Thu, 7 Jun 2012 04:26:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-cl-requirement-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120607112614.1429.88416.idtracker@ietfa.amsl.com> Date: Thu, 07 Jun 2012 04:26:14 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Jun 2012 11:26:14 -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-06.txt Pages : 16 Date : 2012-06-07 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-06.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-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement/ From curtis@occnc.com Thu Jun 7 04:57:32 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1419E21F87ED for <rtgwg@ietfa.amsl.com>; Thu, 7 Jun 2012 04:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.422, 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 CCY8zxd9f6bv for <rtgwg@ietfa.amsl.com>; Thu, 7 Jun 2012 04:57:31 -0700 (PDT) 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 72C1721F87BA for <rtgwg@ietf.org>; Thu, 7 Jun 2012 04:57:31 -0700 (PDT) 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 q57BvRuD087992; Thu, 7 Jun 2012 04:57:27 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206071157.q57BvRuD087992@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: draft-ietf-rtgwg-cl-requirement-06 submitted From: Curtis Villamizar <curtis@occnc.com> Date: Thu, 07 Jun 2012 07:57:27 -0400 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Jun 2012 11:57:32 -0000 Hi RTGWG, draft-ietf-rtgwg-cl-requirement-06 has just been submitted. Diffs to the XML were sent last week. There were no comments on the diffs. The updated document can be found in datatracker at http://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement/ Diffs to the text versions are available through datatracker at http://tools.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-cl-requirement-06 Review and comments would be appreciated. Thanks, Curtis From luayjalil@gmail.com Thu Jun 7 07:16:16 2012 Return-Path: <luayjalil@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A31E21F886C for <rtgwg@ietfa.amsl.com>; Thu, 7 Jun 2012 07:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 Te3FRTa-MEnP for <rtgwg@ietfa.amsl.com>; Thu, 7 Jun 2012 07:16:15 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B997F21F8868 for <rtgwg@ietf.org>; Thu, 7 Jun 2012 07:16:15 -0700 (PDT) Received: by qadz3 with SMTP id z3so151427qad.10 for <rtgwg@ietf.org>; Thu, 07 Jun 2012 07:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-cmae-score:x-cmae-analysis:message-id:to:from:subject:date :mime-version:content-type:user-agent; bh=0IbW5SsqFvI9ozhAk9VNM7faHqsgzfwqG8BG2IXACsM=; b=EVFzz876AiWIkRA4TPtL5pzjwgcP7dW6BdEqvMpMhYTl7KQCl+YEysC5a29Ct+phoP M73/EC4eWgfQnCAksHL7x0mrGoa7yfBDFzmaa54+lXGV7PrtCRNvfPiN3LUHlGYVkICb 94wcADxX1X5j0YEdI1C/l38V3KRbQ+j/nxZLS8Fu5w2rt+7Krz2SCGnXYXyQDMvFrch9 EQV3JQ//6xOngVkifaqQCm93sgk29YwsrbhmHHxRDPDh1V7qBDUy2Z+UZO+eff9vVE8o E/6VveeBTEkyOGLstjszsATCuvbfUZdr2mFI6MV9cHkYXcxkc5kAaXQb6w243RcaUU+q ufBw== Received: by 10.229.136.66 with SMTP id q2mr735900qct.50.1339078574982; Thu, 07 Jun 2012 07:16:14 -0700 (PDT) Received: from njbbicssmp04 (110.sub-69-78-135.myvzw.com. [69.78.135.110]) by mx.google.com with ESMTPS id dx8sm5803920qab.8.2012.06.07.07.16.13 (version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 07:16:13 -0700 (PDT) Received: from njbbicsomta04.myvzw.com ([10.134.210.103]) by njbbicssmp04 (JAMES SMTP Server 2.3.2) with SMTP ID 458; Thu, 7 Jun 2012 13:48:24 +0000 (GMT) Received: from [192.168.1.6] (76-204-214-34.lightspeed.allntx.sbcglobal.net [76.204.214.34]) by njbbicsomta04.myvzw.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPA id <0M59006K83MWY330@njbbicsomta04.myvzw.com>; Thu, 07 Jun 2012 14:16:11 +0000 (GMT) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=2MFGQAtar7MmnNJmZ9sQexttbrj8x1+AgHO6zUAUpRU= c=1 sm=1 a=Fa9zI0Tad0gA:10 a=nDghuxUhq_wA:10 a=jPJDawAOAc8A:10 a=TgB1bJ5ZGPVNraaR4OStpg==:17 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=e0tJjt9K_DhxMT5N28IA:9 a=QEXdDO2ut3YA:10 a=No1GZX0i5u0A:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=C55DUchRcOywj57JJU0A:9 a=fSkjX58JhMQA:10 a=TgB1bJ5ZGPVNraaR4OStpg==:117 Message-id: <869969197.129269.1339076904798.JavaMail.webspher@njbbicssmp04> To: =?utf-8?B?QWxpYSBBdGxhcw==?= <akatlas@gmail.com>, rtgwg@ietf.org From: =?utf-8?B?bHVheWphbGlsQGdtYWlsLmNvbQ==?= <luayjalil@gmail.com> Subject: =?utf-8?B?UmU6IG9waW5pb25zIG9uIGFkb3B0aW9uIG9mIGRyYWZ0LXNoYW5kLXJlbW90ZS1s?= =?utf-8?B?ZmEgYXMgYSBXRyBkcmFmdA==?= Date: Thu, 07 Jun 2012 09:16:10 -0500 MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_Part_0_1339078570705" User-Agent: ICS X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Jun 2012 14:16:16 -0000 ------=_Part_0_1339078570705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U3VwcG9ydAoKTHVheQoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiQWxpYSBBdGxh cyIgPGFrYXRsYXNAZ21haWwuY29tPgpUbzogPHJ0Z3dnQGlldGYub3JnPgpTdWJqZWN0OiBvcGlu aW9ucyBvbiBhZG9wdGlvbiBvZiBkcmFmdC1zaGFuZC1yZW1vdGUtbGZhIGFzIGEgV0cgZHJhZnQK RGF0ZTogV2VkLCBNYXkgMzAsIDIwMTIgMTE6NTggYW0KCgpkcmFmdC1zaGFuZC1yZW1vdGUtbGZh IHdhcyBwcmVzZW50ZWQgZmF2b3JhYmx5IHRoaXMgbGFzdCBJRVRGLiAgVGhlcmUKaXMga25vd24g SVBSCmFzc29jaWF0ZWQgd2l0aCBpdCBvbiBmaWxlICggaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9pcHIvMTc3MC8gKQogVGhpcyBkcmFmdCBwcmVzZW50cwphIHNvbHV0aW9uIGZvciBJUC9M RFAgZmFzdC1yZXJvdXRlIHRoYXQgZG9lcyBub3QgZ3VhcmFudGVlIDEwMCUKY292ZXJhZ2UgYnV0 IGNhbiBzdWJzdGFudGlhbGx5CmltcHJvdmUgY292ZXJhZ2Ugb3ZlciBMRkFzLgoKV2Ugd291bGQg bGlrZSB0byBpbml0aWF0ZSBhIFdHIHBvbGwgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdG8gYWRvcHQK ZHJhZnQtc2hhbmQtcmVtb3RlLWxmYS4KV2UgYXJlLCBvZiBjb3Vyc2UsIGludGVyZXN0ZWQgaW4g b3BpbmlvbnMgYW5kIHJlYXNvbmluZyByYXRoZXIgdGhhbgpzaW1wbGUgeWVzL25vLgoKVGhhbmtz LApBbGlhCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnJ0 Z3dnIG1haWxpbmcgbGlzdApydGd3Z0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Z3dnCg== ------=_Part_0_1339078570705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U3VwcG9ydDxicj48YnI+THVheTxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5G cm9tOiAmcXVvdDtBbGlhIEF0bGFzJnF1b3Q7ICZsdDtha2F0bGFzQGdtYWlsLmNvbSZndDs8YnI+ VG86ICZsdDtydGd3Z0BpZXRmLm9yZyZndDs8YnI+U3ViamVjdDogb3BpbmlvbnMgb24gYWRvcHRp b24gb2YgZHJhZnQtc2hhbmQtcmVtb3RlLWxmYSBhcyBhIFdHIGRyYWZ0PGJyPkRhdGU6IFdlZCwg TWF5IDMwLCAyMDEyIDExOjU4IGFtPGJyPjxicj48YnI+ZHJhZnQtc2hhbmQtcmVtb3RlLWxmYSB3 YXMgcHJlc2VudGVkIGZhdm9yYWJseSB0aGlzIGxhc3QgSUVURi4gJm5ic3A7VGhlcmU8YnI+aXMg a25vd24gSVBSPGJyPmFzc29jaWF0ZWQgd2l0aCBpdCBvbiBmaWxlICggaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9pcHIvMTc3MC8gKTxicj4gVGhpcyBkcmFmdCBwcmVzZW50czxicj5hIHNv bHV0aW9uIGZvciBJUC9MRFAgZmFzdC1yZXJvdXRlIHRoYXQgZG9lcyBub3QgZ3VhcmFudGVlIDEw MCU8YnI+Y292ZXJhZ2UgYnV0IGNhbiBzdWJzdGFudGlhbGx5PGJyPmltcHJvdmUgY292ZXJhZ2Ug b3ZlciBMRkFzLjxicj48YnI+V2Ugd291bGQgbGlrZSB0byBpbml0aWF0ZSBhIFdHIHBvbGwgdG8g ZGV0ZXJtaW5lIHdoZXRoZXIgdG8gYWRvcHQ8YnI+ZHJhZnQtc2hhbmQtcmVtb3RlLWxmYS48YnI+ V2UgYXJlLCBvZiBjb3Vyc2UsIGludGVyZXN0ZWQgaW4gb3BpbmlvbnMgYW5kIHJlYXNvbmluZyBy YXRoZXIgdGhhbjxicj5zaW1wbGUgeWVzL25vLjxicj48YnI+VGhhbmtzLDxicj5BbGlhPGJyPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPnJ0Z3dnIG1h aWxpbmcgbGlzdDxicj5ydGd3Z0BpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Z3dnPGJyPg== ------=_Part_0_1339078570705-- From ju1738@att.com Fri Jun 8 06:52:59 2012 Return-Path: <ju1738@att.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BA021F86D0 for <rtgwg@ietfa.amsl.com>; Fri, 8 Jun 2012 06:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.862 X-Spam-Level: X-Spam-Status: No, score=-105.862 tagged_above=-999 required=5 tests=[AWL=0.736, 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 6OZtcaOP8WC4 for <rtgwg@ietfa.amsl.com>; Fri, 8 Jun 2012 06:52:59 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id D7D1821F86BA for <rtgwg@ietf.org>; Fri, 8 Jun 2012 06:52:58 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id ab302df4.0.1849801.00-192.5120101.nbfkord-smmo07.seg.att.com (envelope-from <ju1738@att.com>); Fri, 08 Jun 2012 13:52:58 +0000 (UTC) X-MXL-Hash: 4fd203ba4f91eb5e-bdcd4ec33914a3ac5a4bad71e383e945f2513db5 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q58Dqvru014061 for <rtgwg@ietf.org>; Fri, 8 Jun 2012 06:52:57 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q58DqoTQ013978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <rtgwg@ietf.org>; Fri, 8 Jun 2012 06:52:53 -0700 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by fflint04.pst.cso.att.com (RSA Interceptor) for <rtgwg@ietf.org>; Fri, 8 Jun 2012 06:52:29 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0355.002; Fri, 8 Jun 2012 09:52:29 -0400 From: "UTTARO, JAMES" <ju1738@att.com> To: "'rtgwg@ietf.org'" <rtgwg@ietf.org> Subject: adoption of draft-shand-remote-lfa as a WG draft Thread-Topic: adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac1FffG1gwhjRVisTUOb69Orf5kVig== Date: Fri, 8 Jun 2012 13:52:29 +0000 Message-ID: <B17A6910EEDD1F45980687268941550FAFE315@MISOUT7MSGUSR9I.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.141.253] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FAFE315MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: <ju1738@att.com> X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=ugEe1kqlDI0A:10 a=cHMR1rA3rowA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=n6BG1uw5fT9qu1Bd9bIA:9 a=CjuIK1q_8ugA:10 a=] X-AnalysisOut: [yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=Ozeu4TI_qKdhAs21wW4A:9 a] X-AnalysisOut: [=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10] X-Mailman-Approved-At: Fri, 08 Jun 2012 09:16:02 -0700 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 08 Jun 2012 13:53:00 -0000 --_000_B17A6910EEDD1F45980687268941550FAFE315MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Jim Uttaro >draft-shand-remote-lfa was presented favorably this last IETF. There is known IPR associated with it on file ( https://datatracker.ietf.org/ipr/1770/ ) This draft presents a solution for IP/LDP fast-reroute that does not guarantee 100% coverage but can substantially improve coverage over LFAs. We would like to initiate a WG poll to determine whether to adopt draft-shand-remote-lfa. We are, of course, interested in opinions and reasoning rather than simple yes/no. Thanks, Alia --_000_B17A6910EEDD1F45980687268941550FAFE315MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <pre>Support<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Jim Uttaro<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre>>draft-shand-remote-lfa was presented favorably this last IETF.&nbs= p; There<o:p></o:p></pre> <pre>is known IPR<o:p></o:p></pre> <pre>associated with it on file ( <a href=3D"https://datatracker.ietf.org/i= pr/1770/">https://datatracker.ietf.org/ipr/1770/</a> )<o:p></o:p></pre> <pre> This draft presents<o:p></o:p></pre> <pre>a solution for IP/LDP fast-reroute that does not guarantee 100%<o:p></= o:p></pre> <pre>coverage but can substantially<o:p></o:p></pre> <pre>improve coverage over LFAs.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>We would like to initiate a WG poll to determine whether to adopt<o:p>= </o:p></pre> <pre>draft-shand-remote-lfa.<o:p></o:p></pre> <pre>We are, of course, interested in opinions and reasoning rather than<o:= p></o:p></pre> <pre>simple yes/no.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Thanks,<o:p></o:p></pre> <pre>Alia<o:p></o:p></pre> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_B17A6910EEDD1F45980687268941550FAFE315MISOUT7MSGUSR9IIT_-- From internet-drafts@ietf.org Sat Jun 9 10:17:26 2012 Return-Path: <internet-drafts@ietf.org> 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 14B7121F87FE; Sat, 9 Jun 2012 10:17:26 -0700 (PDT) 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 p4UuIIxkJ1DH; Sat, 9 Jun 2012 10:17:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F53921F87F3; Sat, 9 Jun 2012 10:17:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-ipfrr-notvia-addresses-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120609171725.31927.73675.idtracker@ietfa.amsl.com> Date: Sat, 09 Jun 2012 10:17:25 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 09 Jun 2012 17:17:26 -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 : IP Fast Reroute Using Not-via Addresses Author(s) : Stewart Bryant Stefano Previdi Mike Shand Filename : draft-ietf-rtgwg-ipfrr-notvia-addresses-09.txt Pages : 32 Date : 2012-06-09 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= -09.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-ipfrr-notvia-addresses-= 09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ipfrr-notvia-addresses/ From ningso@yahoo.com Sat Jun 9 12:19:48 2012 Return-Path: <ningso@yahoo.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F1521F8517 for <rtgwg@ietfa.amsl.com>; Sat, 9 Jun 2012 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z78kTSioe+6b for <rtgwg@ietfa.amsl.com>; Sat, 9 Jun 2012 12:19:47 -0700 (PDT) Received: from nm30.bullet.mail.ac4.yahoo.com (nm30.bullet.mail.ac4.yahoo.com [98.139.52.227]) by ietfa.amsl.com (Postfix) with SMTP id 806B021F850D for <rtgwg@ietf.org>; Sat, 9 Jun 2012 12:19:47 -0700 (PDT) Received: from [98.139.52.195] by nm30.bullet.mail.ac4.yahoo.com with NNFMP; 09 Jun 2012 19:19:44 -0000 Received: from [68.142.200.226] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 09 Jun 2012 19:19:44 -0000 Received: from [66.94.237.114] by t7.bullet.mud.yahoo.com with NNFMP; 09 Jun 2012 19:19:44 -0000 Received: from [127.0.0.1] by omp1019.access.mail.mud.yahoo.com with NNFMP; 09 Jun 2012 19:19:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 505629.81459.bm@omp1019.access.mail.mud.yahoo.com Received: (qmail 56651 invoked by uid 60001); 9 Jun 2012 19:19:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1339269584; bh=WAT+JwEqPN4u7zuiKJpEGbad+bColtKZ8duUm8SRkXk=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=cA/Sr3ucF6Wd93+ClDU5m1zBOn+yV00OaUn3/MS2r0l/d9edLd957RTNJ/Eme0uox3oVF4qRihnaZsfsBtP0n9ZWZTHlfur1t82ZyHobVszqBbiP6neJls/7utg9wxZ0X4BL8mE6/VVbC6VWwUTbk3xp1H/1iMM7cvJMqHaedQQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=wa+M5fCg4XqboYSCVumCr3RA7SWirHfQIyrhGQpw6Ja+BQtCTkITrmrWg6WZ1ZVQG8FemLaXhaqnOWfDCZ9NjbD3IcTKDRvSY1HOW+pjQIexl+iGsL6+lT1k6FLMPdwTbmZ+0k5/rsUQ8M0sMGPem1qFEM3qT5sk0Zg8fOdVmhs=; X-YMail-OSG: OPL6aEYVM1k40ABTIMKCUk5_.CcKJyivR3jTScSLlhSV9V4 3U8OnbzHE8W3XEuJqZGKzi0iz2zv5j992jm3JNPQvsz3mM6jNLHU0Hw78bO9 pNeHvhdwxadIPzHMpwvXiNrmjAv6EZg6ayEBK..mRgy97J.cWM3gxWc5sQ68 SY1V8GjhPgZSdRRZJjJAndi_KOTa8._2AH6AyU2bvoxGbWqtF6Pq1i.yjczX jj4NQV8oKrqFKHHFuiAcnG3KJkmuYucEcz0S935oGfn7BeweSGtBYdXKyv8C HM9yBz24j.TSd3EAlY5D5bc0WoyqPXONQfQWDJ8Xm6kh3cmMla_hAy.hD7PH Xqx6bMXXCPrk0sVUepR4.OkrJAdfhGqMh5Id_Z3HcnhbyoAVc3IqfE4.xlq. htf5gD2qVl1m6UbD.JFOokn1.AqJfqSIiEKYuhJk2Br54EqYG0XZvqjIyD92 rcI82.aEFm_6Ng0.vKwP2PWDZWr8JcrKov9f_CllaVXK5NBrOTE0rFn.TeTx KswOkLqIRu8j8N3WhWcWyeDCzXkzbTScrqlXu5pXfrd1cs3U- Received: from [173.57.97.155] by web84509.mail.ne1.yahoo.com via HTTP; Sat, 09 Jun 2012 12:19:44 PDT X-Mailer: YahooMailWebService/0.8.118.349524 Message-ID: <1339269584.29037.YahooMailNeo@web84509.mail.ne1.yahoo.com> Date: Sat, 9 Jun 2012 12:19:44 -0700 (PDT) From: Ning So <ningso@yahoo.com> Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft To: "rtgwg@ietf.org" <rtgwg@ietf.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-215069597-810821570-1339269584=:29037" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ning So <ningso@yahoo.com> List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 09 Jun 2012 19:19:48 -0000 ---215069597-810821570-1339269584=:29037 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Support as co-author.=0A=0ANing So=0A=0A=0A---- Reply message -----=0AFrom:= "Alia Atlas" <akatlas at gmail.com>=0ATo: <rtgwg at ietf.org>=0ASubject: o= pinions on adoption of draft-shand-remote-lfa as a WG draft=0ADate: Wed, Ma= y 30, 2012 11:58 am=0A=0A=0Adraft-shand-remote-lfa was presented favorably = this last IETF. =A0There=0Ais known IPR=0Aassociated with it on file ( http= s://datatracker.ietf.org/ipr/1770/ )=0AThis draft presents=0Aa solution for= IP/LDP fast-reroute that does not guarantee 100%=0Acoverage but can substa= ntially=0Aimprove coverage over LFAs.=0A=0AWe would like to initiate a WG p= oll to determine whether to adopt=0Adraft-shand-remote-lfa.=0AWe are, of co= urse, interested in opinions and reasoning rather than=0Asimple yes/no.=0A= =0AThanks,=0AAlia=0A_______________________________________________=0Artgwg= mailing list=0Artgwg at ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/r= tgwg ---215069597-810821570-1339269584=:29037 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt"><div>Support as co-au= thor.</div><div><br></div><div>Ning So</div><div><br></div><div><br></div><= div>---- Reply message -----<br>From: "Alia Atlas" <akatlas at gmail.com= ><br>To: <rtgwg at ietf.org><br>Subject: opinions on adoption of d= raft-shand-remote-lfa as a WG draft<br>Date: Wed, May 30, 2012 11:58 am<br>= <br><br>draft-shand-remote-lfa was presented favorably this last IETF. &nbs= p;There<br>is known IPR<br>associated with it on file ( https://datatracker= .ietf.org/ipr/1770/ )<br> This draft presents<br>a solution for IP/LDP fast= -reroute that does not guarantee 100%<br>coverage but can substantially<br>= improve coverage over LFAs.<br><br>We would like to initiate a WG poll to d= etermine whether to adopt<br>draft-shand-remote-lfa.<br>We are, of course, = interested in opinions and reasoning rather than<br>simple yes/no.<br><br>Thanks,<br>Alia<br>________________________________________= _______<br>rtgwg mailing list<br>rtgwg at ietf.org<br>https://www.ietf.org/= mailman/listinfo/rtgwg</div></div></body></html> ---215069597-810821570-1339269584=:29037-- From internet-drafts@ietf.org Sun Jun 10 14:54:14 2012 Return-Path: <internet-drafts@ietf.org> 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 B327B21F84E7; Sun, 10 Jun 2012 14:54:14 -0700 (PDT) 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 4nnB5xePV3pF; Sun, 10 Jun 2012 14:54:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECD121F84B3; Sun, 10 Jun 2012 14:54:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-ordered-fib-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120610215414.3542.50070.idtracker@ietfa.amsl.com> Date: Sun, 10 Jun 2012 14:54:14 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 10 Jun 2012 21:54:14 -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 : Loop-free convergence using oFIB Author(s) : Mike Shand Stewart Bryant Stefano Previdi Clarence Filsfils Pierre Francois Olivier Bonaventure Filename : draft-ietf-rtgwg-ordered-fib-06.txt Pages : 26 Date : 2012-06-10 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 URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-ordered-fib-06.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-ordered-fib-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib/ From wwwrun@rfc-editor.org Mon Jun 11 15:47:47 2012 Return-Path: <wwwrun@rfc-editor.org> 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 1848611E8093; Mon, 11 Jun 2012 15:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocpwNhutgL2p; Mon, 11 Jun 2012 15:47:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 55DA811E808F; Mon, 11 Jun 2012 15:47:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 31EBAB1E005; Mon, 11 Jun 2012 15:47:37 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6571 on Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks From: rfc-editor@rfc-editor.org Message-Id: <20120611224737.31EBAB1E005@rfc-editor.org> Date: Mon, 11 Jun 2012 15:47:37 -0700 (PDT) Cc: rtgwg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 11 Jun 2012 22:47:47 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6571 Title: Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks Author: C. Filsfils, Ed., P. Francois, Ed., M. Shand, B. Decraene, J. Uttaro, N. Leymann, M. Horneffer Status: Informational Stream: IETF Date: June 2012 Mailbox: cf@cisco.com, pierre.francois@imdea.org, imc.shand@googlemail.com, bruno.decraene@orange.com, uttaro@att.com, N.Leymann@telekom.de, Martin.Horneffer@telekom.de Pages: 35 Characters: 71363 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rtgwg-lfa-applicability-06.txt URL: http://www.rfc-editor.org/rfc/rfc6571.txt In this document, we analyze the applicability of the Loop-Free Alternate (LFA) method of providing IP fast reroute in both the core and access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Routing Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From akatlas@gmail.com Tue Jun 12 13:34:07 2012 Return-Path: <akatlas@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA0221F864C for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 13:34:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaXa1hUxnnBc for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 13:34:07 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE4B321F863D for <rtgwg@ietf.org>; Tue, 12 Jun 2012 13:34:06 -0700 (PDT) Received: by yenq13 with SMTP id q13so4446918yen.31 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 13:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0BRBqcFdzgbU4oaHmG3vtXHpxCIzW08KcOjusytwkaU=; b=KyqzbJ1w3CMEzsSY21u2mFv3+nn0/T2T2v2QaoTJmb+V7pDs6e/1OoWdutSMJ4psAA Ri+4GQlCHyaQCm96OPSPkSTwF0XyWS+4mv5QAfzeM2KhS/03Q3NTDQOGhgCQUPmxvlbP AL4h0Hqe+ixiC7HkZIublpaPUlImFiE3UaOAwk+X1wl7DLpH0hZ5xcgg31IVUvl90VtZ CApxqan2QmahpPHSBYn8Ldb9ZRcIgvloOkiLBe/pXmeprE+fHz1uSRRUrvIQeuk9DQkj kxf17J3FLI+4k9V/2AIivtzmoNwJLCHXat3bhpLaAwRybBLSz7cswvW6RWd/64v99HZS TTGQ== MIME-Version: 1.0 Received: by 10.50.178.102 with SMTP id cx6mr9377049igc.14.1339533246410; Tue, 12 Jun 2012 13:34:06 -0700 (PDT) Received: by 10.50.19.67 with HTTP; Tue, 12 Jun 2012 13:34:05 -0700 (PDT) Date: Tue, 12 Jun 2012 16:34:05 -0400 Message-ID: <CAG4d1rdVNx=uMKUD_MsrtSc0nkpxuKpP0bgqKuo2QhiP4=3bGg@mail.gmail.com> Subject: draft-shand-remote-lfa adopted as WG draft From: Alia Atlas <akatlas@gmail.com> To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Jun 2012 20:34:07 -0000 >From the discussion and poll on the list, it is clear that there is good support for adopting draft-shand-remote-lfa as an RTGWG draft. There was also very good feedback about the need for further details on the applicability and coverage of this method - as it pertains to node protection, prefix protection, and two-way traffic protection. Authors, could you please republish the current version of draft-shand-remote-lfa as draft-ietf-rtgwg-remote-lfa-00 and then update the draft to respond to the feedback? Thanks, Alia From akatlas@gmail.com Tue Jun 12 13:36:38 2012 Return-Path: <akatlas@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C66811E8072 for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 13:36:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVKOVazZC5su for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 13:36:37 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1E521F86B5 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 13:36:37 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4444740ghb.31 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 13:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=siSIFOymKeqhPAxa2YTFmqIgZ42lPwhWIIMnfN6ZYno=; b=MvPTZ0nc3LdLcNAOm7JVEVA1EPbkQCjHPsU20Mp4VLdPGzaw77M/8epyt97fVoI4zE dWLXjEy1Rse+1ainAlgycwb8qhlRy4BSsseFraPaByxFcdoynrh4AFLEo31QIRa+JbaJ NgGbMih+R+B4P8cJbUXZjy30nh5w+wGWEEP/ROD11roQtCqNJNHNO+nnCoqRR3wnLzjP ggZ6L5UnaP1lbWK+ulIGaUfjihT8OOOC6E+rbITT1W8SRAhkpY1LyLqx+FTwdkP0ePxr JDmXX1q2MbGZNyr1NLtmazRozw/tFxHV9/zBMUKDxgp4Gi5N20F7xDsi3aYlM2GBXi0M HdTw== MIME-Version: 1.0 Received: by 10.50.157.136 with SMTP id wm8mr9374695igb.14.1339533396424; Tue, 12 Jun 2012 13:36:36 -0700 (PDT) Received: by 10.50.19.67 with HTTP; Tue, 12 Jun 2012 13:36:36 -0700 (PDT) Date: Tue, 12 Jun 2012 16:36:36 -0400 Message-ID: <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> Subject: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft From: Alia Atlas <akatlas@gmail.com> To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Jun 2012 20:36:38 -0000 This is to start a poll and discussion about whether RTGWG should adopt draft-symmvo-rtgwg-cl-use-cases-00 as a WG draft. Please respond with comments and reasoning and if you have read the draft. At our last meeting, very few people indicated that they had read the draft. Authors, please indicate in email whether there is any IPR associated with the draft. Thanks, Alia From akatlas@gmail.com Tue Jun 12 13:39:21 2012 Return-Path: <akatlas@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B144311E8095 for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 13:39:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL+Xm+Hf8mjp for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 13:39:21 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 28A2911E8088 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 13:39:21 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4463603ggn.31 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 13:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XhNfqrxbN5tGrGK0BSKUVQwoWUXmQTtriNqBRkGpqBI=; b=wQZ6mw/G0mzEMIU+2ITy3brCS7WYmfImu2YFUsVQ7HMAzD/3XuoR7jU+IVokkQvsBR 5felbhYg2I6p0gblMEJf7i2PqdKSelONkgfYwsSrvHU5NNZUzef1aUDWIuguM1cNHoG7 hv2VpH8HEn5daTY21XWCP09ge7I7QmyC6QXkFuLh5Fw9g/3VHtjxlz0iHkH/mRv43MvV AyiLB3TLkxZe01tQQ0viTiPCcd0iiqCHY+S9uLTfOozzW3yBkLYitSMOZ6ofDGnapHaL lJkWtOkzSzGkWEs7tuinZMfg8vQdHFb6xaa21Obe/tdZQzAV+YHo4+he4L/vc1uIbEZU axRw== MIME-Version: 1.0 Received: by 10.50.171.40 with SMTP id ar8mr9414187igc.14.1339533560280; Tue, 12 Jun 2012 13:39:20 -0700 (PDT) Received: by 10.50.19.67 with HTTP; Tue, 12 Jun 2012 13:39:20 -0700 (PDT) Date: Tue, 12 Jun 2012 16:39:20 -0400 Message-ID: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> Subject: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft From: Alia Atlas <akatlas@gmail.com> To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Jun 2012 20:39:21 -0000 This email is to start a poll and discussion on whether to adopt draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft. Please respond with opinions, comments, and whether you have read the draft. Last IETF, there were very few people who had read the draft. Authors, please indicate if there is any IPR associated with this draft. Thanks, Alia From akatlas@gmail.com Tue Jun 12 13:41:54 2012 Return-Path: <akatlas@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328FE11E80B5 for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 13:41:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrVGfCaS5o5V for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 13:41:53 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48B8411E80AC for <rtgwg@ietf.org>; Tue, 12 Jun 2012 13:41:44 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4465862ggn.31 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 13:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UsD2zAYo/fM3uZ28glJ7mTMKURr2h/r0yjkG0hfGlnI=; b=ENRBzG1xpypv7xGjAqrXDXnIaCKYA+VMpTHhzvpAd7esOjjVsF6O+tqEqMKXwuQGBE ZTdeNpvRk5tPPcreX2i7em5Ijojoa9iJU04RLdex89pfVcSt7Djl6GQU6ulYAv4Tgwm4 F+uiPVZIQ/SBCuUHPWiOBpBkognBRNIv6gyK0LLuuPcI13m7XkbGGiTvw5wvla2z0oVk DlbdzO1auljoUQjvXXEKPSRHX27O4JsNzz31G/7+YiTpEn7NKAWnaNhVNyZvXhDOl1NE B7m+o7XOW02xkdSRHzt7DKJdMOgFq+Z1nZQ3Fh4jcy2kMfaSUhlTula0gal/kbpydbk7 /qMQ== MIME-Version: 1.0 Received: by 10.50.94.228 with SMTP id df4mr9370244igb.34.1339533703883; Tue, 12 Jun 2012 13:41:43 -0700 (PDT) Received: by 10.50.19.67 with HTTP; Tue, 12 Jun 2012 13:41:43 -0700 (PDT) Date: Tue, 12 Jun 2012 16:41:43 -0400 Message-ID: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> Subject: poll on draft-karan-mofrr-02 to become a WG draft From: Alia Atlas <akatlas@gmail.com> To: rtgwg@ietf.org, pim-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Jun 2012 20:41:54 -0000 This email is to start a poll and discussion on whether draft-karan-mofrr-02 should become an RTGWG draft. Please include comments, details, and whether you have read the draft. The earlier version was presented positively to the PIM WG as well. Authors, please indicate whether there is any IPR associated with this draft. Thanks, Alia From internet-drafts@ietf.org Tue Jun 12 13:58:16 2012 Return-Path: <internet-drafts@ietf.org> 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 3A56711E80D1; Tue, 12 Jun 2012 13:58:16 -0700 (PDT) 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=[AWL=0.000, 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 TD79srT9j+Nm; Tue, 12 Jun 2012 13:58:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FAA21F86DF; Tue, 12 Jun 2012 13:58:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-remote-lfa-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120612205815.3446.91827.idtracker@ietfa.amsl.com> Date: Tue, 12 Jun 2012 13:58:15 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Jun 2012 20:58:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Remote LFA FRR Author(s) : Stewart Bryant Clarence Filsfils Mike Shand Ning So Filename : draft-ietf-rtgwg-remote-lfa-00.txt Pages : 12 Date : 2012-06-12 Abstract: This draft describes an extension to the basic IP fast re-route mechanism described in RFC 5286 that provides additional backup connectivity when none can be provided by the basic mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ice@cisco.com Tue Jun 12 14:33:06 2012 Return-Path: <ice@cisco.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0CC21F8629 for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 14:33:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8vb6wufOjUH for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 14:33:05 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2509821F8628 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 14:33:04 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-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 q5CLX3M1027489 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 23:33:04 +0200 (CEST) Received: from ams3-vpn-dhcp7373.cisco.com (ams3-vpn-dhcp7373.cisco.com [10.61.92.204]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5CLX1jp014609; Tue, 12 Jun 2012 23:33:01 +0200 (CEST) Subject: Re: poll on draft-karan-mofrr-02 to become a WG draft Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands <ice@cisco.com> In-Reply-To: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> Date: Tue, 12 Jun 2012 23:33:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <CC78A79A-740D-4EA5-A6B0-248766259D44@cisco.com> References: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> To: Alia Atlas <akatlas@gmail.com> X-Mailer: Apple Mail (2.1257) Cc: pim-chairs@tools.ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Jun 2012 21:33:06 -0000 Hi Alia, > This email is to start a poll and discussion on whether > draft-karan-mofrr-02 should > become an RTGWG draft. Please include comments, details, and whether = you have > read the draft. I support this draft to become a WG document. > The earlier version was presented positively to the PIM WG as well. >=20 > Authors, please indicate whether there is any IPR associated with this = draft. Yes, there is IPR. I contact the Cisco legal department and requested to = issue an IPR statement. Thx, Ice.= From jeff.tantsura@ericsson.com Tue Jun 12 16:02:45 2012 Return-Path: <jeff.tantsura@ericsson.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA6721F8498 for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 16:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSpnSMqfJmBw for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 16:02:45 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 023DA21F8497 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 16:02:44 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5CN2er8013612; Tue, 12 Jun 2012 18:02:42 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 12 Jun 2012 19:02:39 -0400 From: Jeff Tantsura <jeff.tantsura@ericsson.com> To: Alia Atlas <akatlas@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "pim-chairs@tools.ietf.org" <pim-chairs@tools.ietf.org> Date: Tue, 12 Jun 2012 19:02:37 -0400 Subject: RE: poll on draft-karan-mofrr-02 to become a WG draft Thread-Topic: poll on draft-karan-mofrr-02 to become a WG draft Thread-Index: Ac1I29YQBlsNrTIuSsKLnYu+/XewowAE1YJg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF62190321C79@EUSAACMS0701.eamcs.ericsson.se> References: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> In-Reply-To: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> 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 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Jun 2012 23:02:45 -0000 Hi Alia, Yes/support, having product implementation since 2009. There's an IPR associated with the draft: (https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document= _search=3Ddraft-karan-mofrr) Regards, Jeff -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lia Atlas Sent: Tuesday, June 12, 2012 1:42 PM To: rtgwg@ietf.org; pim-chairs@tools.ietf.org Subject: poll on draft-karan-mofrr-02 to become a WG draft This email is to start a poll and discussion on whether draft-karan-mofrr-02 should become an RTGWG draft. Please include comments, details, and whether you = have read the draft. The earlier version was presented positively to the PIM WG as well. Authors, please indicate whether there is any IPR associated with this draf= t. Thanks, Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From agmalis@gmail.com Tue Jun 12 21:31:04 2012 Return-Path: <agmalis@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E721F858F for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 21:31:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk1pTqL7on-9 for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 21:31:02 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DEB3721F858A for <rtgwg@ietf.org>; Tue, 12 Jun 2012 21:31:00 -0700 (PDT) Received: by ggnc4 with SMTP id c4so109625ggn.31 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 21:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=90pxUqtn6Jy1xuR6oJIPyoU95aQYMbE03LuhWhoThtw=; b=e6UmJibXi0IuFWDOxtEdhTNIjEGsGay3Kp7uw/zn3nzIRS+OlJHa2QK9w4keKQYp/Z clPow5aMbYU0ZSj/R2Y/iVl4k1YrfoCOylAqIL1MzLCEAtm2d7WLnJIpbH05PsX3JKd2 awWvbL1qzolF7U8Y1PyWQ03QQQ7Q2TPDukmDip0SvBOIgvps6bmkQfu2x9EsnoVvV7AG 1AOq1RxBT1Jork2Kv3mw3+zsK9W+L52/DyICIFeKxtCd9IUX6VF/ws1pfsyT8++Mo/0u v8688ItQennQdF/men4EHfVJ4MCbzlqNWju1VlZvXdHnGIM8yI2+CKlssshka1kvIiWj hkgA== Received: by 10.50.188.233 with SMTP id gd9mr9693747igc.73.1339561859294; Tue, 12 Jun 2012 21:30:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.77.78 with HTTP; Tue, 12 Jun 2012 21:30:39 -0700 (PDT) In-Reply-To: <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> References: <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> From: "Andrew G. Malis" <agmalis@gmail.com> Date: Wed, 13 Jun 2012 13:30:39 +0900 Message-ID: <CAA=duU0vdrZufMHKWRedw8fqp_VWO0cN1T0zx9VgX_6-_Y=fUg@mail.gmail.com> Subject: Re: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft To: Alia Atlas <akatlas@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Jun 2012 04:31:05 -0000 I have read the draft and I support! Plus I am not aware of any IPR in this draft. Cheers, Andy On Wed, Jun 13, 2012 at 5:36 AM, Alia Atlas <akatlas@gmail.com> wrote: > This is to start a poll and discussion about whether RTGWG should adopt > draft-symmvo-rtgwg-cl-use-cases-00 as a WG draft. > > Please respond with comments and reasoning and if you have read the draft. > At our last meeting, very few people indicated that they had read the draft. > > Authors, please indicate in email whether there is any IPR associated > with the draft. > > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From agmalis@gmail.com Tue Jun 12 21:31:23 2012 Return-Path: <agmalis@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C73711E8086 for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 21:31:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp+TIloSQSIb for <rtgwg@ietfa.amsl.com>; Tue, 12 Jun 2012 21:31:23 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB22411E80B1 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 21:31:22 -0700 (PDT) Received: by ghbg16 with SMTP id g16so90331ghb.31 for <rtgwg@ietf.org>; Tue, 12 Jun 2012 21:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9JBbxBsoD14bVCBDPBRbBtiTKQ8uBfVE8UaumXPqxIw=; b=dLnOd5vu7ZqU439H+KLGOXrzvXTd/x4ye0YzAIfQCTqMXF/HL7Oc3wh3Hlud5q/CIm Zw/n68OahpTMrgDTJW3mc93bycMwauROJEJqUlS5S9MDL8b7DjEHgN2QXx3aICmoGrLA l1o3HvXN2tL2tD6ExNHsq4YbvEY1GQpGEazOi8i8jLDTEcpWBzqgJmlkHWcSJKlQu+eW GPBFZLxknCiUQLqR0mc3k9UCwBnYeDngeergQZMAfXuS9+fB0csmTDWV66GTct+Yha4F ejrEo8mhmf3Ee8DYu1FOhUIr2TmV0t1E0a9P2ZJe8VhY++YlHKGVNfA/mgdyRMdZ8tBU ELKw== Received: by 10.50.45.197 with SMTP id p5mr9689135igm.73.1339561882262; Tue, 12 Jun 2012 21:31:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.77.78 with HTTP; Tue, 12 Jun 2012 21:31:02 -0700 (PDT) In-Reply-To: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> References: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> From: "Andrew G. Malis" <agmalis@gmail.com> Date: Wed, 13 Jun 2012 13:31:02 +0900 Message-ID: <CAA=duU1BcD7-Lh9EfnuA0XJL=+XyJTMVJxUSYC=c_jJboeXrvw@mail.gmail.com> Subject: Re: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft To: Alia Atlas <akatlas@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Jun 2012 04:31:23 -0000 I have read the draft and I support! Plus I am not aware of any IPR in this draft. Cheers, Andy On Wed, Jun 13, 2012 at 5:39 AM, Alia Atlas <akatlas@gmail.com> wrote: > This email is to start a poll and discussion on whether to adopt > draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft. > Please respond with opinions, comments, and whether you have read the draft. > Last IETF, there were very few people who had read the draft. > > Authors, please indicate if there is any IPR associated with this draft. > > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From Andras.Csaszar@ericsson.com Wed Jun 13 02:22:48 2012 Return-Path: <Andras.Csaszar@ericsson.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFF421F8540 for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 02:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMKSFRDNiIYU for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 02:22:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4D92621F8539 for <rtgwg@ietf.org>; Wed, 13 Jun 2012 02:22:47 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-00-4fd85be652f5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0F.2A.28636.6EB58DF4; Wed, 13 Jun 2012 11:22:46 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.131]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 13 Jun 2012 11:22:45 +0200 From: =?utf-8?B?QW5kcsOhcyBDc8Ohc3rDoXI=?= <Andras.Csaszar@ericsson.com> To: Alia Atlas <akatlas@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "pim-chairs@tools.ietf.org" <pim-chairs@tools.ietf.org> Date: Wed, 13 Jun 2012 11:22:44 +0200 Subject: RE: poll on draft-karan-mofrr-02 to become a WG draft Thread-Topic: poll on draft-karan-mofrr-02 to become a WG draft Thread-Index: Ac1I289vcjN+SOdoQ8eZb3HDj+tQLgAZjFTQ Message-ID: <8DCD771BDA4A394E9BCBA8932E839297783E30F23B@ESESSCMS0363.eemea.ericsson.se> References: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> In-Reply-To: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre6z6Bv+Bs+vilp8eniJ2eJnwzlm iwtvfjM7MHvsnHWX3WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgyjg2/TpbwT25iv17jrE0 MP6Q7WLk5JAQMJG4sbCVCcIWk7hwbz0biC0kcIpRom2hWRcjF5C9kFFiatc3dpAEm4CHxP3r f5lBEiICDYwS+xsnsoAkWARUJU4uWcAIYgsL2EksWjAZqIEDqMheYtUhsGUiAkYSX3YtYAIJ 8wqES2w+lwOxK0BiR/cGVpAwp0CgxL7VSiAmo4CsxMO1FiAVzALiEreezIe6UkBiyZ7zzBC2 qMTLx/9YQWxGARmJD0sPsYG0MgtoSqzfpQ/Rqigxpfsh2O28AoISJ2c+YZnAKDoLydRZCB2z kHTMQtKxgJFlFaNwbmJmTnq5oV5qUWZycXF+nl5x6iZGYLQc3PJbdwfjqXMihxilOViUxHm5 kvb7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDs+/HcU6kj1P/BoUNVJty3ufefPRRmeKvD edK5R0+vBXI/vn/l+J1qwf3CC5bdkXjgf+FKppHBo6+BFrISQXXTJxRrr/d7dv66c6f7skCx k2J3uysWPHnzRvLz/5UHN6/sZDM3Ur4RlKXwdzrrXPm8T+YNMS+7rFceaqhZ3rtyg6zijxNW axZqKbEUZyQaajEXFScCABUnOlVkAgAA X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Jun 2012 09:22:48 -0000 SGkgQWxpYSwNCg0KTW9GUlIgdG8gbWUgaXMgYSBraW5kIG9mIGFwcGx5aW5nIHRoZSBMRkEgaWRl YSB0byBtdWx0aWNhc3QsIGFuZCBhbHNvIGdpdmVuIHRoYXQgaW1wbGVtZW50YXRpb25zIGFscmVh ZHkgZXhpc3QgKGZvciBxdWl0ZSBzb21lIHRpbWUgbm93LCBpZiBJJ20gY29ycmVjdCksIEkgZG8g c3VwcG9ydCBpdC4NCg0KVHJ5aW5nIHRvIGJlIGNvbnN0cnVjdGl2ZSBhZ2FpbiwgSSB3b3VsZCBn aXZlIHNvbWUgZmVlZGJhY2sgZm9yIHRoaXMgb25lLCB0b28gOi0pDQoNCjEuIEkgc3VnZ2VzdCBh IGxpdHRsZSBtb3JlIGdsdWUgYmV0d2VlbiB0aGUgdGV4dCBpbiBjaGFwdGVyIDcgKG5vbi1FQ01Q IG1vZGUgTW9GUlIpIGFuZCB0aGUgTEZBIHNwZWMuIE5vbi1FQ01QIG1vZGUgc2VlbXMgdmVyeSBt dWNoIGxpa2UgdGhlIExGQSBydWxlcywgeWV0IHRoZXkgYXJlIHJlZGVmaW5lZCwgd2hpY2ggaXMg bm90IGEgcHJvYmxlbSwgYnV0IEknZCBwcmVmZXIgaGF2aW5nIGEgc2ltaWxhciBub3RhdGlvbi9z eW50YXgvdGVybWlub2xvZ3kgYW5kIHJ1bGVzIGFzIGZhciBhcyBwb3NzaWJsZS4gSWYgdGhlcmUg YXJlIGRpZmZlcmVuY2VzLCB0aGV5IHNob3VsZCBiZSBoaWdobGlnaHRlZC4NCg0KDQoyLiBDaGFw dGVyIDUsIGRldGVjdGluZyBmYWlsdXJlcy4gSSB0aGluayB3ZSBzaG91bGQgdHJ5IHRvIGdpdmUg YSBsaXR0bGUgbW9yZSBkZXRhaWxzLiBQYWNrZXQgY29tcGFyaXNvbiBkZXRhaWxzLCB3aGF0IG5l ZWRzIHRvIGJlIHN0b3JlZD8gQ29tcGxldGUgcGFja2V0PyBQYWNrZXQgaGFzaD8gUlRQIHNlcSBu dW1iZXI/IC4uLg0KDQpJIHRoaW5rIHRoZSAidGhpcmQgb3B0aW9uIiwgdG8gcmVseSBvbiBJR1Bz IGlzIGJ5IGRlZmluaXRpb24gbm90IEZSUiwgc28gdGhpcyBzaG91bGQgYmUgdGhlIGxhc3Qgb3B0 aW9uLg0KDQpUaGUgZm91cnRoIG9wdGlvbiBpcyAibGV2ZXJhZ2luZyBjb25uZWN0ZWQgbGluayBm YWlsdXJlIi4gSSB0aGluayB0aGlzIG9wdGlvbiBjb3VsZCBiZSB0aGUgZWFzaWVzdC9tb3N0IG5h dHVyYWwgYXBwcm9hY2gsIGFuZCBJIGd1ZXNzIHNpbmNlIExvUywgQkZEIGFuZCBhbnkgbG9jYWwg RFAgZmFpbHVyZSBkZXRlY3Rpb24gbWVjaGFuaXNtIGlzIHVzdWFsbHkgdGllZCBhbHJlYWR5IHRv IHVuaWNhc3QgRlJSLCB3aHkgbm90IHByb3Bvc2UgdGhpcyB0byBiZSB0aGUgcHJpbWFyeSBvcHRp b24gZm9yIE1vRlJSLCB0b28/IA0KDQoNCjMuIENoYXB0ZXIgMTA6ICJUaGUgTW9GUlIgcHJpbmNp cGxlIG1heSBiZSBhcHBsaWVkIHRvIE1WUE5zLiIgTGV0J3MgZ2l2ZSBtb3JlIGRldGFpbHMsIGlm IHBvc3NpYmxlLg0KDQoNCjQuIER1ZSB0byBtTERQLCBwcm9iYWJseSB0aGUgTVBMUyBXRyBjaGFp cnMgc2hvdWxkIGJlIGludm9sdmVkLCB0b28sIG5vdCBvbmx5IFBJTS4NCg0KDQo1LiBXaHkgaXMg dGhlIGludGVuZGVkIHN0YXR1cyAiaW5mb3JtYXRpb25hbCI/IFdoeSBzaG91bGQgaXQgYmUgZGlm ZmVyZW50IGZyb20gTEZBIG9yIHJlbW90ZSBMRkE/IEkgYWdyZWUgdGhlIHNvbHV0aW9uIHByYWN0 aWNhbGx5IGRvZXMgbm90IHJlcXVpcmUgYW55IG5vdmVsIGNvb3BlcmF0aW9uIG1ldGhvZCBmcm9t IG90aGVyIG5vZGVzLCB3aGljaCBpcyBhbiBhZHZhbnRhZ2UsIHNvIHRoZXJlIGlzIGxpdHRsZSB0 byBiZSBhICJTdGFuZGFyZCIsIGJ1dCB0aGF0J3MgdHJ1ZSBmb3IgTEZBIG9yIFJMRkEgYXMgd2Vs bC4gU28/DQoNCg0KNi4gV2Ugb2Z0ZW4gdXNlZCB0aGUgdGVybWlub2xvZ3kgImxpdmUtbGl2ZSIg aW4gb3RoZXIgZHJhZnRzLCBzdWNoIGFzIGluIE1SVC4gSSBhY3R1YWxseSB0aG91Z2h0IHRoYXQg aXQgY2FtZSBmcm9tIE1vRlJSLCBidXQgbm93IEkgZGlkIGZpbmQgbm8gdHJhY2Ugb2YgaXQgaW4g dGhlIGRvYy4gTWF5YmUgd2Ugc2hvdWxkIGFkZCBhIHNlbnRlbmNlIGFib3V0IGl0LCBzYXlpbmcg dGhhdCBNb0ZSUiBpbXBsZW1lbnRzIHdoYXQgaXMgb2Z0ZW4gY2FsbGVkICJsaXZlLWxpdmUiIHBy b3RlY3Rpb24uDQoNCg0KSSBzdGFydGVkIHRvIHJlYWxpc2UgSSdtIG9mdGVuIHRvbyBsb25nLCBz b3JyeSBmb3IgdGhhdCA6LSkNCg0KQW5kcsOhcw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogcnRnd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Z3dnLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBBbGlhIEF0bGFzDQo+IFNlbnQ6IDIwMTIuIGrD um5pdXMgMTIuIDIyOjQyDQo+IFRvOiBydGd3Z0BpZXRmLm9yZzsgcGltLWNoYWlyc0B0b29scy5p ZXRmLm9yZw0KPiBTdWJqZWN0OiBwb2xsIG9uIGRyYWZ0LWthcmFuLW1vZnJyLTAyIHRvIGJlY29t ZSBhIFdHIGRyYWZ0DQo+IA0KPiBUaGlzIGVtYWlsIGlzIHRvIHN0YXJ0IGEgcG9sbCBhbmQgZGlz Y3Vzc2lvbiBvbiB3aGV0aGVyDQo+IGRyYWZ0LWthcmFuLW1vZnJyLTAyIHNob3VsZA0KPiBiZWNv bWUgYW4gUlRHV0cgZHJhZnQuICAgUGxlYXNlIGluY2x1ZGUgY29tbWVudHMsIGRldGFpbHMsIGFu ZCB3aGV0aGVyDQo+IHlvdSBoYXZlDQo+IHJlYWQgdGhlIGRyYWZ0Lg0KPiANCj4gVGhlIGVhcmxp ZXIgdmVyc2lvbiB3YXMgcHJlc2VudGVkIHBvc2l0aXZlbHkgdG8gdGhlIFBJTSBXRyBhcyB3ZWxs Lg0KPiANCj4gQXV0aG9ycywgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgdGhlcmUgaXMgYW55IElQ UiBhc3NvY2lhdGVkIHdpdGggdGhpcw0KPiBkcmFmdC4NCj4gDQo+IFRoYW5rcywNCj4gQWxpYQ0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGd3 ZyBtYWlsaW5nIGxpc3QNCj4gcnRnd2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGd3Zw0K From ningso@yahoo.com Wed Jun 13 11:30:40 2012 Return-Path: <ningso@yahoo.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C68121F8547 for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 11:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_41=0.6] 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 a+EGtfkC6s2H for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 11:30:39 -0700 (PDT) Received: from nm22.bullet.mail.sp2.yahoo.com (nm22.bullet.mail.sp2.yahoo.com [98.139.91.92]) by ietfa.amsl.com (Postfix) with SMTP id 7291821F8550 for <rtgwg@ietf.org>; Wed, 13 Jun 2012 11:30:39 -0700 (PDT) Received: from [98.139.91.68] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:30:38 -0000 Received: from [68.142.200.226] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:29:38 -0000 Received: from [66.94.237.97] by t7.bullet.mud.yahoo.com with NNFMP; 13 Jun 2012 18:29:38 -0000 Received: from [127.0.0.1] by omp1002.access.mail.mud.yahoo.com with NNFMP; 13 Jun 2012 18:29:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 48280.56147.bm@omp1002.access.mail.mud.yahoo.com Received: (qmail 19089 invoked by uid 60001); 13 Jun 2012 18:29:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1339612177; bh=3/EeRKMDBHm3981ZlYAJsx6xGTITShs9IcYBH7JPzg8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=lRnrRWy6gy/yHLKKHDRyH0v5wb2xacr4L4iQSoiWqBcgnPgj0OJGvwmV0khRZPEbhyK8EFWeHYv7YfCKtl6mqQy1CbakCPW3rt295eY8DOU1QeZDowi/S7SdIIlutuCulJzY6mHf0VOedJbm0s9LPAQwrbcVQ4KmZbxWN+qqvW0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=T6CWqOcKyiaO6Q0F/4+Y6RCBDzpQYXFsqGFZGRQWhm5WuoIE1um0Z8yhzFSxoPkiSL3QeUAEkMa+wa07Zid3lAVDoSLVWdmMzFEhV2/BhET/9m6IcQJnop+Q5dEaVwQFGnXzYuAxoBJ4G8FaKx08OWAGFnNZZigJOl+tfrwL+eo=; X-YMail-OSG: CLj808EVM1n1e81TcXG.e2yGtALDrEyoYRwHp9x81Y18AS2 a2OpYlOY9JvtwQJstfWM4hyFe2cIJxVla47bd0jq1jG15AZvAFMeFLdXHag8 UFIadqZ36VZONqbesGo3W3Wv8tweC7MoHxXrXQeDcm9uZF58T3G8B4VELOAU 30HxCg0VszqZxyBraue6iDQiL0sJ6lyEE8WE.VJGiOZgyrvlpwenzGw_Th5W b_fpS45ODOpmxS4yeH.UpzFnvfKHuNeJtfHdukgA3mKTXpk_dpGWRiCl15Vm YfAQFcTMIQjoIFqA920XqVUxIHP8tLK2TLauinleumsSoyjDF0fAY2ydHHip 84bQNMIAIwDBPYveuq1Xi53bbV1AxsQWXXQ17q9t42J1hzTqx8.OsN16lNj_ g8tlXg0NHvFbLdR2lZdYPa04TzHbH3f7ZfsUwpb1n_UPGxp9dhls..7SUuFn _Xe.Ev8ynrjiHbYTBHcdOUQ-- Received: from [173.57.97.155] by web84514.mail.ne1.yahoo.com via HTTP; Wed, 13 Jun 2012 11:29:37 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: <mailman.613.1339579368.3336.rtgwg@ietf.org> Message-ID: <1339612177.18219.YahooMailNeo@web84514.mail.ne1.yahoo.com> Date: Wed, 13 Jun 2012 11:29:37 -0700 (PDT) From: Ning So <ningso@yahoo.com> Subject: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft To: "rtgwg@ietf.org" <rtgwg@ietf.org> In-Reply-To: <mailman.613.1339579368.3336.rtgwg@ietf.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="750031334-358350780-1339612177=:18219" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ning So <ningso@yahoo.com> List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Jun 2012 18:30:40 -0000 --750031334-358350780-1339612177=:18219 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Support as co-author.=A0 I am not aware of any IPR associated with this dra= ft.=0A=0ANing=0A=0A=0A=0AFrom: Alia Atlas <akatlas@gmail.com>=0ATo: rtgwg@i= etf.org=0ASubject: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as W= G=0A=A0=A0=A0 draft=0AMessage-ID:=0A=A0=A0=A0 <CAG4d1re2mY6-tiapwfP_qYmdP7+= uMeFApkHAfzODXHK6AosaLw@mail.gmail.com>=0AContent-Type: text/plain; charset= =3DISO-8859-1=0A=0AThis is to start a poll and discussion about whether RTG= WG should adopt=0Adraft-symmvo-rtgwg-cl-use-cases-00 as a WG draft.=0A=0APl= ease respond with comments and reasoning and if you have read the draft.=0A= At our last meeting, very few people indicated that they had read the draft= .=0A=0AAuthors, please indicate in email whether there is any IPR associate= d=0Awith the draft.=0A=0AThanks,=0AAlia=0A=0A=0A---------------------------= ---=0A=0AMessage: 4=0ADate: Tue, 12 Jun 2012 16:39:20 -0400=0AFrom: Alia At= las <akatlas@gmail.com>=0ATo: rtgwg@ietf.org=0ASubject: poll to adopt draft= -so-yong-rtgwg-cl-framework-05 as a WG=0A=A0=A0=A0 draft=0AMessage-ID:=0A= =A0=A0=A0 <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.c= om>=0AContent-Type: text/plain; charset=3DISO-8859-1=0A=0AThis email is to = start a poll and discussion on whether to adopt=0Adraft-so-yong-rtgwg-cl-fr= amework-05 as an RTGWG draft.=0APlease respond with opinions, comments, and= whether you have read the draft.=0ALast IETF, there were very few people w= ho had read the draft.=0A=0AAuthors, please indicate if there is any IPR as= sociated with this draft.=0A=0AThanks,=0AAlia=0A=0A=0A=0AMessage: 10=0ADate= : Wed, 13 Jun 2012 13:31:02 +0900=0AFrom: "Andrew G. Malis" <agmalis@gmail.= com>=0ATo: Alia Atlas <akatlas@gmail.com>=0ACc: rtgwg@ietf.org=0ASubject: R= e: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG=0A=A0=A0=A0 dr= aft=0AMessage-ID:=0A=A0=A0=A0 <CAA=3DduU1BcD7-Lh9EfnuA0XJL=3D+XyJTMVJxUSYC= =3Dc_jJboeXrvw@mail.gmail.com>=0AContent-Type: text/plain; charset=3DISO-88= 59-1=0A=0AI have read the draft and I support! Plus I am not aware of any I= PR in=0Athis draft.=0A=0ACheers,=0AAndy=0A=0AOn Wed, Jun 13, 2012 at 5:39 A= M, Alia Atlas <akatlas@gmail.com> wrote:=0A> This email is to start a poll = and discussion on whether to adopt=0A> draft-so-yong-rtgwg-cl-framework-05 = as an RTGWG draft.=0A> Please respond with opinions, comments, and whether = you have read the draft.=0A> Last IETF, there were very few people who had = read the draft.=0A>=0A> Authors, please indicate if there is any IPR associ= ated with this draft.=0A>=0A> Thanks,=0A> Alia=0A> ________________________= _______________________=0A> rtgwg mailing list=0A> rtgwg@ietf.org=0A> https= ://www.ietf.org/mailman/listinfo/rtgwg=0A=0A=0A----------------------------= --=0A=0AMessage: 11=0ADate: Wed, 13 Jun 2012 11:22:44 +0200=0AFrom: Andr?s = Cs?sz?r <Andras.Csaszar@ericsson.com>=0ATo: Alia Atlas <akatlas@gmail.com>,= "rtgwg@ietf.org" <rtgwg@ietf.org>,=0A=A0=A0=A0 "pim-chairs@tools.ietf.org"= <pim-chairs@tools.ietf.org>=0ASubject: RE: poll on draft-karan-mofrr-02 to= become a WG draft=0AMessage-ID:=0A=A0=A0=A0 <8DCD771BDA4A394E9BCBA8932E839= 297783E30F23B@ESESSCMS0363.eemea.ericsson.se>=0A=A0=A0=A0 =0AContent-Type: = text/plain; charset=3D"utf-8"=0A=0AHi Alia,=0A=0AMoFRR to me is a kind of a= pplying the LFA idea to multicast, and also given that implementations alre= ady exist (for quite some time now, if I'm correct), I do support it.=0A=0A= Trying to be constructive again, I would give some feedback for this one, t= oo :-)=0A=0A1. I suggest a little more glue between the text in chapter 7 (= non-ECMP mode MoFRR) and the LFA spec. Non-ECMP mode seems very much like t= he LFA rules, yet they are redefined, which is not a problem, but I'd prefe= r having a similar notation/syntax/terminology and rules as far as possible= . If there are differences, they should be highlighted.=0A=0A=0A2. Chapter = 5, detecting failures. I think we should try to give a little more details.= Packet comparison details, what needs to be stored? Complete packet? Packe= t hash? RTP seq number? ...=0A=0AI think the "third option", to rely on IGP= s is by definition not FRR, so this should be the last option.=0A=0AThe fou= rth option is "leveraging connected link failure". I think this option coul= d be the easiest/most natural approach, and I guess since LoS, BFD and any = local DP failure detection mechanism is usually tied already to unicast FRR= , why not propose this to be the primary option for MoFRR, too? =0A=0A=0A3.= Chapter 10: "The MoFRR principle may be applied to MVPNs." Let's give more= details, if possible.=0A=0A=0A4. Due to mLDP, probably the MPLS WG chairs = should be involved, too, not only PIM.=0A=0A=0A5. Why is the intended statu= s "informational"? Why should it be different from LFA or remote LFA? I agr= ee the solution practically does not require any novel cooperation method f= rom other nodes, which is an advantage, so there is little to be a "Standar= d", but that's true for LFA or RLFA as well. So?=0A=0A=0A6. We often used t= he terminology "live-live" in other drafts, such as in MRT. I actually thou= ght that it came from MoFRR, but now I did find no trace of it in the doc. = Maybe we should add a sentence about it, saying that MoFRR implements what = is often called "live-live" protection.=0A=0A=0AI started to realise I'm of= ten too long, sorry for that :-)=0A=0AAndr?s=0A=0A=0A> -----Original Messag= e-----=0A> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On = Behalf=0A> Of Alia Atlas=0A> Sent: 2012. j?nius 12. 22:42=0A> To: rtgwg@iet= f.org; pim-chairs@tools.ietf.org=0A> Subject: poll on draft-karan-mofrr-02 = to become a WG draft=0A> =0A> This email is to start a poll and discussion = on whether=0A> draft-karan-mofrr-02 should=0A> become an RTGWG draft.=A0 P= lease include comments, details, and whether=0A> you have=0A> read the draf= t.=0A> =0A> The earlier version was presented positively to the PIM WG as w= ell.=0A> =0A> Authors, please indicate whether there is any IPR associated = with this=0A> draft.=0A> =0A> Thanks,=0A> Alia=0A> ________________________= _______________________=0A> rtgwg mailing list=0A> rtgwg@ietf.org=0A> https= ://www.ietf.org/mailman/listinfo/rtgwg=0A=0A------------------------------= =0A=0A_______________________________________________=0Artgwg mailing list= =0Artgwg@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/rtgwg=0A=0A=0AEnd= of rtgwg Digest, Vol 90, Issue 15=0A************************************* --750031334-358350780-1339612177=:18219 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt">Support as co-author.=   I am not aware of any IPR associated with this draft.<br><br>Ning<br= ><br><br><div style=3D"font-family: times new roman, new york, times, serif= ; font-size: 12pt;"><div style=3D"font-family: times new roman, new york, t= imes, serif; font-size: 12pt;">From: Alia Atlas <<a ymailto=3D"mailto:ak= atlas@gmail.com" href=3D"mailto:akatlas@gmail.com">akatlas@gmail.com</a>>= ;<br>To: <a ymailto=3D"mailto:rtgwg@ietf.org" href=3D"mailto:rtgwg@ietf.org= ">rtgwg@ietf.org</a><br>Subject: poll on adopting draft-symmvo-rtgwg-cl-use= -cases-00 as WG<br>    draft<br>Message-ID:<br>  &= nbsp; <CAG4d1re2mY6-tiapwfP_qYmdP7+<a ymailto=3D"mailto:uMeFApkHAfzODXHK= 6AosaLw@mail.gmail.com" href=3D"mailto:uMeFApkHAfzODXHK6AosaLw@mail.gmail.c= om">uMeFApkHAfzODXHK6AosaLw@mail.gmail.com</a>><br>Content-Type: text/pl= ain; charset=3DISO-8859-1<br><br>This is to start a poll and discussion about w= hether RTGWG should adopt<br>draft-symmvo-rtgwg-cl-use-cases-00 as a WG dra= ft.<br><br>Please respond with comments and reasoning and if you have read = the draft.<br>At our last meeting, very few people indicated that they had = read the draft.<br><br>Authors, please indicate in email whether there is a= ny IPR associated<br>with the draft.<br><br>Thanks,<br>Alia<br><br><br>----= --------------------------<br><br>Message: 4<br>Date: Tue, 12 Jun 2012 16:3= 9:20 -0400<br>From: Alia Atlas <<a ymailto=3D"mailto:akatlas@gmail.com" = href=3D"mailto:akatlas@gmail.com">akatlas@gmail.com</a>><br>To: <a ymail= to=3D"mailto:rtgwg@ietf.org" href=3D"mailto:rtgwg@ietf.org">rtgwg@ietf.org<= /a><br>Subject: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG<b= r>    draft<br>Message-ID:<br>    <CAG4d1r= f6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+<a ymailto=3D"mailto:Gg@mail.gmail.com" href=3D"mailto:Gg@mail.gmail.com">Gg@= mail.gmail.com</a>><br>Content-Type: text/plain; charset=3DISO-8859-1<br= ><br>This email is to start a poll and discussion on whether to adopt<br>dr= aft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft.<br>Please respond with= opinions, comments, and whether you have read the draft.<br>Last IETF, the= re were very few people who had read the draft.<br><br>Authors, please indi= cate if there is any IPR associated with this draft.<br><br>Thanks,<br>Alia= <br><br><br><br>Message: 10<br>Date: Wed, 13 Jun 2012 13:31:02 +0900<br>Fro= m: "Andrew G. Malis" <<a ymailto=3D"mailto:agmalis@gmail.com" href=3D"ma= ilto:agmalis@gmail.com">agmalis@gmail.com</a>><br>To: Alia Atlas <<a = ymailto=3D"mailto:akatlas@gmail.com" href=3D"mailto:akatlas@gmail.com">akat= las@gmail.com</a>><br>Cc: <a ymailto=3D"mailto:rtgwg@ietf.org" href=3D"m= ailto:rtgwg@ietf.org">rtgwg@ietf.org</a><br>Subject: Re: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG<br>    draft<br= >Message-ID:<br>    <CAA=3DduU1BcD7-Lh9EfnuA0XJL=3D+XyJTM= VJxUSYC=3D<a ymailto=3D"mailto:c_jJboeXrvw@mail.gmail.com" href=3D"mailto:c= _jJboeXrvw@mail.gmail.com">c_jJboeXrvw@mail.gmail.com</a>><br>Content-Ty= pe: text/plain; charset=3DISO-8859-1<br><br>I have read the draft and I sup= port! Plus I am not aware of any IPR in<br>this draft.<br><br>Cheers,<br>An= dy<br><br>On Wed, Jun 13, 2012 at 5:39 AM, Alia Atlas <<a ymailto=3D"mai= lto:akatlas@gmail.com" href=3D"mailto:akatlas@gmail.com">akatlas@gmail.com<= /a>> wrote:<br>> This email is to start a poll and discussion on whet= her to adopt<br>> draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft.= <br>> Please respond with opinions, comments, and whether you have read = the draft.<br>> Last IETF, there were very few people who had read the d= raft.<br>><br>> Authors, please indicate if there is any IPR associat= ed with this draft.<br>><br>> Thanks,<br>> Alia<br>> _________________= ______________________________<br>> rtgwg mailing list<br>> <a ymailt= o=3D"mailto:rtgwg@ietf.org" href=3D"mailto:rtgwg@ietf.org">rtgwg@ietf.org</= a><br>> <a href=3D"https://www.ietf.org/mailman/listinfo/rtgwg" target= =3D"_blank">https://www.ietf.org/mailman/listinfo/rtgwg</a><br><br><br>----= --------------------------<br><br>Message: 11<br>Date: Wed, 13 Jun 2012 11:= 22:44 +0200<br>From: Andr?s Cs?sz?r <<a ymailto=3D"mailto:Andras.Csaszar= @ericsson.com" href=3D"mailto:Andras.Csaszar@ericsson.com">Andras.Csaszar@e= ricsson.com</a>><br>To: Alia Atlas <<a ymailto=3D"mailto:akatlas@gmai= l.com" href=3D"mailto:akatlas@gmail.com">akatlas@gmail.com</a>>, "<a yma= ilto=3D"mailto:rtgwg@ietf.org" href=3D"mailto:rtgwg@ietf.org">rtgwg@ietf.or= g</a>" <<a ymailto=3D"mailto:rtgwg@ietf.org" href=3D"mailto:rtgwg@ietf.o= rg">rtgwg@ietf.org</a>>,<br>    "<a ymailto=3D"mailto:pim-chairs@tools.ietf.org" href=3D"mailto:pim-chairs@too= ls.ietf.org">pim-chairs@tools.ietf.org</a>" <<a ymailto=3D"mailto:pim-ch= airs@tools.ietf.org" href=3D"mailto:pim-chairs@tools.ietf.org">pim-chairs@t= ools.ietf.org</a>><br>Subject: RE: poll on draft-karan-mofrr-02 to becom= e a WG draft<br>Message-ID:<br>    <<a ymailto=3D"mailto:= 8DCD771BDA4A394E9BCBA8932E839297783E30F23B@ESESSCMS0363.eemea.ericsson.se" = href=3D"mailto:8DCD771BDA4A394E9BCBA8932E839297783E30F23B@ESESSCMS0363.eeme= a.ericsson.se">8DCD771BDA4A394E9BCBA8932E839297783E30F23B@ESESSCMS0363.eeme= a.ericsson.se</a>><br>    <br>Content-Type: text/plain; c= harset=3D"utf-8"<br><br>Hi Alia,<br><br>MoFRR to me is a kind of applying t= he LFA idea to multicast, and also given that implementations already exist= (for quite some time now, if I'm correct), I do support it.<br><br>Trying = to be constructive again, I would give some feedback for this one, too :-)<br><br>1. I suggest a little more glue between the text in chapter 7 (= non-ECMP mode MoFRR) and the LFA spec. Non-ECMP mode seems very much like t= he LFA rules, yet they are redefined, which is not a problem, but I'd prefe= r having a similar notation/syntax/terminology and rules as far as possible= . If there are differences, they should be highlighted.<br><br><br>2. Chapt= er 5, detecting failures. I think we should try to give a little more detai= ls. Packet comparison details, what needs to be stored? Complete packet? Pa= cket hash? RTP seq number? ...<br><br>I think the "third option", to rely o= n IGPs is by definition not FRR, so this should be the last option.<br><br>= The fourth option is "leveraging connected link failure". I think this opti= on could be the easiest/most natural approach, and I guess since LoS, BFD a= nd any local DP failure detection mechanism is usually tied already to unic= ast FRR, why not propose this to be the primary option for MoFRR, too? <br><br><br>3. Chapter 10: "The MoFRR principle may be applied to MVP= Ns." Let's give more details, if possible.<br><br><br>4. Due to mLDP, proba= bly the MPLS WG chairs should be involved, too, not only PIM.<br><br><br>5.= Why is the intended status "informational"? Why should it be different fro= m LFA or remote LFA? I agree the solution practically does not require any = novel cooperation method from other nodes, which is an advantage, so there = is little to be a "Standard", but that's true for LFA or RLFA as well. So?<= br><br><br>6. We often used the terminology "live-live" in other drafts, su= ch as in MRT. I actually thought that it came from MoFRR, but now I did fin= d no trace of it in the doc. Maybe we should add a sentence about it, sayin= g that MoFRR implements what is often called "live-live" protection.<br><br= ><br>I started to realise I'm often too long, sorry for that :-)<br><br>And= r?s<br><br><br>> -----Original Message-----<br>> From: <a ymailto=3D"mailto:rtgwg-bounces@ietf.org" href=3D"mailto:rtgwg-bounces@iet= f.org">rtgwg-bounces@ietf.org</a> [mailto:<a ymailto=3D"mailto:rtgwg-bounce= s@ietf.org" href=3D"mailto:rtgwg-bounces@ietf.org">rtgwg-bounces@ietf.org</= a>] On Behalf<br>> Of Alia Atlas<br>> Sent: 2012. j?nius 12. 22:42<br= >> To: <a ymailto=3D"mailto:rtgwg@ietf.org" href=3D"mailto:rtgwg@ietf.or= g">rtgwg@ietf.org</a>; <a ymailto=3D"mailto:pim-chairs@tools.ietf.org" href= =3D"mailto:pim-chairs@tools.ietf.org">pim-chairs@tools.ietf.org</a><br>>= Subject: poll on draft-karan-mofrr-02 to become a WG draft<br>> <br>>= ; This email is to start a poll and discussion on whether<br>> draft-kar= an-mofrr-02 should<br>> become an RTGWG draft.  Please include com= ments, details, and whether<br>> you have<br>> read the draft.<br>>= ; <br>> The earlier version was presented positively to the PIM WG as we= ll.<br>> <br>> Authors, please indicate whether there is any IPR asso= ciated with this<br>> draft.<br>> <br>> Thanks,<br>> Alia<br>> ___= ____________________________________________<br>> rtgwg mailing list<br>= > <a ymailto=3D"mailto:rtgwg@ietf.org" href=3D"mailto:rtgwg@ietf.org">rt= gwg@ietf.org</a><br>> <a href=3D"https://www.ietf.org/mailman/listinfo/r= tgwg" target=3D"_blank">https://www.ietf.org/mailman/listinfo/rtgwg</a><br>= <br>------------------------------<br><br>_________________________________= ______________<br>rtgwg mailing list<br><a ymailto=3D"mailto:rtgwg@ietf.org= " href=3D"mailto:rtgwg@ietf.org">rtgwg@ietf.org</a><br><a href=3D"https://w= ww.ietf.org/mailman/listinfo/rtgwg" target=3D"_blank">https://www.ietf.org/= mailman/listinfo/rtgwg</a><br><br><br>End of rtgwg Digest, Vol 90, Issue 15= <br>*************************************<br><br><br> </div> </div> </div>= </body></html> --750031334-358350780-1339612177=:18219-- From ningso@yahoo.com Wed Jun 13 11:39:32 2012 Return-Path: <ningso@yahoo.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B51611E8083 for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 11:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_41=0.6] 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 6CqsGftRr6p6 for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 11:39:31 -0700 (PDT) Received: from nm11-vm0.access.bullet.mail.sp2.yahoo.com (nm11-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.124]) by ietfa.amsl.com (Postfix) with SMTP id 7167811E807F for <rtgwg@ietf.org>; Wed, 13 Jun 2012 11:39:31 -0700 (PDT) Received: from [98.139.44.107] by nm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:39:31 -0000 Received: from [98.139.44.84] by tm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:39:31 -0000 Received: from [127.0.0.1] by omp1021.access.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:39:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 331728.63426.bm@omp1021.access.mail.sp2.yahoo.com Received: (qmail 74586 invoked by uid 60001); 13 Jun 2012 18:39:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1339612770; bh=FY8yu0o4hQe2M6eICr2jjbNeCvUG+tURo4Jnf8PAS1E=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZTjhAHUdQYMe6X8CxO12k51FZx7wQ5J0MgRlsuDcujP655yNnv9gd+BTVIRX0sVZ+F86TvvQuCoszLB4sl22xJ8P+OoH0rHth3apSL4OrosEwueQkponfnT/ZaE2E0rW7TphxV/DsXSfedfckiQBr4FIlo4eCMb/b3uMhyojXo8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fquw8LR4DK9INxm2NPrg7RdVMgAntmcii/uKoSvOiVh2AKEuExJQ4ujrwuk3IQsxKFakKC819pihdabIFtW/QiOrOhNo6Qp07aDJIzOtZE1gVa4865DXlpyMo+gB9PwMhqp9l7eHJM0btvpAcae9ca6aMojQ23QUZofrSdP0PB0=; X-YMail-OSG: m.ytME4VM1lO2Aq.KGheetXTj3ilmejoM.A01k7hjcLg1pD WTveVjCCc.2POqrtTS8pyRfm6i77ds_sTY8iurflaRmKq96kRT7LUq4awmLa jejYZnNCm5OT8Lg8x.wRJEUkFmPz_Lh9R1GLOm5F.nd_9Dalf8.uJ11gxhHy 3INN4F3YzzGM_74xZjLdtoz._sTB8dufpfhZlFHC1G3z1wGQPONC3WaLjoVa oGZ5vYLQuS.jt6CiT4pyPYsBOmTGwEXoCVQj1EcK1wFTE7t.SbLvUMJT2KyU ONBvkSdZFjiySs0Kyr.4DgxZGCOzQuC5B33LhwRtrXsmA4FORBkamezS71Xt qdR0nPWDNNbiWutEacx9fXvbTl5IatS9c.RfJWzqZjiHGlR__ZLlIoxixomL RZ3m9NI4ZIkRK_e4syjGQ5C3Ep8PFM_QP2CFLerdQKzGy57ciF0hb4bFsL5. LymEcRvyH7RZReQAlukcr_Q-- Received: from [173.57.97.155] by web84508.mail.ne1.yahoo.com via HTTP; Wed, 13 Jun 2012 11:39:30 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: <mailman.613.1339579368.3336.rtgwg@ietf.org> Message-ID: <1339612770.47991.YahooMailNeo@web84508.mail.ne1.yahoo.com> Date: Wed, 13 Jun 2012 11:39:30 -0700 (PDT) From: Ning So <ningso@yahoo.com> Subject: Re: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft To: "rtgwg@ietf.org" <rtgwg@ietf.org> In-Reply-To: <mailman.613.1339579368.3336.rtgwg@ietf.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-20871971-843189509-1339612770=:47991" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ning So <ningso@yahoo.com> List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Jun 2012 18:39:32 -0000 ---20871971-843189509-1339612770=:47991 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Support as co-author.=A0 I am not aware any IPR associated with draft.=0A= =0ANing=0A=0A=0A=0AMessage: 10=0ADate: Wed, 13 Jun 2012 13:31:02 +0900=0AFr= om: "Andrew G. Malis" <agmalis@gmail.com>=0ATo: Alia Atlas <akatlas@gmail.c= om>=0ACc: rtgwg@ietf.org=0ASubject: Re: poll to adopt draft-so-yong-rtgwg-c= l-framework-05 as a WG=0A=A0=A0=A0 draft=0AMessage-ID:=0A=A0=A0=A0 <CAA=3Dd= uU1BcD7-Lh9EfnuA0XJL=3D+XyJTMVJxUSYC=3Dc_jJboeXrvw@mail.gmail.com>=0AConten= t-Type: text/plain; charset=3DISO-8859-1=0A=0AI have read the draft and I s= upport! Plus I am not aware of any IPR in=0Athis draft.=0A=0ACheers,=0AAndy= =0A=0AOn Wed, Jun 13, 2012 at 5:39 AM, Alia Atlas <akatlas@gmail.com> wrote= :=0A> This email is to start a poll and discussion on whether to adopt=0A> = draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft.=0A> Please respond w= ith opinions, comments, and whether you have read the draft.=0A> Last IETF,= there were very few people who had read the draft.=0A>=0A> Authors, please= indicate if there is any IPR associated with this draft.=0A>=0A> Thanks,= =0A> Alia=0A> _______________________________________________=0A> rtgwg mai= ling list=0A> rtgwg@ietf.org=0A> https://www.ietf.org/mailman/listinfo/rtgw= g=0A=0A=0A------------------------------=0A=0AMessage: 11=0ADate: Wed, 13 J= un 2012 11:22:44 +0200=0AFrom: Andr?s Cs?sz?r <Andras.Csaszar@ericsson.com>= =0ATo: Alia Atlas <akatlas@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>,= =0A=A0=A0=A0 "pim-chairs@tools.ietf.org" <pim-chairs@tools.ietf.org>=0ASubj= ect: RE: poll on draft-karan-mofrr-02 to become a WG draft=0AMessage-ID:=0A= =A0=A0=A0 <8DCD771BDA4A394E9BCBA8932E839297783E30F23B@ESESSCMS0363.eemea.er= icsson.se>=0A=A0=A0=A0 =0AContent-Type: text/plain; charset=3D"utf-8"=0A=0A= Hi Alia,=0A=0AMoFRR to me is a kind of applying the LFA idea to multicast, = and also given that implementations already exist (for quite some time now,= if I'm correct), I do support it.=0A=0ATrying to be constructive again, I = would give some feedback for this one, too :-)=0A=0A1. I suggest a little m= ore glue between the text in chapter 7 (non-ECMP mode MoFRR) and the LFA sp= ec. Non-ECMP mode seems very much like the LFA rules, yet they are redefine= d, which is not a problem, but I'd prefer having a similar notation/syntax/= terminology and rules as far as possible. If there are differences, they sh= ould be highlighted.=0A=0A=0A2. Chapter 5, detecting failures. I think we s= hould try to give a little more details. Packet comparison details, what ne= eds to be stored? Complete packet? Packet hash? RTP seq number? ...=0A=0AI = think the "third option", to rely on IGPs is by definition not FRR, so this= should be the last option.=0A=0AThe fourth option is "leveraging connected= link failure". I think this option could be the easiest/most natural appro= ach, and I guess since LoS, BFD and any local DP failure detection mechanis= m is usually tied already to unicast FRR, why not propose this to be the pr= imary option for MoFRR, too? =0A=0A=0A3. Chapter 10: "The MoFRR principle m= ay be applied to MVPNs." Let's give more details, if possible.=0A=0A=0A4. D= ue to mLDP, probably the MPLS WG chairs should be involved, too, not only P= IM.=0A=0A=0A5. Why is the intended status "informational"? Why should it be= different from LFA or remote LFA? I agree the solution practically does no= t require any novel cooperation method from other nodes, which is an advant= age, so there is little to be a "Standard", but that's true for LFA or RLFA= as well. So?=0A=0A=0A6. We often used the terminology "live-live" in other= drafts, such as in MRT. I actually thought that it came from MoFRR, but no= w I did find no trace of it in the doc. Maybe we should add a sentence abou= t it, saying that MoFRR implements what is often called "live-live" protect= ion.=0A=0A=0AI started to realise I'm often too long, sorry for that :-)=0A= =0AAndr?s=0A=0A=0A> -----Original Message-----=0A> From: rtgwg-bounces@ietf= .org [mailto:rtgwg-bounces@ietf.org] On Behalf=0A> Of Alia Atlas=0A> Sent: = 2012. j?nius 12. 22:42=0A> To: rtgwg@ietf.org; pim-chairs@tools.ietf.org=0A= > Subject: poll on draft-karan-mofrr-02 to become a WG draft=0A> =0A> This = email is to start a poll and discussion on whether=0A> draft-karan-mofrr-02= should=0A> become an RTGWG draft.=A0 Please include comments, details, an= d whether=0A> you have=0A> read the draft.=0A> =0A> The earlier version was= presented positively to the PIM WG as well.=0A> =0A> Authors, please indic= ate whether there is any IPR associated with this=0A> draft.=0A> =0A> Thank= s,=0A> Alia=0A> _______________________________________________=0A> rtgwg m= ailing list=0A> rtgwg@ietf.org=0A> https://www.ietf.org/mailman/listinfo/rt= gwg=0A=0A------------------------------=0A=0A______________________________= _________________=0Artgwg mailing list=0Artgwg@ietf.org=0Ahttps://www.ietf.= org/mailman/listinfo/rtgwg=0A=0A=0AEnd of rtgwg Digest, Vol 90, Issue 15=0A= ************************************* ---20871971-843189509-1339612770=:47991 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt"><div><span>Support as= co-author.  I am not aware any IPR associated with draft.</span></div= ><div><br><span></span></div><div><span>Ning<br></span></div><br><div style= =3D"font-family: times new roman, new york, times, serif; font-size: 12pt;"= ><div style=3D"font-family: times new roman, new york, times, serif; font-s= ize: 12pt;"><br>Message: 10<br>Date: Wed, 13 Jun 2012 13:31:02 +0900<br>Fro= m: "Andrew G. Malis" <<a ymailto=3D"mailto:agmalis@gmail.com" href=3D"ma= ilto:agmalis@gmail.com">agmalis@gmail.com</a>><br>To: Alia Atlas <<a = ymailto=3D"mailto:akatlas@gmail.com" href=3D"mailto:akatlas@gmail.com">akat= las@gmail.com</a>><br>Cc: <a ymailto=3D"mailto:rtgwg@ietf.org" href=3D"m= ailto:rtgwg@ietf.org">rtgwg@ietf.org</a><br>Subject: Re: poll to adopt draf= t-so-yong-rtgwg-cl-framework-05 as a WG<br>    draft<br>Message-ID:<br>    <CAA=3DduU1BcD7-Lh9EfnuA0XJL= =3D+XyJTMVJxUSYC=3D<a ymailto=3D"mailto:c_jJboeXrvw@mail.gmail.com" href=3D= "mailto:c_jJboeXrvw@mail.gmail.com">c_jJboeXrvw@mail.gmail.com</a>><br>C= ontent-Type: text/plain; charset=3DISO-8859-1<br><br>I have read the draft = and I support! Plus I am not aware of any IPR in<br>this draft.<br><br>Chee= rs,<br>Andy<br><br>On Wed, Jun 13, 2012 at 5:39 AM, Alia Atlas <<a ymail= to=3D"mailto:akatlas@gmail.com" href=3D"mailto:akatlas@gmail.com">akatlas@g= mail.com</a>> wrote:<br>> This email is to start a poll and discussio= n on whether to adopt<br>> draft-so-yong-rtgwg-cl-framework-05 as an RTG= WG draft.<br>> Please respond with opinions, comments, and whether you h= ave read the draft.<br>> Last IETF, there were very few people who had r= ead the draft.<br>><br>> Authors, please indicate if there is any IPR= associated with this draft.<br>><br>> Thanks,<br>> Alia<br>> _______________________________________________<br>> rtgwg mailing list= <br>> <a ymailto=3D"mailto:rtgwg@ietf.org" href=3D"mailto:rtgwg@ietf.org= ">rtgwg@ietf.org</a><br>> <a href=3D"https://www.ietf.org/mailman/listin= fo/rtgwg" target=3D"_blank">https://www.ietf.org/mailman/listinfo/rtgwg</a>= <br><br><br>------------------------------<br><br>Message: 11<br>Date: Wed,= 13 Jun 2012 11:22:44 +0200<br>From: Andr?s Cs?sz?r <<a ymailto=3D"mailt= o:Andras.Csaszar@ericsson.com" href=3D"mailto:Andras.Csaszar@ericsson.com">= Andras.Csaszar@ericsson.com</a>><br>To: Alia Atlas <<a ymailto=3D"mai= lto:akatlas@gmail.com" href=3D"mailto:akatlas@gmail.com">akatlas@gmail.com<= /a>>, "<a ymailto=3D"mailto:rtgwg@ietf.org" href=3D"mailto:rtgwg@ietf.or= g">rtgwg@ietf.org</a>" <<a ymailto=3D"mailto:rtgwg@ietf.org" href=3D"mai= lto:rtgwg@ietf.org">rtgwg@ietf.org</a>>,<br>    "<a ymail= to=3D"mailto:pim-chairs@tools.ietf.org" href=3D"mailto:pim-chairs@tools.ietf.org">pim-chairs@tools.ietf.org</a>" &= lt;<a ymailto=3D"mailto:pim-chairs@tools.ietf.org" href=3D"mailto:pim-chair= s@tools.ietf.org">pim-chairs@tools.ietf.org</a>><br>Subject: RE: poll on= draft-karan-mofrr-02 to become a WG draft<br>Message-ID:<br>  &n= bsp; <<a ymailto=3D"mailto:8DCD771BDA4A394E9BCBA8932E839297783E30F23B@ES= ESSCMS0363.eemea.ericsson.se" href=3D"mailto:8DCD771BDA4A394E9BCBA8932E8392= 97783E30F23B@ESESSCMS0363.eemea.ericsson.se">8DCD771BDA4A394E9BCBA8932E8392= 97783E30F23B@ESESSCMS0363.eemea.ericsson.se</a>><br>    <= br>Content-Type: text/plain; charset=3D"utf-8"<br><br>Hi Alia,<br><br>MoFRR= to me is a kind of applying the LFA idea to multicast, and also given that= implementations already exist (for quite some time now, if I'm correct), I= do support it.<br><br>Trying to be constructive again, I would give some f= eedback for this one, too :-)<br><br>1. I suggest a little more glue betwee= n the text in chapter 7 (non-ECMP mode MoFRR) and the LFA spec. Non-ECMP mode se= ems very much like the LFA rules, yet they are redefined, which is not a pr= oblem, but I'd prefer having a similar notation/syntax/terminology and rule= s as far as possible. If there are differences, they should be highlighted.= <br><br><br>2. Chapter 5, detecting failures. I think we should try to give= a little more details. Packet comparison details, what needs to be stored?= Complete packet? Packet hash? RTP seq number? ...<br><br>I think the "thir= d option", to rely on IGPs is by definition not FRR, so this should be the = last option.<br><br>The fourth option is "leveraging connected link failure= ". I think this option could be the easiest/most natural approach, and I gu= ess since LoS, BFD and any local DP failure detection mechanism is usually = tied already to unicast FRR, why not propose this to be the primary option = for MoFRR, too? <br><br><br>3. Chapter 10: "The MoFRR principle may be applied to MVPNs." Let's give more details, if possible.<br><br><br>4. = Due to mLDP, probably the MPLS WG chairs should be involved, too, not only = PIM.<br><br><br>5. Why is the intended status "informational"? Why should i= t be different from LFA or remote LFA? I agree the solution practically doe= s not require any novel cooperation method from other nodes, which is an ad= vantage, so there is little to be a "Standard", but that's true for LFA or = RLFA as well. So?<br><br><br>6. We often used the terminology "live-live" i= n other drafts, such as in MRT. I actually thought that it came from MoFRR,= but now I did find no trace of it in the doc. Maybe we should add a senten= ce about it, saying that MoFRR implements what is often called "live-live" = protection.<br><br><br>I started to realise I'm often too long, sorry for t= hat :-)<br><br>Andr?s<br><br><br>> -----Original Message-----<br>> Fr= om: <a ymailto=3D"mailto:rtgwg-bounces@ietf.org" href=3D"mailto:rtgwg-bounces@ietf.org">rtgwg-bounces@ietf.org</a> [mailto:= <a ymailto=3D"mailto:rtgwg-bounces@ietf.org" href=3D"mailto:rtgwg-bounces@i= etf.org">rtgwg-bounces@ietf.org</a>] On Behalf<br>> Of Alia Atlas<br>>= ; Sent: 2012. j?nius 12. 22:42<br>> To: <a ymailto=3D"mailto:rtgwg@ietf.= org" href=3D"mailto:rtgwg@ietf.org">rtgwg@ietf.org</a>; <a ymailto=3D"mailt= o:pim-chairs@tools.ietf.org" href=3D"mailto:pim-chairs@tools.ietf.org">pim-= chairs@tools.ietf.org</a><br>> Subject: poll on draft-karan-mofrr-02 to = become a WG draft<br>> <br>> This email is to start a poll and discus= sion on whether<br>> draft-karan-mofrr-02 should<br>> become an RTGWG= draft.  Please include comments, details, and whether<br>> you ha= ve<br>> read the draft.<br>> <br>> The earlier version was present= ed positively to the PIM WG as well.<br>> <br>> Authors, please indic= ate whether there is any IPR associated with this<br>> draft.<br>> <b= r>> Thanks,<br>> Alia<br>> _____________________________________________= __<br>> rtgwg mailing list<br>> <a ymailto=3D"mailto:rtgwg@ietf.org" = href=3D"mailto:rtgwg@ietf.org">rtgwg@ietf.org</a><br>> <a href=3D"https:= //www.ietf.org/mailman/listinfo/rtgwg" target=3D"_blank">https://www.ietf.o= rg/mailman/listinfo/rtgwg</a><br><br>------------------------------<br><br>= _______________________________________________<br>rtgwg mailing list<br><a= ymailto=3D"mailto:rtgwg@ietf.org" href=3D"mailto:rtgwg@ietf.org">rtgwg@iet= f.org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/rtgwg" target= =3D"_blank">https://www.ietf.org/mailman/listinfo/rtgwg</a><br><br><br>End = of rtgwg Digest, Vol 90, Issue 15<br>*************************************<= br><br><br> </div> </div> </div></body></html> ---20871971-843189509-1339612770=:47991-- From curtis@occnc.com Wed Jun 13 15:11:58 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CC721F846E for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 15:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 74wsPutD9MPC for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 15:11:58 -0700 (PDT) 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 B99A321F846B for <rtgwg@ietf.org>; Wed, 13 Jun 2012 15:11:57 -0700 (PDT) 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 q5DMBrjS087141; Wed, 13 Jun 2012 15:11:53 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206132211.q5DMBrjS087141@gateway.ipv6.occnc.com> To: Alia Atlas <akatlas@gmail.com> From: Curtis Villamizar <curtis@occnc.com> Subject: Re: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft In-reply-to: Your message of "Tue, 12 Jun 2012 16:36:36 EDT." <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> Date: Wed, 13 Jun 2012 18:11:53 -0400 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Jun 2012 22:11:58 -0000 In message <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> Alia Atlas writes: > This is to start a poll and discussion about whether RTGWG should adopt > draft-symmvo-rtgwg-cl-use-cases-00 as a WG draft. > > Please respond with comments and reasoning and if you have read the draft. > At our last meeting, very few people indicated that they had read the draft. > > Authors, please indicate in email whether there is any IPR associated > with the draft. > > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg Alia, I know of no IPR that is associated with this draft. [Co-authors please speak up regarding IPR as well]. btw- support. :-) ... and I did read it. reason for support: contains background information that was pulled from CL requirements and CL framework that is useful to have in an informational document. It is referenced by CL requirements and CL framework to add clarity to CL requirements and CL framework without pulling the entire discussion into those two documents. WG mailing list discussion of the contents would be appreciated by the authors. Note: no pending changes to this document except author affiliations, downcasing a letter in the title: "USe Cases" changes to "Use Cases", and similar one paragraph addition to the acknowledgements as in CL requirements acknowledgements. Curtis From curtis@occnc.com Wed Jun 13 16:42:04 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906CF11E80C7 for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 16:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 ledPgCRxmYL0 for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 16:42:04 -0700 (PDT) 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 B3A7E11E80C0 for <rtgwg@ietf.org>; Wed, 13 Jun 2012 16:42:03 -0700 (PDT) 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 q5DNfxp5088821; Wed, 13 Jun 2012 16:42:00 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206132342.q5DNfxp5088821@gateway.ipv6.occnc.com> To: Alia Atlas <akatlas@gmail.com> From: Curtis Villamizar <curtis@occnc.com> Subject: Re: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft In-reply-to: Your message of "Tue, 12 Jun 2012 16:39:20 EDT." <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> Date: Wed, 13 Jun 2012 19:41:59 -0400 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Jun 2012 23:42:04 -0000 In message <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> Alia Atlas writes: > This email is to start a poll and discussion on whether to adopt > draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft. > Please respond with opinions, comments, and whether you have read the draft. > Last IETF, there were very few people who had read the draft. > > Authors, please indicate if there is any IPR associated with this draft. > > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg Alia, I know of no IPR associated with this draft. I will point out that this draft references two others: draft-villamizar-mpls-tp-multipath, and draft-villamizar-mpls-tp-multipath-te-extn which do have IPR: see http://datatracker.ietf.org/ipr/1593/ . The terms are described in the Licensing Declaration section of the IPR declaration. How this affects draft-so-yong-rtgwg-cl-framework (CL framework) is: 1. Issues of reordering within specific MPLS LSP is discussed as a potential issue in CL framework. Specifically MPLS-TP LSP cannot be reordered. If MPLS-TP LSP are carried within larger LSP, then constraints are placed on those aggregate LSPs. 2. A few solutions are proposed which include: a. Don't do that. Carry MPLS-TP LSPs separately. Don't aggregate MPLS-TP LSPs into bigger LSPs. (Note: has scaling implications, but otherwise fine). b. Refer to draft-villamizar-mpls-tp-multipath for three more options described there. i. MPLS as a Server Layer for MPLS-TP (Section 5.2.1). Expanded on in mpls-tp-multipath-te-extn. ii. MPLS-TP as a Server Layer for MPLS (Section 5.2.2). All core LSP are small and MPLS-TP. MPLS CL at edges used many edge-to-edge components. Ability to load balance at the point of congestion is lost. [Workable but poor solution]. iii. Relax MPLS-TP OAM Requirements (Section 5.2.3). Relax MPLS-TP reordering constraint but maintain order within microflows. Accept very limited OAM error. [Requires no changes except that operator ignore parts of standard in their deployment.] Many operators will tell you that 2a above is just fine. Many operators claim that they have no intention to use MPLS-TP in their core and don't need to further aggregate MPLS-TP LSP in their use of MPLS-TP (or have no intention to use MPLS-TP at all). The IPR is related to one type of forwarding change that is assumed if you opt for 2.b.i above. Since the terms of the IPR are not onerous, that should be a viable option for everyone if they choose it. Also, if you can figure out a different way to accomplish the same thing, then CL framework can remain unchanged but mpls-tp-multipath-te-extn may or may not be affected by the existance of an alternate. For the CL framework it means that a technical issue is raised for which one potential solution has IPR and that solution is described elsewhere. The technical issue remains regardless of the solution set. Other solutions are cited in CL framework. I don't consider that IPR to be related to the CL framework draft, therefore I started by saying "I know of no IPR associated with this draft." That said. Yes/support. :-) ... and I read this one too. Reason to support: The CL framework as it now stands raises numerous known but mostly solvable technical issues that arrise from the set of CL requirements, and cover a number of potential solutions for specific issues. An attempt is made to cover the full set of requirements, enumerating the requirements, categorizing them, and indicating where in the CL framework specific sets of requirements are addressed. The document calls for a number of followup documents to provide greater detail on some issues as well as documents to specify protocol extensions to address groups of related requirements. There is much in the framework document that needs further discussion within the WG, however IMHO the existing CL framework is WG chartered work item and this CL framework is a good start for that WG document. Curtis From curtis@occnc.com Wed Jun 13 16:51:49 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2D921F847F for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 16:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 oysdgSa3VQGQ for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 16:51:49 -0700 (PDT) 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 8263621F8478 for <rtgwg@ietf.org>; Wed, 13 Jun 2012 16:51:44 -0700 (PDT) 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 q5DNpfeR089080; Wed, 13 Jun 2012 16:51:41 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206132351.q5DNpfeR089080@gateway.ipv6.occnc.com> To: Alia Atlas <akatlas@gmail.com> From: Curtis Villamizar <curtis@occnc.com> Subject: Re: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft In-reply-to: Your message of "Tue, 12 Jun 2012 16:39:20 EDT." <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> Date: Wed, 13 Jun 2012 19:51:41 -0400 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Jun 2012 23:51:50 -0000 btw- current version is -06. In message <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> Alia Atlas writes: This email is to start a poll and discussion on whether to adopt draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft. Please respond with opinions, comments, and whether you have read the draft. Last IETF, there were very few people who had read the draft. Authors, please indicate if there is any IPR associated with this draft. Thanks, Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From curtis@occnc.com Wed Jun 13 17:57:40 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B4411E80C2 for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 17:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 caVZuCXmg6Ry for <rtgwg@ietfa.amsl.com>; Wed, 13 Jun 2012 17:57:39 -0700 (PDT) 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 7F70311E80AC for <rtgwg@ietf.org>; Wed, 13 Jun 2012 17:57:39 -0700 (PDT) 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 q5E0vYMg092081; Wed, 13 Jun 2012 17:57:34 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206140057.q5E0vYMg092081@gateway.ipv6.occnc.com> To: curtis@occnc.com From: Curtis Villamizar <curtis@occnc.com> Subject: Re: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft In-reply-to: Your message of "Wed, 13 Jun 2012 19:51:41 EDT." <201206132351.q5DNpfeR089080@gateway.ipv6.occnc.com> Date: Wed, 13 Jun 2012 20:57:34 -0400 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Jun 2012 00:57:40 -0000 My mistake. CL requirements is at -06. CL framework is -05. In message <201206132351.q5DNpfeR089080@gateway.ipv6.occnc.com> Curtis Villamizar writes: btw- current version is -06. In message <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> Alia Atlas writes: This email is to start a poll and discussion on whether to adopt draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft. Please respond with opinions, comments, and whether you have read the draft. Last IETF, there were very few people who had read the draft. Authors, please indicate if there is any IPR associated with this draft. Thanks, Alia _______________________________________________ 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 curtis@occnc.com Thu Jun 14 11:38:14 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674CC21F8738 for <rtgwg@ietfa.amsl.com>; Thu, 14 Jun 2012 11:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 Ks-ACye399el for <rtgwg@ietfa.amsl.com>; Thu, 14 Jun 2012 11:38:14 -0700 (PDT) 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 B52B821F8736 for <rtgwg@ietf.org>; Thu, 14 Jun 2012 11:38:13 -0700 (PDT) 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 q5EIc9eh028042; Thu, 14 Jun 2012 11:38:09 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206141838.q5EIc9eh028042@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: CL requirements - management requirements from CL framework From: Curtis Villamizar <curtis@occnc.com> Date: Thu, 14 Jun 2012 14:38:09 -0400 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Jun 2012 18:38:14 -0000 In reviewing changes to CL framework suggested by Iftkhar, I found some comments that indicate text to be moved to CL requirements. -- remove this - add to CL-req in management section The composite link functions provide component link fault notification and composite link fault notification. Component link fault notification MUST be sent to the management plane. Composite link fault notification MUST be sent to management plane and distribute via link state message in IGP. -- remove this - add to CL-req in management section Operator may want to perform an optimization function such as load balance or energy saving over a composite link, which may conduct some traffic moving from one component link to another. 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. I suggest we reword the original wording above and add the following to CL requirements. MR#+ Component link fault notification MUST be sent to the management plane. MR#+ Composite link fault notification MUST be sent to management plane and distribute via link state message in IGP. MR#+ An operator initiated optimization MUST be performed in a minimally disruptive manner as described in Section [?] Note: Section [?] is where ever we put the description of what we mean by "minimally disruptive", "delay discontinuity", etc. The sentence "The protocol that facilitates this process between two composite link end points is for further study." is not needed in a requirements document. These requirements seem almost obvious. Significant event notifications are always sent to the management plane, but stating these explicitly doesn't hurt. If all load balance changes are to be minimally disruptive as per FR#12, then operator initiated optimization should be assumed to included, but this new requirement could be perceived as covering a very significant management plane initiated optimization. Maybe the existing MR#6 could be more specific regarding what a management plane initiated "optimization process" entails. It currently reads "Management Plane SHOULD provide the means for an operator to initiate an optimization process." I suggest the first two go after the existing MR#5 and the third goes between the existing MR#6 and MR#7. I also suggest that the existing MR#6 be left as is unless someone volunteers a clarification. Curtis From curtis@occnc.com Thu Jun 14 17:36:30 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1200311E8095 for <rtgwg@ietfa.amsl.com>; Thu, 14 Jun 2012 17:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[AWL=-2.375, BAYES_00=-2.599, GB_SUMOF=5, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] 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 AhOHsyEJzFkP for <rtgwg@ietfa.amsl.com>; Thu, 14 Jun 2012 17:36:28 -0700 (PDT) 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 5A9CC11E8083 for <rtgwg@ietf.org>; Thu, 14 Jun 2012 17:36:28 -0700 (PDT) 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 q5F0aF7T036143; Thu, 14 Jun 2012 17:36:15 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206150036.q5F0aF7T036143@gateway.ipv6.occnc.com> To: curtis@occnc.com From: Curtis Villamizar <curtis@occnc.com> Subject: Re: draft-so-yong-rtgwg-cl-framework In-reply-to: Your message of "Sun, 06 May 2012 14:14:03 EDT." <201205061814.q46IE3GQ099189@gateway.ipv6.occnc.com> Date: Thu, 14 Jun 2012 20:36:15 -0400 Cc: Iftekhar Hussain <IHussain@infinera.com>, "rtgwg@ietf.org" <rtgwg@ietf.org> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Jun 2012 00:36:30 -0000 Iftekhar, I'm replying to this email because this email thread accounts for most of the changes that I just made to draft-so-yong-rtgwg-cl-framework. Since the call for support as a WG item is ongoing I will not submit the updates until that call is completed. Briefly the changes to the document are: 1. Author affiliation change for Ning, address change for Lucy. @@ -61,23 +61,17 @@ @@ -107,12 +101,12 @@ 2. Some clarification in "Flow Identification" section resulting from your comments. @@ -474,29 +470,35 @@ 3. A brief summary added to the "Flow Identification" section. @@ -474,29 +470,35 @@ (last addition in that set of diffs) 4. Wording changes suggested in this thread (see inline below). @@ -648,17 +680,18 @@ 5. Significant rewording in "Composite Link in Data Plane" section to reduce redundancy and put the general description of traffic distribution here and issues later, but referencing here. @@ -770,24 +803,26 @@ @@ -795,34 +830,38 @@ 6. Clarified wording about large networks and scalability. @@ -833,12 +872,20 @@ 7. Clarified wording about large routing changes. @@ -851,15 +898,32 @@ 8. Removed redundant description of issues in "Data Plane Challenges" that were already covered in "Flow Identification" section or "Composite Link in Data Plane" section, and moved some text that was not covered in either place. @@ -1391,59 +1455,14 @@ 9. Added clarifications and cross reference to "Very Large LSP" section. @@ -1453,8 +1472,18 @@ 10. Better defined what a "very large microflow" is. @@ -1464,8 +1493,8 @@ 11. Added some text to the acknowledgements. @@ -2506,9 +2535,22 @@ Diffs will be sent in a separate email - too long to attach. The @@ notation above refers to specific diff chunks. Followup to the most recent email is inline. It was pointed out in another thread that some text on carrying IP and LDP is in more than one place and similar enough to be redundant. I'll get that in a next set of changes. Best Regards, Curtis In message <201205061814.q46IE3GQ099189@gateway.ipv6.occnc.com> Curtis Villamizar writes: > > Iftekhar, > > Thank you for the detailed comments. Responses to individual > comments/suggestions are inline. > > This is a long email message, so if I missed anything, please point > out what I missed. > > Please let me know if you are in general agreement with the responses > and if so I'll make specific proposals for replacement text or propose > more detailed action items. > > Best Regards, > > Curtis > > > In message <D7D7AB44C06A2440B716F1F1F5E70AE534638F36@SV-EXDB-PROD1.infinera.com> > Iftekhar Hussain writes: > > > Dear Authors, > > > > Please find below some comments on the > > http://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05. > > > > > > ---------------------------- > > > > 2.1. Flow Identification > > > > "Operator may have other objectives such as ...composite link energy > > saving, and etc. These new requirements are described in > > [I-D.ietf-rtgwg-cl-requirement]" > > > > Comment: > > > > I don't recall any energy saving related requirement (or discussion) > > in the [I-D.ietf-rtgwg-cl-requirement. Suggest removing the text > > "energy saving etc." > > You are entirely correct that there are no energy savings mentioned in > the requirements document. This wording came from one of the other > authors but I think I understand the intent. There is a daily cycle > (and less so a weekly cycle) to traffic levels. During the low > traffic hours (generally late at night for local hours of night) > traffic can be rebalanced to reduce the number of active component > links. Where it is possible to depower interfaces, this could result > in energy savings. > > I'm OK with removing this example, though it is a very good example > and an goal that we should be pursuing. Another option is to add a > "MAY" in the requirements docuemt somewhere that indicates that "Load > balancing MAY be used during sustained low traffic periods to reduce > the number of active component links for the purpose of power > reduction". > > I'll wait for further comments on this before making a suggestion on > how we will proceed. No further comments on the mailing list on this. The requirements was added to CL requirements. > > 2.2. Composite Link in Control Plane > > > > "LDP follows the IGP, therefore failure to forward on the IGP path > > will often result in loss of connectivity if the IGP adjacency is not > > withdrawn when an LDP FEC is refused. This is a pathologic case that > > can occur if LDP is carried natively and there is a high volume of LDP > > traffic. This situation can be avoided by carrying LDP within RSVP-TE > > LSP." > > > > > > Comment: > > > > Is it the loss of connectivity referring to LDP control plane > > connectivity only or LDP signaled LSP data plane or both? > > The bottom line is that admission control cannot be applied to LDP > without loss of connectivity. Complete loss of connectivity for a > subset of traffic, no matter how low its priority, is unacceptable. > > LDP does not support TE. There are two options. Either don't carry > enough LDP traffic such that this situation can occur (this is the > case when a small subset of traffic is high priority traffic carried > within LDP, such as VOIP or enterprise VPN traffic mixed with a much > larger volume of Internet traffic). The alternative is to carry the > LDP traffic within RSVP-TE LSP when enough LDP traffic is aggregated > such that TE is needed. > > The goal was to refer to this problem without going into an > excessively long explanation. If you think it is too brief and > therefore is unclear, then I'll reword it. No further comments so I'm assuming that the wording was adequate as is. > > Comment: > > > > "Composite link capacity is aggregated capacity and MAY be larger than > > individual component link capacity." > > Before the MAY insert "LSP capacity" and the sentence makes more > sense. I'll reread this and see if that is what was intended. Fixed in @@ -648,17 +680,18 @@ (#4 above) > > Composite link aggregate capacity should always be larger than > > individual component link capacity. Did I misunderstand? > > The statement as written is not useful. The sum of positive > quantities is always greater than the quantities being summed. Thanks > for pointing out this statement. I'll look at the context and figure > out the intent. Looked fine after the two word insertion mentioned above. > > "...1. If no other information is available the largest microflow is > > bound by one of the following:" > > > > Suggested text: > > > > If no other information is available the largest microflow is bound > > (i.e., signaling extensions don't indicate a bound) by one of the > > following: > > I'll reword this. The other information could be signaled or > configured. Added this in @@ -648,17 +680,18 @@ last change in the chunk. > > Comment: > > > > Section 2.2 provides architectural guidelines e.g., " ...Available > > capacity in other component links MUST be used to carry impacted > > traffic. The available bandwidth after failure MUST be advertised > > immediately to avoid looped crankback" and provides illustrative > > examples e.g.,"... no microflow larger than 10 Gb/s will be present on > > the RSVP-TE LSP that aggregate traffic across the core, even if the > > core interfaces are 100 Gb/s interfaces." > > Be careful not to take the last sentence out of the context of the > example (where no interface feeding the core is greater than 10 Gb/s). No issue here. > > In contrast, section 2.1 appears to be little bit too vague e.g., " > > ... technique of grouping flows, such as hashing on the flow > > identification criteria, becomes essential to reduce the stored state, > > and is an essential scaling technique. Other means of grouping flows > > may be possible" > > > > Suggestion: > > > > Add some examples which flow identification scheme to use for > > composite links or add a reference to section 4.2 which discusses flow > > identification trade-offs. > > The intent in Section 2.1 is to make three points. First, tracking > every flow is not scalable. Second, IP src/dst address hashing has > proven (in over two decades of experience) to be an excellent way of > identifying groups of flows (for reasons briefly listed). Third, if > you find a better way to identify groups of flows, then use it. > > We don't want to require the use of IP address hashing, but wanted to > strongly encourage its use, given its long history of successful > deployment. > > I'll look at rewording the section. Above comments insired the changes in diff chunk @@ -474,29 +470,35 @@ > > 4.1.4. Requirements for Contained LSP > > > > Comment: > > > > Add reference to specific relevant to requirements in > > I-D.ietf-rtgwg-cl-requirement] similar to section 4.1.2 and 4.1.3. > > OK. The sentence "[I-D.ietf-rtgwg-cl-requirement] calls for new LSP > constraints." needs followup indicating which requirements are being > referred to. The existing text identifies the requirement topics. I don't want to embed the requirement numbers here since the numbers can change. > > 4.2. Data Plane Challenges > > > > Comment: > > > > Minor typo: "very course..." should be "very coarse..." > > Of coarse. How could I miss that? :-) > > I searched for other uses of the word "course" and found quite a few > that should be "coarse". Thanks for the catch. > > > Comment: > > > > "In practice using the MPLS label stack alone has proven too course > > to acheive a reasonably good load balance, due to bin-packing issues > > and discrpencies between signaled bandwidth and actual traffic loads > > on LSP." > > > > Suggest adding a reference to an IETF standard or best practices > > document that discusses these issues. > > OK, if I can find something. This has been discussed on and off on > the mailing lists for about a decade. There may be something in the > original link bundling RFC or elsewhere. That text is gone. The topic is covered in Flow Identification. Another reference to draft-symmvo-rtgwg-cl-use-cases was added. RFC4928 indicates that more than MPLS label stack is needed but doesn't say why. There is a little more detail in the Entropy Label draft (now in last call). > > Comment: > > > > Sections 4.2, 2.1, 2.3, appear to be somewhat redundant. Suggest > > trimming section 2.1 and absorbing that information in section 4.2. > > Thanks for pointing this out. I'll reread and try to reduce > redundancy, using cross references where appropriate rather than > repeating a point. Redundant information in 4.2 was removed. Some information in 4.2 was put into 2.3. This left 2.1 with the background on current flow identification and 2.3 with background on current traffic distribution. > > 3. Architecture Tradeoffs > > > > Comment: > > > > "Composite Link is applicable to large networks, and therefore > > scalability must be a major consideration." > > > > What is a typical definition of a large network? Suggestion: Add an > > example (or a forward reference to section 3.3.1 which has an example) > > Any network that one of your customers wants to build would be a good > example of large. :-) [But not a good definition of large.] > > By "large" we mean the type of networks that service providers or > large content providers are building today. > > In the future we may find that enterprises are building large enough > private networks to have certain scaling problems that had previously > only been experienced by service providers and content providers in > the past. A good example of that in the past is overuse of bridging. > Some of the NSFNET regional networks in the late 1980s used bridging > but experienced severe scaling issues very quickly. It wasn't until > the early to mid 1990s that large enterprises began having similar > problems. > > The point of the phrase "Composite Link is applicable to large > networks" is that if you need parallel links because the single link > capacity je jour is too small, then your network is large relative to > most other networks. Considering the magnitude of "large" where > 10Gb/s links are too small, the phrase "and therefore scalability must > be a major consideration" may seem almost rhetorical to some with > deployment experience with IP networks. > > The reason that the statement here is brief is that there are a number > of IETF base documents dating back to the mid-1990s on the importance > of scalability. These realization came from deployment experience. > Despite this someone occasionally makes a naive comment about > processors getting faster and memory getting larger, ignoring the fact > that comparable grouth with order NlogN or N-squared growth in > computation or memory requirements far outpaces Moore's Law > improvements. > > I think at least one somewhat ancient RFC indicatea that scalability > must be considered in every document in the IETF routing area. If I > find it I'll cite it. It will probably have Brian Carpenter or > Christian Huitman on the author list, making it easier to find. Maybe > Fred Baker. I think it was an IAB or IESG RFC. Best general IAB statement I found was "All designs must scale readily to very many nodes per site and to many millions of sites." in RFC 1958 "Architectural Principles of the Internet" (1996). RFC 2791 "Scalable Routing Design Principles" by Jessica Yu (2000) is very good but focused on BGP. RFC 3439 "Internet Architectural Guidelines" by Randy Bush and David Meyer (2002) was an IAB document about scaling but touched on a lot of topics without driving home any one point very well (IMHO). I didn't add any reference here. I did make changes saying a bit about what a "large network" means. > > 3.1. Scalability Motivations > > > > Comment: > > > > "....a large routing change to be accomplished more quickly," > > > > What is a typical definition of a large routing change? Suggestion: > > Add an example. > > Not entirely serious: Hurricane Katrina resulted in a number of "large > routing changes". There was the collaspse of the Raratan River bridge > in NJ taking out fibers on both sides of the bridge (thought to be > redundant), an earthquake east of San Diego taking out three of four > fiber paths, etc. > > This is again a relative term that has been used for quite some time. > A customer circuit going down or a new customer coming online results > in a tiny routing change. A metro fault may be handled entirely in > the metro and have no effect at all on routing elsewhere in the > provider network or global network. Major fiber outages generally > result in large routing changes. > > In an MPLS context, a large routing change is one that affects a large > number of LSP. A classic example is where one hop along one of two or > three east-west paths across the continental US goes down (or comes > up, though this can be made far less disruptive). Many LSP traverse > the small number of US east-west paths and terminate in a large number > of medium to large sized cities along either coast. > > Again, I'll look at clarifying, but in less words than this response. I added changes giving some limited information about what a large routing change entails in an MPLS network. > > 7.2.5. Dynamic Multipath Balance > > > > Comment: > > > > "...uses a course granularity, the adjustments would have to be > > equally course, in the worst case moving entire LSP" > > > > Minor typo "course" should be "coarse". > > s/course/coarse/ with selective replacement. > > > 7. Required Protocol Extensions and Mechanisms > > > > Comment/suggestion: > > > > Organizing section 7 as a matrix containing something like: > > Requirement#, Existing Mechanisms, Gaps, Ongoing/new extensions..., > > might be more clearer. AT a minimum, add a traceability to each > > requirement in [I-D.ietf-rtgwg-cl-requirement] and the section number > > in framework document that addresses each requirement (or set of > > requirement). > > Section 7.2 groups the requirements but there is no where that lists > every requirement in numeric order and points to where in the grouping > it falls. It should be easy enough to add that. > > At the moment, potential issues with the requirements or in this > document are listed in Section 7.3. This is a different approach, > listing the omissions rather than cross referencing. Ideally we > address all of the issues and drop this section. > > Section 7.4 lists the requirements by protocol or functionality > affected. This as stated in the first paragraph is for the benefit of > implementors. Subsections of 7.4 refers back to the groupings in > subsections of 7.2. It would not be difficult to put in the reverse > cross references (functional group refers to protocol change or > functionality supporting it). I didn't add this cross reference because the requirement numbers change. There is no way to add a tag in the requirements document that would allow a tag to number mapping if the numbers change. Keeping it this way I only have to fix the requirement numbering in Section 7.2 if the CL requirements document changes. > > Is there a minimal set of requirements which must be met to form a > > deployable (useful) composite link based solution? > > That's a great question. > > "Enough to be useful" is interpreted differently by different network > operators deploying a network. For an equipment vendor the best > approach is to plan to implement everything over time under the > assumption that every feature will appear in a check box in someone's > RFI/RFP/RFQ eventually, but ask current key customers which features > to prioritize. That process may yield a different answer for > different equipment vendors, depending on who their current key > customers are. > > BTW- Our friends at Verizon made sure that almost every requirement is > a MUST, so ask them to identify the requirements that they are not > really serious about. Wear protective fireproof undergarments. :-) Did you ever ask? > > ----------------------- > > > > Regards, > > Iftekhar > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From curtis@occnc.com Thu Jun 14 17:39:06 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67FE11E8095 for <rtgwg@ietfa.amsl.com>; Thu, 14 Jun 2012 17:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=1.546, BAYES_00=-2.599, GB_I_LETTER=-2, 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 b29sDI5ep8E4 for <rtgwg@ietfa.amsl.com>; Thu, 14 Jun 2012 17:39:04 -0700 (PDT) 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 5D3E811E8072 for <rtgwg@ietf.org>; Thu, 14 Jun 2012 17:39:04 -0700 (PDT) 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 q5F0coBt036155; Thu, 14 Jun 2012 17:38:50 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206150038.q5F0coBt036155@gateway.ipv6.occnc.com> To: curtis@occnc.com From: Curtis Villamizar <curtis@occnc.com> Subject: Re: draft-so-yong-rtgwg-cl-framework - part 2 - diffs In-reply-to: Your message of "Sun, 06 May 2012 14:14:03 EDT." <201205061814.q46IE3GQ099189@gateway.ipv6.occnc.com> Date: Thu, 14 Jun 2012 20:38:50 -0400 Cc: Iftekhar Hussain <IHussain@infinera.com>, "rtgwg@ietf.org" <rtgwg@ietf.org> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Jun 2012 00:39:06 -0000 In a prior email I wrote: Diffs will be sent in a separate email - too long to attach. Here they are: Index: draft-so-yong-rtgwg-cl-framework.xml =================================================================== RCS file: /home/cvs/CVS-occnc/customers/ietf/rtg-cl/draft-so-yong-rtgwg-cl-framework.xml,v retrieving revision 1.10 diff -u -w -r1.10 draft-so-yong-rtgwg-cl-framework.xml --- draft-so-yong-rtgwg-cl-framework.xml 7 Mar 2012 21:35:14 -0000 1.10 +++ draft-so-yong-rtgwg-cl-framework.xml 14 Jun 2012 20:46:17 -0000 @@ -61,23 +61,17 @@ <?rfc inline="yes" ?> <rfc category="info" ipr="trust200902" - docName="draft-so-yong-rtgwg-cl-framework-05"> + docName="draft-so-yong-rtgwg-cl-framework-06-preview1"> <front> <title abbrev="Composite Link Framework"> Composite Link Framework in Multi Protocol Label Switching (MPLS) - Verizon + fullname="So Ning" initials="S." surname="Ning"> + Tata Communications
- - 2400 N. Glenville Ave. - Richardson, TX - 75082 - - +1 972-729-7905 - ning.so@verizonbusiness.com + ning.so@tatacommunications.com
@@ -107,12 +101,12 @@ Huawei USA
- 1700 Alma Dr. Suite 500 + 5340 Legacy Dr. Plano, TX - 75075 + 75025 - +1 469-229-5387 - lucyyong@huawei.com + +1 469-277-5837 + lucy.yong@huawei.com
@@ -380,7 +374,8 @@ described in greater detail than given requirements alone. -
+
Traffic mapping to component links is a data plane @@ -399,17 +394,18 @@ - Operator may have other objectives such as placing a - bidirectional flow or LSP on the same component link in - both direction, load balance over component links, composite - link energy saving, and etc. These new requirements are - described in . + The network operator may have other objectives such as + placing a bidirectional flow or LSP on the same component + link in both direction, load balance over component links, + composite link energy saving, and etc. These new + requirements are described in . @@ -474,29 +470,35 @@ flow identification. If some LSP may require strict packet ordering but those LSP cannot be distinguished from others, then only the top label can be used as a flow identifier. - If only the top label is used, then there may not be - adequate flow granularity to accomplish well balanced - traffic distribution and it will not be possible to carry - LSP that are larger than any individual component link. + If only the top label is used (for example, as specified by + when the "all-ones" component + described in is not used), then + there may not be adequate flow granularity to accomplish + well balanced traffic distribution and it will not be + possible to carry LSP that are larger than any individual + component link. The number of flows can be extremely large. This may be the case when the entire label stack is used and is always the case when IP addresses are used in provider networks - carrying Internet traffic. Current practice at the time of - writing were documented in and - . These practices as described, - make use of IP addresses. The common practices were - extended to include the MPLS label stack and the common - practice of looking at IP addresses within the MPLS payload. - These extended practices are described in and due to - their impact on pseudowires without a PWE3 Control Word. + carrying Internet traffic. Current practice for native IP + load balancing at the time of writing were documented in + , . These + practices as described, make use of IP addresses. The + common practices were extended to include the MPLS label + stack and the common practice of looking at IP addresses + within the MPLS payload. These extended practices are + described in and due to their impact on pseudowires + without a PWE3 Control Word. Additional detail on current + multipath practices can be found in the appendices of . - Using only the top label supports too course a traffic + Using only the top label supports too coarse a traffic balance. Using the full label stack or IP addresses as flow identification provides a sufficiently fine traffic balance, but is capable of identifying such a high number of distinct @@ -506,9 +508,39 @@ technique. Other means of grouping flows may be possible. + + In summary: + + + Load balancing using only the MPLS label stack provides + too coarse a granularity of load balance. + + + Tracking every flow is not scalable due to the extremely + large number of flows in provider networks. + + + Existing techniques, IP source and destination hash in + particular, have proven in over two decades of + experience to be an excellent way of identifying groups + of flows. + + + If a better way to identify groups of flows is + discovered, then that method can be used. + + + IP address hashing is not required, but use of this + technique is strongly encouraged given the technique's + long history of successful deployment. + + + +
-
+
A composite Link is advertised as a single logical interface @@ -648,17 +680,18 @@ - Composite link capacity is aggregated capacity and MAY be - larger than individual component link capacity. Any - aggregated LSP can determine a bounds on the largest - microflow that could be carried and this constraint can be - handled as follows. + Composite link capacity is aggregated capacity. LSP + capacity MAY be larger than individual component link + capacity. Any aggregated LSP can determine a bounds on the + largest microflow that could be carried and this constraint + can be handled as follows. - If no other information is available the largest + If no information is available through signaling, + management plane, or configuration, the largest microflow is bound by one of the following: @@ -770,24 +803,26 @@
-
+
- The traffic over a composite link is distributed over - individual component links. Traffic distribution may be - determined by or constrained by control plane or management - plane. Traffic distribution may be changed due to component - link status change, subject to constraints imposed by either - the management plane or control plane. The distribution - function is local to the routers in which a composite link - belongs to and is not specified here. - + The data plane must first identify groups of flows. Flow + identification is covered in . + Having identified groups of flows the groups must be placed + on individual component links. This second step is called + traffic distribution or traffic placement. The two steps + together are known as traffic balancing or load balancing. + + + + Traffic distribution may be determined by or constrained by + control plane or management plane. Traffic distribution may + be changed due to component link status change, subject to + constraints imposed by either the management plane or + control plane. The distribution function is local to the + routers in which a composite link belongs to and is not + specified here. @@ -795,34 +830,38 @@ differentiate multicast traffic vs. unicast traffic. - + + In order to maintain scalability, existing data plane + forwarding retains state associated with the top label only. + The use of flow group identification is in a second step in + the forwarding process. Data plane forwarding makes use of + the top label to select a composite link, or a group of + components within a composite link or for the case where an + LSP is pinned (see ), a specific + component link. For those LSP for which the LSP selects + only the composite link or a group of components within a + composite link, the load balancing makes use of the flow + group identification. + - + + The most common traffic placement techniques uses the a flow + group identification as an index into a table. The table + provides an indirection. The number of bits of hash is + constrained to keep table size small. While this is not the + best technique, it is the most common. Better techniques + exist but they are outside the scope of this document and + some are considered proprietary. + - + + Requirements to limit frequency of load balancing can be + adhered to by keeping track of when a flow group was last + moved and imposing a minimum period before that flow group + can be moved again. This is straightforward for a table + approach. For other approaches it may be less + straightforward but is acheivable. +
@@ -833,12 +872,20 @@ Scalability and stability are critical considerations in - protocol design where protocols may be used in a large - network. Composite Link is applicable to large networks, and - therefore scalability must be a major consideration. Some of - the requirements of Composite Link require additional - information to be carried in situations where component links - differ in some significant way. + protocol design where protocols may be used in a large network + such as today's service provider networks. Composite Link is + applicable to networks which are large enough to require that + traffic be split over multiple paths. Scalability is a major + consideration for networks that reach a capacity large enough + to require Composite Link. + + + + Some of the requirements of Composite Link could potentially + have a negative impact on scalability. For example, Composite + Link requires additional information to be carried in + situations where component links differ in some significant + way.
). Reducing the - amount of information allows the exchange of information - during a large routing change to be accomplished more - quickly, and simplifying route computation improves - convergence time after very significant network faults which - cannot be handled by preprovisioned or precomputed - protection mechanisms. Aggregating smaller LSP into larger - LSP is a means to reduce RSVP-TE signaling (see ). + ). + + + + In an MPLS network large routing changes can occur when a + single fault occurs. For example, a single fault may impact + a very large number of LSP traversing a given link. As new + LSP are signaled to avoid the fault, resources are consumed + elsewhere, and routing protocol announcements must flood the + resource changes. If protection is in place, there is less + urgency to converging quickly. If multiple faults occur + that are not covered by shared risk groups (SRG), then some + protection may fail, adding urgency to converging quickly + even where protection was deployed. + + + + Reducing the amount of information allows the exchange of + information during a large routing change to be accomplished + more quickly and simplifies route computation. Simplifying + route computation improves convergence time after very + significant network faults which cannot be handled by + preprovisioned or precomputed protection mechanisms. + Aggregating smaller LSP into larger LSP is a means to reduce + path computation load and reduce RSVP-TE signaling (see + ). @@ -905,7 +969,7 @@ sensible choices regarding the amount of change to link parameters that require link readvertisement. For example, if delay measurements include queuing delay, then a much - more course granularity of delay measurement would be called + more coarse granularity of delay measurement would be called for than if the delay does not include queuing and is dominated by geographic delay (speed of light delay). @@ -1133,7 +1197,7 @@ path symmetry requires extensions and is particularly challenging for very large LSP (see - target="sect.path-symmetry" />), + ), accommodating a very wide range of requirements among @@ -1142,7 +1206,7 @@ reduce scalability if a large number of aggregates are used to provide a too fine a reflection of the requirements in the contained LSP (see - target="sect.contained-lsp" />), + ), backwards compatibility is somewhat limited due to the @@ -1150,13 +1214,13 @@ provide too little information regarding their configured default behavior, and legacy LSP which provide too little information regarding their requirements (see - target="sect.compat" />), + ), data plane challenges include those of accommodating very large LSP, large microflows, traffic ordering constraints imposed by a subsent of LSP, and accounting for IP and LDP - traffic (see target="sect.dp-challenge" />). + traffic (see ). @@ -1391,59 +1455,14 @@ title="Data Plane Challenges"> - Regardless of implementation choices, there are tradeoffs - regarding the flow identification granularity. If flow - identification granularity is very course, such as using top - lable only, LSP larger than the size of a component link are - not feasible. In practice using the MPLS label stack alone - has proven too course to acheive a reasonably good load - balance, due to bin-packing issues and discrpencies between - signaled bandwidth and actual traffic loads on LSP. If a - finer granualrity is based on IP addresses, then a table - approach is infeasible, due to the extremely large number of - IP address pairs found in Internet traffic. The preferred - implementation has been to use a hash over the IP address - pairs to provide a fine granuarity but with a feasible - implementation. Where hashing is used, the hash itself can - be done at ingress and placed in a fat-pw label or entropy - label (see ) to avoid - performing the deeper MPLS header parse in the network core - and the hash in the network core. - - - - Other implementations are possible, but must still face the - problem that not using IP addresses provides a granularity - which is too course and using IP host pairs yields a table - size which is so impractical as to be considered an - infeasible solution. This section assumes that this problem - is addressed, but makes no assumption as to the - implementation. Where a hash based solution is mentioned, - such mention should be considered a reference approach, not - a requirement. - - - - In order to maintain scalability, existing data plane - forwarding retains state associated with the top label only. - Data plane forwarding makes use of the top label to select a - composite link, or a group of components within a composite - link or for the case where an LSP is pinned (see ), a specific component link. For those - LSP for which the LSP selects only the composite link or a - group of components within a composite link, the load - balancing may make use of the entire label stack and in some - cases may make use of information in the payload, though no - state on specific contained LSP is retained. - - - - Load balancing makes use of techniques which allow large - sets of flows to be moved to rearrange traffic. These large - sets of flows may be at a finer granularity than contained - LSP. Requirements to limit frequency of load balancing - rearrangement can be adhered to by constraining the - frequency at which these large sets of flows are moved. + Flow identification is briefly discussed in + . + Traffic distribution is briefly discussed in + . + + This section discusses issues specific to particular + requirements specified in + .
+ + + Very large LSP can be accommodated as long as they can be + subdivided (see ). A + very large LSP cannot have a requirement for symetric + paths unless complex protocol extensions are proposed (see + and ).
@@ -1464,8 +1493,8 @@ Within a very large LSP there may be very large - microflows, or very large flows which cannot be further - subdivided for other reasons. Flows which cannot be + microflows. A very large microflow is a very large flows + which cannot be further subdivided. Flows which cannot be subdivided must be no larger that the capacity of any single component. @@ -2122,8 +2151,8 @@ FR#11 explicitly calls for dynamic load balancing similar to existing adaptive multipath. In implementations where - flow identification uses a course granularity, the - adjustments would have to be equally course, in the worst + flow identification uses a coarse granularity, the + adjustments would have to be equally coarse, in the worst case moving entire LSP. The impact of flow identification granularity and potential adaptive multipath approaches may need to be documented in greater detail than provided @@ -2506,9 +2535,22 @@ Authors would like to thank Adrian Farrel, Fred Jounay, Yuji - Kamite for his extensive comments and suggestions, Ron Bonica, - Nabil Bitar, Eric Gray, Lou Berger, and Kireeti Kompella for - their reviews and great suggestions. + Kamite for his extensive comments and suggestions regarding + early versions of this document, Ron Bonica, Nabil Bitar, + Eric Gray, Lou Berger, and Kireeti Kompella for their reviews + of early versions and great suggestions. + + + Authors would like to thank Iftekhar Hussain for review and + suggestions regarding recent versions of this document. + + + In the interest of full disclosure of affiliation and in the + interest of acknowledging sponsorship, past affiliations of + authors are noted. Much of the work done by Ning So occurred + while Ning was at Verizon. Much of the work done by Curtis + Villamizar occurred while at Infinera. Infinera continues to + sponsor this work on a consulting basis.
From curtis@occnc.com Fri Jun 15 11:25:12 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 7162A11E809F for ; Fri, 15 Jun 2012 11:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 tagged_above=-999 required=5 tests=[AWL=-2.109, BAYES_00=-2.599, GB_SUMOF=5, 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 EbdsVNne16Dt for ; Fri, 15 Jun 2012 11:25:10 -0700 (PDT) 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 C710911E80BB for ; Fri, 15 Jun 2012 11:25:08 -0700 (PDT) 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 q5FIOUs4013120; Fri, 15 Jun 2012 11:24:30 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206151824.q5FIOUs4013120@gateway.ipv6.occnc.com> To: Iftekhar Hussain From: Curtis Villamizar Subject: Re: draft-so-yong-rtgwg-cl-framework In-reply-to: Your message of "Sun, 20 May 2012 17:39:19 -0000." Date: Fri, 15 Jun 2012 14:24:30 -0400 Cc: "rtgwg@ietf.org" 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: Fri, 15 Jun 2012 18:25:12 -0000 Iftekhar, I replied to the wrong message. This one came after the one I replied to. I just looked this over and it appears that I didn't miss anything in this reply. Regarding your last point: [...] It would not be difficult to put in the reverse cross references (functional group refers to protocol change or functionality supporting it). [Iftekhar] OK. That would be great. One thing I noticed was that some of the sections in this document are referring to specific requirements that are being addressed while others don't Actually it is not difficult in principle to provide cross references but it is somewhat time consuming. It also turns out that it isn't very useful. The reason is that documents covering many topics must consider certain groups of requirements such as backward compatibility and general network management. I did the exercise briefly, but didn't expand the text yet. I'll post diffs if it seems to add more clarity than bloat. Regarding "One thing I noticed was that some of the sections in this document are referring to specific requirements that are being addressed while others don't": A number of requirements are cited because they highly problematic or have non-obvious implications. Many such citations are within the "New Challenges" section in cases were a particular requirement is problematic or in the "Existing Mechanisms" or "Mechanisms Proposed in Other Documents" because existing or proposed mechanisms address some requirements or because the mechanisms are incomplete in some way, failing to address some requirements. There are citations in "Required Document Coverage" to indicate specific requirements or sets of requirements that are going to need a document to cover the approach taken to address them. This is the full set of requirements cited before "7.1. Brief Review of Requirements". FR#10 and FR#12 are cited as requiring the existing soft preemption [RFC5712]. The delay and jitter requirements are listed to emphasize that there are quite a few or them and not all in the same section followed by the sentence "Requirement FR#17 is particularly problematic, calling for constraints on jitter" and then discussion. FR#18 and FR#19 are cited because they indicate local control which FR#21 gives control to the ingress. FR#21 is again cited because it specifies symetrical traffic, a requirement which may not be acheivable with very large LSP. This is the full set of requirements cited after "7.1. Brief Review of Requirements". Most of these citations are in "7.2. Required Document Coverage". The CL framework document would be very long if it attempted to fully address all of the issues. The following are sentences pulled from the text. FR#11 explicitly calls for dynamic load balancing. IGP-TE and RSVP-TE extensions are needed to support frequency of load balancing rearrangement called for in FR#13, and FR#15-FR#17. Lower layer to upper layer communication called for in FR#7 and FR#20. The behavior of hash methods used in classic multipath needs to be described in terms of FR#12 which calls for minimally disruptive load adjustments. Protocol extensions are needed to support dynamic load balance as called for to meet FR#22 (path symmetry) and to meet FR#11 (dynamic placement of flows). Extending LDP is called for in DR#2. DR#5 calls for Composite Link to span multiple network topologies. There is one citation in "7.3. Open Issues Regarding Requirements". The following sentence appears in that section: "We may need a performance section in this document to specifically address #DR6 (fast convergence), and #DR7 (fast worst case failure convergence), though we do already have scalability discussion." The paragraph is asking whether we need a document to cover this or whether the coverage in the framework is sufficient. If we have a separate document, then we can pull some text out of the CL framework. Curtis In message Iftekhar Hussain writes: Curtis, Thank you for the detailed responses. Please see in-line. Best regards, Iftekhar -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Sunday, May 06, 2012 11:14 AM To: Iftekhar Hussain Cc: rtgwg@ietf.org Subject: Re: draft-so-yong-rtgwg-cl-framework Iftekhar, Thank you for the detailed comments. Responses to individual comments/suggestions are inline. This is a long email message, so if I missed anything, please point out what I missed. Please let me know if you are in general agreement with the responses and if so I'll make specific proposals for replacement text or propose more detailed action items. Best Regards, Curtis In message Iftekhar Hussain writes: > Dear Authors, > > Please find below some comments on the > http://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05. > > > ---------------------------- > > 2.1. Flow Identification > > "Operator may have other objectives such as ...composite link energy > saving, and etc. These new requirements are described in > [I-D.ietf-rtgwg-cl-requirement]" > > Comment: > > I don't recall any energy saving related requirement (or discussion) > in the [I-D.ietf-rtgwg-cl-requirement. Suggest removing the text > "energy saving etc." You are entirely correct that there are no energy savings mentioned in the requirements document. This wording came from one of the other authors but I think I understand the intent. There is a daily cycle (and less so a weekly cycle) to traffic levels. During the low traffic hours (generally late at night for local hours of night) traffic can be rebalanced to reduce the number of active component links. Where it is possible to depower interfaces, this could result in energy savings. I'm OK with removing this example, though it is a very good example and an goal that we should be pursuing. Another option is to add a "MAY" in the requirements docuemt somewhere that indicates that "Load balancing MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction". [Iftekhar] OK. The latter option seems reasonable. I'll wait for further comments on this before making a suggestion on how we will proceed. > 2.2. Composite Link in Control Plane > > "LDP follows the IGP, therefore failure to forward on the IGP path > will often result in loss of connectivity if the IGP adjacency is not > withdrawn when an LDP FEC is refused. This is a pathologic case that > can occur if LDP is carried natively and there is a high volume of LDP > traffic. This situation can be avoided by carrying LDP within RSVP-TE > LSP." > > > Comment: > > Is it the loss of connectivity referring to LDP control plane > connectivity only or LDP signaled LSP data plane or both? The bottom line is that admission control cannot be applied to LDP without loss of connectivity. Complete loss of connectivity for a subset of traffic, no matter how low its priority, is unacceptable. LDP does not support TE. There are two options. Either don't carry enough LDP traffic such that this situation can occur (this is the case when a small subset of traffic is high priority traffic carried within LDP, such as VOIP or enterprise VPN traffic mixed with a much larger volume of Internet traffic). The alternative is to carry the LDP traffic within RSVP-TE LSP when enough LDP traffic is aggregated such that TE is needed. The goal was to refer to this problem without going into an excessively long explanation. If you think it is too brief and therefore is unclear, then I'll reword it. [Iftekhar] OK. I believe a brief rewording to help clarify this point would be useful. > Comment: > > "Composite link capacity is aggregated capacity and MAY be larger than > individual component link capacity." Before the MAY insert "LSP capacity" and the sentence makes more sense. I'll reread this and see if that is what was intended. > Composite link aggregate capacity should always be larger than > individual component link capacity. Did I misunderstand? The statement as written is not useful. The sum of positive quantities is always greater than the quantities being summed. Thanks for pointing out this statement. I'll look at the context and figure out the intent. [Iftekhar] Okay. That will be great. Thanks. > > "...1. If no other information is available the largest microflow is > bound by one of the following:" > > Suggested text: > > If no other information is available the largest microflow is bound > (i.e., signaling extensions don't indicate a bound) by one of the > following: I'll reword this. The other information could be signaled or configured. [Iftekhar] OK. > Comment: > > Section 2.2 provides architectural guidelines e.g., " ...Available > capacity in other component links MUST be used to carry impacted > traffic. The available bandwidth after failure MUST be advertised > immediately to avoid looped crankback" and provides illustrative > examples e.g.,"... no microflow larger than 10 Gb/s will be present on > the RSVP-TE LSP that aggregate traffic across the core, even if the > core interfaces are 100 Gb/s interfaces." Be careful not to take the last sentence out of the context of the example (where no interface feeding the core is greater than 10 Gb/s). > In contrast, section 2.1 appears to be little bit too vague e.g., " > ... technique of grouping flows, such as hashing on the flow > identification criteria, becomes essential to reduce the stored state, > and is an essential scaling technique. Other means of grouping flows > may be possible" > > Suggestion: > > Add some examples which flow identification scheme to use for > composite links or add a reference to section 4.2 which discusses flow > identification trade-offs. The intent in Section 2.1 is to make three points. First, tracking every flow is not scalable. Second, IP src/dst address hashing has proven (in over two decades of experience) to be an excellent way of identifying groups of flows (for reasons briefly listed). Third, if you find a better way to identify groups of flows, then use it. We don't want to require the use of IP address hashing, but wanted to strongly encourage its use, given its long history of successful deployment. I'll look at rewording the section. [Iftekhar] Okay. I believe that will be helpful to the reader. > 4.1.4. Requirements for Contained LSP > > Comment: > > Add reference to specific relevant to requirements in > I-D.ietf-rtgwg-cl-requirement] similar to section 4.1.2 and 4.1.3. OK. The sentence "[I-D.ietf-rtgwg-cl-requirement] calls for new LSP constraints." needs followup indicating which requirements are being referred to. [Iftekhar] OK. Thanks. > 4.2. Data Plane Challenges > > Comment: > > Minor typo: "very course..." should be "very coarse..." Of coarse. How could I miss that? :-) I searched for other uses of the word "course" and found quite a few that should be "coarse". Thanks for the catch. [Iftekhar] OK > Comment: > > "In practice using the MPLS label stack alone has proven too course > to acheive a reasonably good load balance, due to bin-packing issues > and discrpencies between signaled bandwidth and actual traffic loads > on LSP." > > Suggest adding a reference to an IETF standard or best practices > document that discusses these issues. OK, if I can find something. This has been discussed on and off on the mailing lists for about a decade. There may be something in the original link bundling RFC or elsewhere. [Iftekhar] OK > Comment: > > Sections 4.2, 2.1, 2.3, appear to be somewhat redundant. Suggest > trimming section 2.1 and absorbing that information in section 4.2. Thanks for pointing this out. I'll reread and try to reduce redundancy, using cross references where appropriate rather than repeating a point. [Iftekhar] OK > 3. Architecture Tradeoffs > > Comment: > > "Composite Link is applicable to large networks, and therefore > scalability must be a major consideration." > > What is a typical definition of a large network? Suggestion: Add an > example (or a forward reference to section 3.3.1 which has an example) Any network that one of your customers wants to build would be a good example of large. :-) [But not a good definition of large.] By "large" we mean the type of networks that service providers or large content providers are building today. In the future we may find that enterprises are building large enough private networks to have certain scaling problems that had previously only been experienced by service providers and content providers in the past. A good example of that in the past is overuse of bridging. Some of the NSFNET regional networks in the late 1980s used bridging but experienced severe scaling issues very quickly. It wasn't until the early to mid 1990s that large enterprises began having similar problems. The point of the phrase "Composite Link is applicable to large networks" is that if you need parallel links because the single link capacity je jour is too small, then your network is large relative to most other networks. Considering the magnitude of "large" where 10Gb/s links are too small, the phrase "and therefore scalability must be a major consideration" may seem almost rhetorical to some with deployment experience with IP networks. The reason that the statement here is brief is that there are a number of IETF base documents dating back to the mid-1990s on the importance of scalability. These realization came from deployment experience. Despite this someone occasionally makes a naive comment about processors getting faster and memory getting larger, ignoring the fact that comparable grouth with order NlogN or N-squared growth in computation or memory requirements far outpaces Moore's Law improvements. I think at least one somewhat ancient RFC indicatea that scalability must be considered in every document in the IETF routing area. If I find it I'll cite it. It will probably have Brian Carpenter or Christian Huitman on the author list, making it easier to find. Maybe Fred Baker. I think it was an IAB or IESG RFC. [Iftekhar] OK. I understand the difficulty. > 3.1. Scalability Motivations > > Comment: > > "....a large routing change to be accomplished more quickly," > > What is a typical definition of a large routing change? Suggestion: > Add an example. Not entirely serious: Hurricane Katrina resulted in a number of "large routing changes". There was the collaspse of the Raratan River bridge in NJ taking out fibers on both sides of the bridge (thought to be redundant), an earthquake east of San Diego taking out three of four fiber paths, etc. This is again a relative term that has been used for quite some time. A customer circuit going down or a new customer coming online results in a tiny routing change. A metro fault may be handled entirely in the metro and have no effect at all on routing elsewhere in the provider network or global network. Major fiber outages generally result in large routing changes. In an MPLS context, a large routing change is one that affects a large number of LSP. A classic example is where one hop along one of two or three east-west paths across the continental US goes down (or comes up, though this can be made far less disruptive). Many LSP traverse the small number of US east-west paths and terminate in a large number of medium to large sized cities along either coast. Again, I'll look at clarifying, but in less words than this response. [Iftekhar] OK. I will leave to your discretion. May be have a "typical" today large network numbers? > 7.2.5. Dynamic Multipath Balance > > Comment: > > "...uses a course granularity, the adjustments would have to be > equally course, in the worst case moving entire LSP" > > Minor typo "course" should be "coarse". s/course/coarse/ with selective replacement. [Iftekhar] OK. :) > 7. Required Protocol Extensions and Mechanisms > > Comment/suggestion: > > Organizing section 7 as a matrix containing something like: > Requirement#, Existing Mechanisms, Gaps, Ongoing/new extensions..., > might be more clearer. AT a minimum, add a traceability to each > requirement in [I-D.ietf-rtgwg-cl-requirement] and the section number > in framework document that addresses each requirement (or set of > requirement). Section 7.2 groups the requirements but there is no where that lists every requirement in numeric order and points to where in the grouping it falls. It should be easy enough to add that. At the moment, potential issues with the requirements or in this document are listed in Section 7.3. This is a different approach, listing the omissions rather than cross referencing. Ideally we address all of the issues and drop this section. Section 7.4 lists the requirements by protocol or functionality affected. This as stated in the first paragraph is for the benefit of implementors. Subsections of 7.4 refers back to the groupings in subsections of 7.2. It would not be difficult to put in the reverse cross references (functional group refers to protocol change or functionality supporting it). [Iftekhar] OK. That would be great. One thing I noticed was that some of the sections in this document are referring to specific requirements that are being addressed while others don't > Is there a minimal set of requirements which must be met to form a > deployable (useful) composite link based solution? That's a great question. "Enough to be useful" is interpreted differently by different network operators deploying a network. For an equipment vendor the best approach is to plan to implement everything over time under the assumption that every feature will appear in a check box in someone's RFI/RFP/RFQ eventually, but ask current key customers which features to prioritize. That process may yield a different answer for different equipment vendors, depending on who their current key customers are. BTW- Our friends at Verizon made sure that almost every requirement is a MUST, so ask them to identify the requirements that they are not really serious about. Wear protective fireproof undergarments. :-) [Iftekhar] OK, :) > ----------------------- > > Regards, > Iftekhar From curtis@occnc.com Fri Jun 15 11:45:44 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 5E6E021F8642 for ; Fri, 15 Jun 2012 11:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 PMV6PGVsjjHh for ; Fri, 15 Jun 2012 11:45:43 -0700 (PDT) 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 D80F121F8645 for ; Fri, 15 Jun 2012 11:45:42 -0700 (PDT) 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 q5FIjZ8d014753; Fri, 15 Jun 2012 11:45:35 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206151845.q5FIjZ8d014753@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: draft-so-yong-rtgwg-cl-framework-06-preview2 From: Curtis Villamizar Date: Fri, 15 Jun 2012 14:45:35 -0400 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: Fri, 15 Jun 2012 18:45:44 -0000 RTGWG, Below are diffs mostly to address comments about IP & LDP coverage being in two places and a little redundant. I think those comments came a while ago from Lucy (in private email) but I refiled the email and left a comment in the XML and an editor window open to remind myself. Text on IP&LDP was moved around and consolidated. In private email a while ago Lucy reminded me that Entropy Label was changed back to using a reserved label. This is addressed in the very last diff chunk. Diff chunk @@ -420,16 +420,16 @@ just reads better IMO. I also snuck in the deletion of an old comment that explained why a chunk of text was deleted a long time ago. BTW- I think we are at the point (long past the point) where most or all correspondence among co-authors about this set of drafts should Cc the RTGWG mailing list. Curtis Index: draft-so-yong-rtgwg-cl-framework.xml =================================================================== RCS file: /home/cvs/CVS-occnc/customers/ietf/rtg-cl/draft-so-yong-rtgwg-cl-framework.xml,v retrieving revision 1.12 diff -u -w -r1.12 draft-so-yong-rtgwg-cl-framework.xml --- draft-so-yong-rtgwg-cl-framework.xml 14 Jun 2012 21:39:20 -0000 1.12 +++ draft-so-yong-rtgwg-cl-framework.xml 15 Jun 2012 18:12:21 -0000 @@ -61,7 +61,7 @@ + docName="draft-so-yong-rtgwg-cl-framework-06-preview2"> @@ -420,16 +420,16 @@ </t> <t> a pseudowire (PW) <xref target="RFC3985" /> identified - by an MPLS label, + by an MPLS PW label, </t> <t> a flow or group of flows within a pseudowire (PW) - <xref target="RFC6391" /> identified by an MPLS label, + <xref target="RFC6391" /> identified by an MPLS flow label, </t> <t> - an entropy flow in an LSP + a flow or flow group in an LSP <xref target="I-D.ietf-mpls-entropy-label" /> - identified by an MPLS label, + identified by an MPLS entropy label, </t> <t> all traffic between a pair of IP hosts, identified by an @@ -632,37 +632,15 @@ When an LSP is signaled using RSVP-TE, the LSP MUST be placed on the component link that meets the LSP criteria indicated in the signaling message. - <!-- deleting - obvious restatement of requirements - - Since the composite link brings some unique - characteristics, some signaling protocol extensions are - expected to facilitate the composite link to place LSP to - a proper component link. Several cases may be considered - as below. Signaling extension for configuring such LSP is - for further study. - --> </t> <t> When an LSP is signaled using LDP, the LSP MUST be placed on the component link that meets the LSP criteria, if such a - component link is available. LDP follows the IGP, therefore - failure to forward on the IGP path will often result in loss - of connectivity if the IGP adjacency is not withdrawn when - an LDP FEC is refused. This is a pathologic case that can - occur if LDP is carried natively and there is a high volume - of LDP traffic. This situation can be avoided by carrying - LDP within RSVP-TE LSP. - </t> - - <t> - <!-- the following needs to be considered by the WG --> - LDP traffic engineering is specifically disallowed by <xref - target="RFC3468" />. It may be possible to support - multi-topology IGP extensions to accommodate more than one - set of criteria. If so, the additional IGP could be bound - to the forwarding criteria, and the LDP FEC bound to a - specific IGP instance, inheriting the forwarding criteria. - {Note: WG needs to discuss this.] + component link is available. LDP does not support traffic + engineering capabilities, imposing restrictions on LDP use + of Composite Link. See <xref target="sect.ldp-limitations" + /> for further details. </t> <t> @@ -671,12 +649,12 @@ links. The route computing engine may select one group of component links for a LSP. The routing protocol MUST make this grouping available in the TE-LSDB. The route - computation MUST be extended to include only the capacity of - groups within a composite link which meet LSP criteria. The - signaling protocol MUST be able to indicate either the - criteria, or which groups may be used. A composite link - MUST place the LSP on a component link or group which meets - or exceeds the LSP criteria. + computation used in RSVP-TE MUST be extended to include only + the capacity of groups within a composite link which meet + LSP criteria. The signaling protocol MUST be able to + indicate either the criteria, or which groups may be used. + A composite link MUST place the LSP on a component link or + group which meets or exceeds the LSP criteria. </t> <t> @@ -1561,7 +1539,7 @@ <t> <xref target="I-D.ietf-rtgwg-cl-requirement" /> requires that native IP and native LDP be accommodated. In some - network, a subset of services may be carried as native IP + networks, a subset of services may be carried as native IP or carried as native LDP. Today this may be accommodated by the network operator estimating the contribution of IP and LDP and configuring a lower set of available bandwidth @@ -1595,6 +1573,11 @@ is a subset). </t> + </section> + + <section anchor="sect.ldp-limitations" + title="IP and LDP Limitations"> + <t> IP does not offer traffic engineering. LDP cannot be extended to offer traffic engineering <xref @@ -1602,11 +1585,35 @@ engineered fallback to an alternate path for IP and LDP traffic if resources are not adequate for the IP and/or LDP traffic alone on a given link in the primary path. - The only option available to LDP is to fail to forward a - FEC if conditions are not met for that FEC. In either LDP - DOD mode or DU mode, another path will be used if - available in a manner similar to a link which is present - in the IGP but does not have LDP enabled. + The only option for IP and LDP would be to declare the + link down. Declaring a link down due to resource + exhaustion would reduce traffic to zero and eliminate the + resource exhaustion. This would cause oscillations and is + therefore not a viable solution. + </t> + + <t> + Congestion caused by IP or LDP traffic loads is a + pathologic case that can occur if IP and/or LDP are + carried natively and there is a high volume of IP or LDP + traffic. This situation can be avoided by carrying IP and + LDP within RSVP-TE LSP. + </t> + + <t> + <!-- the following needs to be considered by the WG --> + It is also not possible to route LDP traffic differently + for different FEC. LDP traffic engineering is + specifically disallowed by <xref target="RFC3468" />. It + may be possible to support multi-topology IGP extensions + to accommodate more than one set of criteria. If so, the + additional IGP could be bound to the forwarding criteria, + and the LDP FEC bound to a specific IGP instance, + inheriting the forwarding criteria. Alternately, one IGP + instance can be used and the LDP SPF can make use of the + constraints, such as delay and jitter, for a given LDP + FEC. [Note: WG needs to discuss this and decide first + whether to solve this at all and then if so, how.] </t> </section> @@ -1905,19 +1912,18 @@ <xref target="I-D.ietf-mpls-entropy-label" /> provides a means for a LER to put an additional label known as an entropy label on the MPLS label stack. As defined, - only the LER can add the entropy label and this label must - be at the bottom of stack. + only the LER can add the entropy label. </t> <t> - If the bottom of stack restriction on entropy labels were to - be relaxed, then core LSR could add entropy labels based on - deep packet inspection and place the entropy label just - below the label being acted on. This would be helpful in - situations where the label stack depth to which load - distribution can operate is limited by implementation or is - limited for other reasons such as carrying both MPLS-TP and - MPLS with entropy labels within the same hierarchical LSP. + Core LSR acting as LER for aggregated LSP can add entropy + labels based on deep packet inspection and place an entropy + label indicator (ELI) and entropy label (EL) just below the + label being acted on. This would be helpful in situations + where the label stack depth to which load distribution can + operate is limited by implementation or is limited for other + reasons such as carrying both MPLS-TP and MPLS with entropy + labels within the same hierarchical LSP. </t> </section> From curtis@occnc.com Fri Jun 15 12:25:58 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E82A11E80CD for <rtgwg@ietfa.amsl.com>; Fri, 15 Jun 2012 12:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.560, 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 8eQ3xm5me4wj for <rtgwg@ietfa.amsl.com>; Fri, 15 Jun 2012 12:25:57 -0700 (PDT) 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 82A4511E80C7 for <rtgwg@ietf.org>; Fri, 15 Jun 2012 12:25:57 -0700 (PDT) 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 q5FJPn7l020338; Fri, 15 Jun 2012 12:25:49 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206151925.q5FJPn7l020338@gateway.ipv6.occnc.com> To: curtis@occnc.com From: Curtis Villamizar <curtis@occnc.com> Subject: Re: CL requirements - management requirements from CL framework In-reply-to: Your message of "Thu, 14 Jun 2012 14:38:09 EDT." <201206141838.q5EIc9eh028042@gateway.ipv6.occnc.com> Date: Fri, 15 Jun 2012 15:25:49 -0400 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Jun 2012 19:25:58 -0000 RTGWG, There was no comment on this. The three management requirements below were added. Section [?] in the text below is replaced with "Section 4.3" in the txt version of the draft. No one so far has offerred a clarification to what was MR#6 which currently reads "Management Plane SHOULD provide the means for an operator to initiate an optimization process." Curtis In message <201206141838.q5EIc9eh028042@gateway.ipv6.occnc.com> Curtis Villamizar writes: > > In reviewing changes to CL framework suggested by Iftkhar, I found > some comments that indicate text to be moved to CL requirements. > > -- remove this - add to CL-req in management section > > The composite link functions provide component link fault > notification and composite link fault notification. Component > link fault notification MUST be sent to the management > plane. Composite link fault notification MUST be sent to > management plane and distribute via link state message in IGP. > > -- remove this - add to CL-req in management section > > Operator may want to perform an optimization function such as > load balance or energy saving over a composite link, which may > conduct some traffic moving from one component link to > another. 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. > > I suggest we reword the original wording above and add the following > to CL requirements. > > MR#+ Component link fault notification MUST be sent to the > management plane. > > MR#+ Composite link fault notification MUST be sent to management > plane and distribute via link state message in IGP. > > MR#+ An operator initiated optimization MUST be performed in a > minimally disruptive manner as described in Section [?] > > Note: Section [?] is where ever we put the description of what we mean > by "minimally disruptive", "delay discontinuity", etc. > > The sentence "The protocol that facilitates this process between two > composite link end points is for further study." is not needed in a > requirements document. > > These requirements seem almost obvious. Significant event > notifications are always sent to the management plane, but stating > these explicitly doesn't hurt. If all load balance changes are to be > minimally disruptive as per FR#12, then operator initiated > optimization should be assumed to included, but this new requirement > could be perceived as covering a very significant management plane > initiated optimization. > > Maybe the existing MR#6 could be more specific regarding what a > management plane initiated "optimization process" entails. It > currently reads "Management Plane SHOULD provide the means for an > operator to initiate an optimization process." > > I suggest the first two go after the existing MR#5 and the third goes > between the existing MR#6 and MR#7. I also suggest that the existing > MR#6 be left as is unless someone volunteers a clarification. > > Curtis From IHussain@infinera.com Fri Jun 15 13:55:15 2012 Return-Path: <IHussain@infinera.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9038B21F845E for <rtgwg@ietfa.amsl.com>; Fri, 15 Jun 2012 13:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 kws32l-l+FhZ for <rtgwg@ietfa.amsl.com>; Fri, 15 Jun 2012 13:55:13 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8D94821F85C0 for <rtgwg@ietf.org>; Fri, 15 Jun 2012 13:55:13 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0283.003; Fri, 15 Jun 2012 13:55:13 -0700 From: Iftekhar Hussain <IHussain@infinera.com> To: "curtis@occnc.com" <curtis@occnc.com> Subject: RE: draft-so-yong-rtgwg-cl-framework - part 2 - diffs Thread-Topic: draft-so-yong-rtgwg-cl-framework - part 2 - diffs Thread-Index: AQHNSo9GAbQNJ0Gto0Cljgw/PXPqb5b73LRA Date: Fri, 15 Jun 2012 20:55:12 +0000 Message-ID: <D7D7AB44C06A2440B716F1F1F5E70AE534658F14@SV-EXDB-PROD1.infinera.com> References: Your message of "Sun, 06 May 2012 14:14:03 EDT." <201205061814.q46IE3GQ099189@gateway.ipv6.occnc.com> <201206150038.q5F0coBt036155@gateway.ipv6.occnc.com> In-Reply-To: <201206150038.q5F0coBt036155@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" <rtgwg@ietf.org> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Jun 2012 20:55:15 -0000 Curtis, Thanks for the follow up. These changes address my comments. Regards, Iftekhar -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com]=20 Sent: Thursday, June 14, 2012 5:39 PM To: curtis@occnc.com Cc: Iftekhar Hussain; rtgwg@ietf.org Subject: Re: draft-so-yong-rtgwg-cl-framework - part 2 - diffs In a prior email I wrote: Diffs will be sent in a separate email - too long to attach. Here they are: Index: draft-so-yong-rtgwg-cl-framework.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/cvs/CVS-occnc/customers/ietf/rtg-cl/draft-so-yong-rtgwg-cl-= framework.xml,v retrieving revision 1.10 diff -u -w -r1.10 draft-so-yong-rtgwg-cl-framework.xml --- draft-so-yong-rtgwg-cl-framework.xml 7 Mar 2012 21:35:14 -0000 1.10 +++ draft-so-yong-rtgwg-cl-framework.xml 14 Jun 2012 20:46:17 -0000 @@ -61,23 +61,17 @@ <?rfc inline=3D"yes" ?> =20 <rfc category=3D"info" ipr=3D"trust200902" - docName=3D"draft-so-yong-rtgwg-cl-framework-05"> + docName=3D"draft-so-yong-rtgwg-cl-framework-06-preview1"> =20 <front> <title abbrev=3D"Composite Link Framework"> Composite Link Framework in Multi Protocol Label Switching (MPLS)</t= itle> =20 <author - fullname=3D"So Ning" initials=3D"N." surname=3D"So"> - <organization>Verizon</organization> + fullname=3D"So Ning" initials=3D"S." surname=3D"Ning"> + <organization>Tata Communications</organization> <address> - <postal> - <street>2400 N. Glenville Ave.</street> - <city>Richardson, TX</city> - <code>75082</code> - </postal> - <phone>+1 972-729-7905</phone> - <email>ning.so@verizonbusiness.com</email> + <email>ning.so@tatacommunications.com</email> </address> </author> =20 @@ -107,12 +101,12 @@ <organization>Huawei USA</organization> <address> <postal> - <street>1700 Alma Dr. Suite 500</street> + <street>5340 Legacy Dr.</street> <city>Plano, TX</city> - <code>75075</code> + <code>75025</code> </postal> - <phone>+1 469-229-5387</phone> - <email>lucyyong@huawei.com</email> + <phone>+1 469-277-5837</phone> + <email>lucy.yong@huawei.com</email> </address> </author> =20 @@ -380,7 +374,8 @@ described in greater detail than given requirements alone. </t> =20 - <section title=3D"Flow Identification"> + <section anchor=3D"sect.flow-id" + title=3D"Flow Identification"> =20 <t> Traffic mapping to component links is a data plane @@ -399,17 +394,18 @= @ </t> =20 <t> - Operator may have other objectives such as placing a - bidirectional flow or LSP on the same component link in - both direction, load balance over component links, composite - link energy saving, and etc. These new requirements are - described in <xref target=3D"I-D.ietf-rtgwg-cl-requirement" - />. + The network operator may have other objectives such as + placing a bidirectional flow or LSP on the same component + link in both direction, load balance over component links, + composite link energy saving, and etc. These new + requirements are described in <xref + target=3D"I-D.ietf-rtgwg-cl-requirement" />. </t> =20 <!-- - The feasibility of symetric paths for all flows is questionable! - Perhaps the emphasis on this (mis)feature should be reduced. + The feasibility of symetric paths for all flows is + questionable! Perhaps the emphasis on this (mis)feature in + the above paragraph should be reduced. --> =20 <t> @@ -474,29 +470,35 @@ flow identification. If some LSP may require strict packet ordering but those LSP cannot be distinguished from others, then only the top label can be used as a flow identifier. - If only the top label is used, then there may not be - adequate flow granularity to accomplish well balanced - traffic distribution and it will not be possible to carry - LSP that are larger than any individual component link. + If only the top label is used (for example, as specified by + <xref target=3D"RFC4201" /> when the "all-ones" component + described in <xref target=3D"RFC4201" /> is not used), then + there may not be adequate flow granularity to accomplish + well balanced traffic distribution and it will not be + possible to carry LSP that are larger than any individual + component link. </t> =20 <t> The number of flows can be extremely large. This may be the case when the entire label stack is used and is always the case when IP addresses are used in provider networks - carrying Internet traffic. Current practice at the time of - writing were documented in <xref target=3D"RFC2991" /> and - <xref target=3D"RFC2992" />. These practices as described, - make use of IP addresses. The common practices were - extended to include the MPLS label stack and the common - practice of looking at IP addresses within the MPLS payload. - These extended practices are described in <xref - target=3D"RFC4385" /> and <xref target=3D"RFC4928" /> due to - their impact on pseudowires without a PWE3 Control Word. + carrying Internet traffic. Current practice for native IP + load balancing at the time of writing were documented in + <xref target=3D"RFC2991" />, <xref target=3D"RFC2992" />. These + practices as described, make use of IP addresses. The + common practices were extended to include the MPLS label + stack and the common practice of looking at IP addresses + within the MPLS payload. These extended practices are + described in <xref target=3D"RFC4385" /> and <xref + target=3D"RFC4928" /> due to their impact on pseudowires + without a PWE3 Control Word. Additional detail on current + multipath practices can be found in the appendices of <xref + target=3D"I-D.symmvo-rtgwg-cl-use-cases" />. </t> =20 <t> - Using only the top label supports too course a traffic + Using only the top label supports too coarse a traffic balance. Using the full label stack or IP addresses as flow identification provides a sufficiently fine traffic balance, but is capable of identifying such a high number of distinct @@ -506,9 = +508,39 @@ technique. Other means of grouping flows may be possible. </t> =20 + <t> + In summary: + <list style=3D"numbers"> + <t> + Load balancing using only the MPLS label stack provides + too coarse a granularity of load balance. + </t> + <t> + Tracking every flow is not scalable due to the extremely + large number of flows in provider networks. + </t> + <t> + Existing techniques, IP source and destination hash in + particular, have proven in over two decades of + experience to be an excellent way of identifying groups + of flows. + </t> + <t> + If a better way to identify groups of flows is + discovered, then that method can be used. + </t> + <t> + IP address hashing is not required, but use of this + technique is strongly encouraged given the technique's + long history of successful deployment. + </t> + </list> + </t> + </section> =20 - <section title=3D"Composite Link in Control Plane"> + <section anchor=3D"sect.control-plane" + title=3D"Composite Link in Control Plane"> =20 <t> A composite Link is advertised as a single logical interface @@ -648,17= +680,18 @@ </t> =20 <t> - Composite link capacity is aggregated capacity and MAY be - larger than individual component link capacity. Any - aggregated LSP can determine a bounds on the largest - microflow that could be carried and this constraint can be - handled as follows. + Composite link capacity is aggregated capacity. LSP + capacity MAY be larger than individual component link + capacity. Any aggregated LSP can determine a bounds on the + largest microflow that could be carried and this constraint + can be handled as follows. </t> =20 <t> <list style=3D"numbers"> <t> - If no other information is available the largest + If no information is available through signaling, + management plane, or configuration, the largest microflow is bound by one of the following: <list style=3D"letters"> <t> @@ -770,24 +803,26 @@ =20 </section> =20 - <section title=3D"Composite Link in Data Plane"> + <section anchor=3D"sect.data-plane" + title=3D"Composite Link in Data Plane"> =20 <t> - The traffic over a composite link is distributed over - individual component links. Traffic distribution may be - determined by or constrained by control plane or management - plane. Traffic distribution may be changed due to component - link status change, subject to constraints imposed by either - the management plane or control plane. The distribution - function is local to the routers in which a composite link - belongs to and is not specified here. - <!-- corouted LSP are coordinated by the PATH/RESV - - However, if a bi-directional LSP is required to be placed - on the same component link in both directions, the routers - at both composite link end points need incorporation in - determining the component link for the LSP. The protocol - extension of that is for further study. - --> + The data plane must first identify groups of flows. Flow + identification is covered in <xref target=3D"sect.flow-id" />. + Having identified groups of flows the groups must be placed + on individual component links. This second step is called + traffic distribution or traffic placement. The two steps + together are known as traffic balancing or load balancing. + </t> + + <t> + Traffic distribution may be determined by or constrained by + control plane or management plane. Traffic distribution may + be changed due to component link status change, subject to + constraints imposed by either the management plane or + control plane. The distribution function is local to the + routers in which a composite link belongs to and is not + specified here. </t> =20 <t> @@ -795,34 +830,38 @@ differentiate multicast traffic vs. unicast traffic. </t> =20 - <!-- protection already covered - - A component link in a composite link may fail - independently. The routers at a composite link MUST maintain - each component link status. Two routers may use the control - plane to sync up a component link state. When a component link - fails, the routers of a composite link MUST re-assign impacted - flows to other active component links in minimal disruptive - manner. This is local function and do not incorporate with LSP - head-end routers. - --> + <t> + In order to maintain scalability, existing data plane + forwarding retains state associated with the top label only. + The use of flow group identification is in a second step in + the forwarding process. Data plane forwarding makes use of + the top label to select a composite link, or a group of + components within a composite link or for the case where an + LSP is pinned (see <xref target=3D"RFC4201" />), a specific + component link. For those LSP for which the LSP selects + only the composite link or a group of components within a + composite link, the load balancing makes use of the flow + group identification. + </t> =20 - <!-- remove this - add to CL-req in management section - The composite link functions provide component link fault - notification and composite link fault notification. Component - link fault notification MUST be sent to the management - plane. Composite link fault notification MUST be sent to - management plane and distribute via link state message in IGP. - --> + <t> + The most common traffic placement techniques uses the a flow + group identification as an index into a table. The table + provides an indirection. The number of bits of hash is + constrained to keep table size small. While this is not the + best technique, it is the most common. Better techniques + exist but they are outside the scope of this document and + some are considered proprietary. + </t> =20 - <!-- remove this - add to CL-req in management section - Operator may want to perform an optimization function such as - load balance or energy saving over a composite link, which may - conduct some traffic moving from one component link to - another. 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. - --> + <t> + Requirements to limit frequency of load balancing can be + adhered to by keeping track of when a flow group was last + moved and imposing a minimum period before that flow group + can be moved again. This is straightforward for a table + approach. For other approaches it may be less + straightforward but is acheivable. + </t> =20 </section> =20 @@ -833,12 +872,20 @@ =20 <t> Scalability and stability are critical considerations in - protocol design where protocols may be used in a large - network. Composite Link is applicable to large networks, and - therefore scalability must be a major consideration. Some of - the requirements of Composite Link require additional - information to be carried in situations where component links - differ in some significant way. + protocol design where protocols may be used in a large network + such as today's service provider networks. Composite Link is + applicable to networks which are large enough to require that + traffic be split over multiple paths. Scalability is a major + consideration for networks that reach a capacity large enough + to require Composite Link. + </t> + + <t> + Some of the requirements of Composite Link could potentially + have a negative impact on scalability. For example, Composite + Link requires additional information to be carried in + situations where component links differ in some significant + way. </t> =20 <section anchor=3D"sect.scalability" @@ -851,15 +898,32 @@ adequate to meet requirements. Routing information is aggregated to reduce the amount of information exchange related to routing and to simplify route computation (see - <xref target=3D"sect.routing-tradeoff" />). Reducing the - amount of information allows the exchange of information - during a large routing change to be accomplished more - quickly, and simplifying route computation improves - convergence time after very significant network faults which - cannot be handled by preprovisioned or precomputed - protection mechanisms. Aggregating smaller LSP into larger - LSP is a means to reduce RSVP-TE signaling (see <xref - target=3D"sect.signaling-tradeoff" />). + <xref target=3D"sect.routing-tradeoff" />). + </t> + + <t> + In an MPLS network large routing changes can occur when a + single fault occurs. For example, a single fault may impact + a very large number of LSP traversing a given link. As new + LSP are signaled to avoid the fault, resources are consumed + elsewhere, and routing protocol announcements must flood the + resource changes. If protection is in place, there is less + urgency to converging quickly. If multiple faults occur + that are not covered by shared risk groups (SRG), then some + protection may fail, adding urgency to converging quickly + even where protection was deployed. + </t> + + <t> + Reducing the amount of information allows the exchange of + information during a large routing change to be accomplished + more quickly and simplifies route computation. Simplifying + route computation improves convergence time after very + significant network faults which cannot be handled by + preprovisioned or precomputed protection mechanisms. + Aggregating smaller LSP into larger LSP is a means to reduce + path computation load and reduce RSVP-TE signaling (see + <xref target=3D"sect.signaling-tradeoff" />). </t> =20 <t> @@ -905,7 +969,7 @@ sensible choices regarding the amount of change to link parameters that require link readvertisement. For example, if delay measurements include queuing delay, then a much - more course granularity of delay measurement would be called + more coarse granularity of delay measurement would be called for than if the delay does not include queuing and is dominated by geographic delay (speed of light delay). </t> @@ -1133,7 +1197,7 @@ <t> path symmetry requires extensions and is particularly challenging for very large LSP (see - target=3D"sect.path-symmetry" />), + <xref target=3D"sect.path-symmetry" />), </t> <t> accommodating a very wide range of requirements among @@ -1142,7 +120= 6,7 @@ reduce scalability if a large number of aggregates are used to provide a too fine a reflection of the requirements in the contained LSP (see - target=3D"sect.contained-lsp" />), + <xref target=3D"sect.contained-lsp" />), </t> <t> backwards compatibility is somewhat limited due to the @@ -1150,13 +1= 214,13 @@ provide too little information regarding their configured default behavior, and legacy LSP which provide too little information regarding their requirements (see - target=3D"sect.compat" />), + <xref target=3D"sect.compat" />), </t> <t> data plane challenges include those of accommodating very large LSP, large microflows, traffic ordering constraints imposed by a subsent of LSP, and accounting for IP and LDP - traffic (see target=3D"sect.dp-challenge" />). + traffic (see <xref target=3D"sect.dp-challenge" />). </t> </list> </t> @@ -1391,59 +1455,14 @@ title=3D"Data Plane Challenges"> =20 <t> - Regardless of implementation choices, there are tradeoffs - regarding the flow identification granularity. If flow - identification granularity is very course, such as using top - lable only, LSP larger than the size of a component link are - not feasible. In practice using the MPLS label stack alone - has proven too course to acheive a reasonably good load - balance, due to bin-packing issues and discrpencies between - signaled bandwidth and actual traffic loads on LSP. If a - finer granualrity is based on IP addresses, then a table - approach is infeasible, due to the extremely large number of - IP address pairs found in Internet traffic. The preferred - implementation has been to use a hash over the IP address - pairs to provide a fine granuarity but with a feasible - implementation. Where hashing is used, the hash itself can - be done at ingress and placed in a fat-pw label or entropy - label (see <xref target=3D"sect.entropy" />) to avoid - performing the deeper MPLS header parse in the network core - and the hash in the network core. - </t> - - <t> - Other implementations are possible, but must still face the - problem that not using IP addresses provides a granularity - which is too course and using IP host pairs yields a table - size which is so impractical as to be considered an - infeasible solution. This section assumes that this problem - is addressed, but makes no assumption as to the - implementation. Where a hash based solution is mentioned, - such mention should be considered a reference approach, not - a requirement. - </t> - - <t> - In order to maintain scalability, existing data plane - forwarding retains state associated with the top label only. - Data plane forwarding makes use of the top label to select a - composite link, or a group of components within a composite - link or for the case where an LSP is pinned (see <xref - target=3D"RFC4201" />), a specific component link. For those - LSP for which the LSP selects only the composite link or a - group of components within a composite link, the load - balancing may make use of the entire label stack and in some - cases may make use of information in the payload, though no - state on specific contained LSP is retained. - </t> - - <t> - Load balancing makes use of techniques which allow large - sets of flows to be moved to rearrange traffic. These large - sets of flows may be at a finer granularity than contained - LSP. Requirements to limit frequency of load balancing - rearrangement can be adhered to by constraining the - frequency at which these large sets of flows are moved. + Flow identification is briefly discussed in + <xref target=3D"sect.flow-id" />. + Traffic distribution is briefly discussed in + <xref target=3D"sect.data-plane" />. + + This section discusses issues specific to particular + requirements specified in + <xref target=3D"I-D.ietf-rtgwg-cl-requirement" />. </t> =20 <section anchor=3D"sect.large-lsp" @@ -1453,8 +1472,18 @@ Very large LSP may exceed the capacity of any single component of a composite link. In some cases contained LSP may exceed the capacity of any single component. - These LSP require the use of the equivalent of the - all-ones component of a link bundle. + These LSP may the use of the equivalent of the all-ones + component of a link bundle, or may use a subset of + components which meet the LSP requirements. + </t> + + <t> + Very large LSP can be accommodated as long as they can be + subdivided (see <xref target=3D"sect.large-flows" />). A + very large LSP cannot have a requirement for symetric + paths unless complex protocol extensions are proposed (see + <xref target=3D"sect.control-plane" /> and <xref + target=3D"sect.path-symmetry" />). </t> =20 </section> @@ -1464,8 +1493,8 @@ =20 <t> Within a very large LSP there may be very large - microflows, or very large flows which cannot be further - subdivided for other reasons. Flows which cannot be + microflows. A very large microflow is a very large flows + which cannot be further subdivided. Flows which cannot be subdivided must be no larger that the capacity of any single component. </t> @@ -2122,8 +2151,8 @@ <t> FR#11 explicitly calls for dynamic load balancing similar to existing adaptive multipath. In implementations where - flow identification uses a course granularity, the - adjustments would have to be equally course, in the worst + flow identification uses a coarse granularity, the + adjustments would have to be equally coarse, in the worst case moving entire LSP. The impact of flow identification granularity and potential adaptive multipath approaches may need to be documented in greater detail than provided @@ -2506,9 = +2535,22 @@ =20 <t> Authors would like to thank Adrian Farrel, Fred Jounay, Yuji - Kamite for his extensive comments and suggestions, Ron Bonica, - Nabil Bitar, Eric Gray, Lou Berger, and Kireeti Kompella for - their reviews and great suggestions. + Kamite for his extensive comments and suggestions regarding + early versions of this document, Ron Bonica, Nabil Bitar, + Eric Gray, Lou Berger, and Kireeti Kompella for their reviews + of early versions and great suggestions. + </t> + <t> + Authors would like to thank Iftekhar Hussain for review and + suggestions regarding recent versions of this document. + </t> + <t> + In the interest of full disclosure of affiliation and in the + interest of acknowledging sponsorship, past affiliations of + authors are noted. Much of the work done by Ning So occurred + while Ning was at Verizon. Much of the work done by Curtis + Villamizar occurred while at Infinera. Infinera continues to + sponsor this work on a consulting basis. </t> =20 </section> From IHussain@infinera.com Fri Jun 15 13:59:39 2012 Return-Path: <IHussain@infinera.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9921F8642 for <rtgwg@ietfa.amsl.com>; Fri, 15 Jun 2012 13:59:39 -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=[AWL=-1.000, 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 DJ5iPLQE0sCW for <rtgwg@ietfa.amsl.com>; Fri, 15 Jun 2012 13:59:39 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 375AB21F8637 for <rtgwg@ietf.org>; Fri, 15 Jun 2012 13:59:39 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0283.003; Fri, 15 Jun 2012 13:59:38 -0700 From: Iftekhar Hussain <IHussain@infinera.com> To: Alia Atlas <akatlas@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org> Subject: RE: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft Thread-Topic: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft Thread-Index: AQHNSypdD4Gk0UjPw0eBUYjx5sfDDJb73Q6A Date: Fri, 15 Jun 2012 20:59:38 +0000 Message-ID: <D7D7AB44C06A2440B716F1F1F5E70AE534658F27@SV-EXDB-PROD1.infinera.com> References: <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> In-Reply-To: <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Jun 2012 20:59:39 -0000 Support Thanks, Iftekhar -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lia Atlas Sent: Tuesday, June 12, 2012 1:37 PM To: rtgwg@ietf.org Subject: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft This is to start a poll and discussion about whether RTGWG should adopt draft-symmvo-rtgwg-cl-use-cases-00 as a WG draft. Please respond with comments and reasoning and if you have read the draft. At our last meeting, very few people indicated that they had read the draft= . Authors, please indicate in email whether there is any IPR associated with = the draft. Thanks, Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From IHussain@infinera.com Fri Jun 15 14:00:06 2012 Return-Path: <IHussain@infinera.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A582821F8637 for <rtgwg@ietfa.amsl.com>; Fri, 15 Jun 2012 14:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 4C0v3K+96icZ for <rtgwg@ietfa.amsl.com>; Fri, 15 Jun 2012 14:00:06 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1301A21F864E for <rtgwg@ietf.org>; Fri, 15 Jun 2012 14:00:06 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0283.003; Fri, 15 Jun 2012 14:00:06 -0700 From: Iftekhar Hussain <IHussain@infinera.com> To: Alia Atlas <akatlas@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org> Subject: RE: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft Thread-Topic: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft Thread-Index: AQHNSypd1KnA8J9IbEyKuphQIvDQNJb73UHA Date: Fri, 15 Jun 2012 21:00:05 +0000 Message-ID: <D7D7AB44C06A2440B716F1F1F5E70AE534658F38@SV-EXDB-PROD1.infinera.com> References: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> In-Reply-To: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Jun 2012 21:00:06 -0000 Support Thanks, Iftekhar -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lia Atlas Sent: Tuesday, June 12, 2012 1:39 PM To: rtgwg@ietf.org Subject: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft This email is to start a poll and discussion on whether to adopt draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft. Please respond with opinions, comments, and whether you have read the draft= . Last IETF, there were very few people who had read the draft. Authors, please indicate if there is any IPR associated with this draft. Thanks, Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From ietf-ipr@ietf.org Mon Jun 18 08:50:49 2012 Return-Path: <ietf-ipr@ietf.org> 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 3B2CE21F86E1; Mon, 18 Jun 2012 08:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 vh+PJNWL0yJX; Mon, 18 Jun 2012 08:50:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E02221F86D8; Mon, 18 Jun 2012 08:50:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat <ietf-ipr@ietf.org> To: Gabor.Sandor.Enyedi@ericsson.com, akatlas@juniper.net, rkebler@juniper.net, Andras.Csaszar@ericsson.com, russwh@cisco.com, mike@mshand.org.uk, maciek@bgp.nu Subject: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120618155048.18575.97874.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2012 08:50:48 -0700 Cc: adrian@olddog.co.uk, stbryant@cisco.com, ipr-announce@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Jun 2012 15:50:49 -0000 Dear Gabor Sandor Envedi, Alia Atlas, Robert Kebler, Andras Csaszar, Russ W= hite, Mike Shand, Maciek Konstantynowicz: An IPR disclosure that pertains to your Internet-Draft entitled "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees" (draf= t- ietf-rtgwg-mrt-frr-architecture) was submitted to the IETF Secretariat on 2012-06-18 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1801/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01.""); The IETF Secretariat From lucy.yong@huawei.com Mon Jun 18 11:24:24 2012 Return-Path: <lucy.yong@huawei.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4470521F84F0 for <rtgwg@ietfa.amsl.com>; Mon, 18 Jun 2012 11:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVbAt-agbQCv for <rtgwg@ietfa.amsl.com>; Mon, 18 Jun 2012 11:24:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9821621F84E7 for <rtgwg@ietf.org>; Mon, 18 Jun 2012 11:24:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHA22089; Mon, 18 Jun 2012 14:24:23 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 18 Jun 2012 11:22:05 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 18 Jun 2012 11:22:02 -0700 From: Lucy yong <lucy.yong@huawei.com> To: Alia Atlas <akatlas@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org> Subject: RE: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft Thread-Topic: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft Thread-Index: AQHNSNt4exAwZosTCUGDnJ7bZ9bYkJcAbI5Q Date: Mon, 18 Jun 2012 18:22:01 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D33117C30@dfweml505-mbx> References: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> In-Reply-To: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Jun 2012 18:24:24 -0000 Support! I am not aware of IPR related to this draft. Lucy -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lia Atlas Sent: Tuesday, June 12, 2012 3:39 PM To: rtgwg@ietf.org Subject: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft This email is to start a poll and discussion on whether to adopt draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft. Please respond with opinions, comments, and whether you have read the draft= . Last IETF, there were very few people who had read the draft. Authors, please indicate if there is any IPR associated with this draft. Thanks, Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From lucy.yong@huawei.com Mon Jun 18 11:25:35 2012 Return-Path: <lucy.yong@huawei.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8FC21F84F0 for <rtgwg@ietfa.amsl.com>; Mon, 18 Jun 2012 11:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J53Jnr3cDhlv for <rtgwg@ietfa.amsl.com>; Mon, 18 Jun 2012 11:25:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5C14F21F84E7 for <rtgwg@ietf.org>; Mon, 18 Jun 2012 11:25:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHA22170; Mon, 18 Jun 2012 14:25:35 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 18 Jun 2012 11:23:40 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Mon, 18 Jun 2012 11:23:38 -0700 From: Lucy yong <lucy.yong@huawei.com> To: Alia Atlas <akatlas@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org> Subject: RE: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft Thread-Topic: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft Thread-Index: AQHNSNtlv1PUklDgsEe3QQPyGozsKZcAbSfQ Date: Mon, 18 Jun 2012 18:23:37 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D33117C42@dfweml505-mbx> References: <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> In-Reply-To: <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Jun 2012 18:25:36 -0000 Support! I am not aware of IPR related to this draft. Lucy -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lia Atlas Sent: Tuesday, June 12, 2012 3:37 PM To: rtgwg@ietf.org Subject: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft This is to start a poll and discussion about whether RTGWG should adopt draft-symmvo-rtgwg-cl-use-cases-00 as a WG draft. Please respond with comments and reasoning and if you have read the draft. At our last meeting, very few people indicated that they had read the draft= . Authors, please indicate in email whether there is any IPR associated with the draft. Thanks, Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From eosborne@cisco.com Mon Jun 18 12:42:52 2012 Return-Path: <eosborne@cisco.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A720221F85C5 for <rtgwg@ietfa.amsl.com>; Mon, 18 Jun 2012 12:42:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCKBvMttilYH for <rtgwg@ietfa.amsl.com>; Mon, 18 Jun 2012 12:42:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9AF21F85B4 for <rtgwg@ietf.org>; Mon, 18 Jun 2012 12:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=361; q=dns/txt; s=iport; t=1340048572; x=1341258172; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=fpjrhRuBdlz2e1Hv3Q/MNpk6r6f3RO1n/TMsHZ3lcks=; b=LlWVK7ylrwv+4E8425By6zjO5twhHp9G+zLdZV/nBP+F2LdtpojEhcnU Khl64S443l3dwQ7tELm9le4SvNSXw0xkoHoF1+bIbL1jqVfM1UVvgmPEY afBfSDEPEphPY5+RDM3WXGK1J0J1czSY/hvqhrnUpq3aIGpTlDeElBtZr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHeD30+tJXG+/2dsb2JhbABFtW6BB4IYAQEBAwEBAQEPAR0KNBALAgEIDhQGGAYBJjABAQQBEggah2QFC5hrn2gEkRJgA4hCmnmBZoJ+ X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="93507207" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jun 2012 19:42:51 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5IJgpCS016281; Mon, 18 Jun 2012 19:42:51 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Jun 2012 14:42:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft Date: Mon, 18 Jun 2012 14:42:49 -0500 Message-ID: <D29E470202D67745B61059870F433B54097E0AC2@XMB-RCD-202.cisco.com> In-Reply-To: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft Thread-Index: Ac1I23U1Jy3xDSQoRrypgh+0a2lcAwErwTaA References: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> From: "Eric Osborne (eosborne)" <eosborne@cisco.com> To: "Alia Atlas" <akatlas@gmail.com>, <rtgwg@ietf.org> X-OriginalArrivalTime: 18 Jun 2012 19:42:51.0728 (UTC) FILETIME=[8C3D8500:01CD4D8A] X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Jun 2012 19:42:52 -0000 .. >=20 > Authors, please indicate if there is any IPR associated with this draft. >=20 No IPR from my side (and this includes Tony, who worked on an early rev of the draft). eric > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From Andras.Csaszar@ericsson.com Tue Jun 19 03:22:05 2012 Return-Path: <Andras.Csaszar@ericsson.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F81D21F85A4 for <rtgwg@ietfa.amsl.com>; Tue, 19 Jun 2012 03:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iGualKtGTF3 for <rtgwg@ietfa.amsl.com>; Tue, 19 Jun 2012 03:22:05 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C437721F8570 for <rtgwg@ietf.org>; Tue, 19 Jun 2012 03:21:59 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-b2-4fe052c62006 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E4.7D.11869.6C250EF4; Tue, 19 Jun 2012 12:21:58 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.231]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 19 Jun 2012 12:21:57 +0200 From: =?utf-8?B?QW5kcsOhcyBDc8Ohc3rDoXI=?= <Andras.Csaszar@ericsson.com> To: "rtgwg@ietf.org" <rtgwg@ietf.org> Date: Tue, 19 Jun 2012 12:21:56 +0200 Subject: FW: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 Thread-Topic: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 Thread-Index: Ac1NaiJ7NpMi3ZPIRJuY9nqlOGj6ewAmr8Sw Message-ID: <8DCD771BDA4A394E9BCBA8932E8392978729A67134@ESESSCMS0363.eemea.ericsson.se> References: <20120618155048.18575.97874.idtracker@ietfa.amsl.com> In-Reply-To: <20120618155048.18575.97874.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvre6xoAf+BlfuGVtcePOb2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGfvWbGAreMBfceL9LtYGxjX8XYwcHBICJhJbf6t1MXICmWIS F+6tZ+ti5OIQEjjFKPF75kVmCGcho8ThuxcYQarYBDwk7l//ywxiiwioSvTOamUDsVmA7I+v vzKBNAgL9DNKrH9/HqpoAqPEx15OCNtIYuXleUwgNq9AuMSjjgtsIFcICThKnP1uDxLmFHCS ePrtJjtImFFAVuLhWguQMLOAuMStJ/OZIA4VkFiyB2K6hICoxMvH/1hBbEYBGYkPSw+BTWQW 0JRYv0sfolVRYkr3Q3aIpYISJ2c+YZnAKDoLydRZCB2zkHTMQtKxgJFlFaNwbmJmTnq5kV5q UWZycXF+nl5x6iZGYCQc3PJbdQfjnXMihxilOViUxHmtt+7xFxJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cCYqChy6J6JTF8154mJc/VfLRTcUPtMcrq0cLi36bkFG245CBzh41gZGNq4Mcs4 +XiylIOB2qGCR8X7Xi1RnRQ790y16Qvez6od/3I05YK+FfFn8Z2Ybm+/6KXB2/0JXV9688I1 sivUwt76mxxoeO2X/bqSP4B57c3qZ8feMyn5RfXa5G1a/U2JpTgj0VCLuag4EQD5xymxUgIA AA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 19 Jun 2012 10:22:05 -0000 RGVhciBBbGwsDQpGWUksIHdlIGhhZCBhbiBJUFIgc3RhdGVtZW50IGFscmVhZHkgYSB5ZWFyIGFn byBmb3IgdGhlIGluZGl2aWR1YWwgZHJhZnQsIGJ1dCBhZnRlciBXRyBhZG9wdGlvbiBhbmQgcmVu YW1pbmcsIHRoZSBJUFIgZGlzY2xvc3VyZSB3YXMgbm90IHRyYW5zZmVycmVkIGJ5IHRoZSBJRVRG IHN5c3RlbXMgb250byB0aGUgV0cgYWRvcHRlZCBkcmFmdCwgdGhhdCdzIHdoeSBpdCBoYWQgdG8g YmUgZG9uZSBhZ2FpbiwgaS5lLiBpdCBpcyB0aGUgc2FtZSBhcyBiZWZvcmUuDQoNCkFuZHLDoXMN Cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIFNlY3JldGFyaWF0 IFttYWlsdG86aWV0Zi1pcHJAaWV0Zi5vcmddIA0KU2VudDogMjAxMi4gasO6bml1cyAxOC4gMTc6 NTENClRvOiBHw6Fib3IgU8OhbmRvciBFbnllZGk7IGFrYXRsYXNAanVuaXBlci5uZXQ7IHJrZWJs ZXJAanVuaXBlci5uZXQ7IEFuZHLDoXMgQ3PDoXN6w6FyOyBydXNzd2hAY2lzY28uY29tOyBtaWtl QG1zaGFuZC5vcmcudWs7IG1hY2lla0BiZ3AubnUNCkNjOiBzdGJyeWFudEBjaXNjby5jb207IGFk cmlhbkBvbGRkb2cuY28udWs7IGFsdmFyby5yZXRhbmFAaHAuY29tOyBha2F0bGFzQGdtYWlsLmNv bTsgcnRnd2dAaWV0Zi5vcmc7IGlwci1hbm5vdW5jZUBpZXRmLm9yZw0KU3ViamVjdDogSVBSIERp c2Nsb3N1cmU6IFRlbGVmb25ha3RpZWJvbGFnZXQgTE0gRXJpY3Nzb24gKHB1YmwpJ3MgU3RhdGVt ZW50IGFib3V0IElQUiByZWxhdGVkIHRvIGRyYWZ0LWlldGYtcnRnd2ctbXJ0LWZyci1hcmNoaXRl Y3R1cmUtMDENCg0KDQpEZWFyIEdhYm9yIFNhbmRvciBFbnZlZGksIEFsaWEgQXRsYXMsIFJvYmVy dCBLZWJsZXIsIEFuZHJhcyBDc2FzemFyLCBSdXNzIFdoaXRlLCBNaWtlIFNoYW5kLCBNYWNpZWsg S29uc3RhbnR5bm93aWN6Og0KDQogQW4gSVBSIGRpc2Nsb3N1cmUgdGhhdCBwZXJ0YWlucyB0byB5 b3VyIEludGVybmV0LURyYWZ0IGVudGl0bGVkICJBbiBBcmNoaXRlY3R1cmUgZm9yIElQL0xEUCBG YXN0LVJlcm91dGUgVXNpbmcgTWF4aW1hbGx5IFJlZHVuZGFudCBUcmVlcyIgKGRyYWZ0LQ0KaWV0 Zi1ydGd3Zy1tcnQtZnJyLWFyY2hpdGVjdHVyZSkgd2FzIHN1Ym1pdHRlZCB0byB0aGUgSUVURiBT ZWNyZXRhcmlhdCBvbg0KMjAxMi0wNi0xOCBhbmQgaGFzIGJlZW4gcG9zdGVkIG9uIHRoZSAiSUVU RiBQYWdlIG9mIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgRGlzY2xvc3VyZXMiIChodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xODAxLykuIFRoZSB0aXRsZSBvZiB0aGUgSVBS IGRpc2Nsb3N1cmUgaXMgIlRlbGVmb25ha3RpZWJvbGFnZXQgTE0gRXJpY3Nzb24gKHB1YmwpJ3Mg U3RhdGVtZW50IGFib3V0IElQUiByZWxhdGVkIHRvIGRyYWZ0LWlldGYtcnRnd2ctbXJ0LWZyci1h cmNoaXRlY3R1cmUtMDEuIiIpOw0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From curtis@occnc.com Wed Jun 20 08:53:07 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DB421F86CF for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 08:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.517, 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 L3mOyh2a-2Cn for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 08:53:07 -0700 (PDT) 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 DE1CA21F86C3 for <rtgwg@ietf.org>; Wed, 20 Jun 2012 08:53:06 -0700 (PDT) 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 q5KFqsat072252; Wed, 20 Jun 2012 08:52:54 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206201552.q5KFqsat072252@gateway.ipv6.occnc.com> To: Gabor.Sandor.Enyedi@ericsson.com, akatlas@juniper.net, rkebler@juniper.net, Andras.Csaszar@ericsson.com, russwh@cisco.com, mike@mshand.org.uk, maciek@bgp.nu, adrian@olddog.co.uk, stbryant@cisco.com, rtgwg@ietf.org From: Curtis Villamizar <curtis@occnc.com> Subject: Re: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 In-reply-to: Your message of "Mon, 18 Jun 2012 08:50:48 PDT." <20120618155048.18575.97874.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2012 11:52:54 -0400 Cc: patent.licensing@ericsson.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Jun 2012 15:53:07 -0000 In message <20120618155048.18575.97874.idtracker@ietfa.amsl.com> IETF Secretariat writes: > > Dear Gabor Sandor Envedi, Alia Atlas, Robert Kebler, Andras Csaszar, > Russ White, Mike Shand, Maciek Konstantynowicz: > > An IPR disclosure that pertains to your Internet-Draft entitled "An > Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees" > (draft- ietf-rtgwg-mrt-frr-architecture) was submitted to the IETF > Secretariat on 2012-06-18 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1801/). The title of the IPR > disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement > about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01.""); > > The IETF Secretariat Prior reasons to be hesitant about this work included the rather substantial change to routing and forwarding, and the need to deploy network wide (no accommodation for legacy equipment). Regardless, it became a WG item. Now that there is an IPR disclosure with no statement at all regarding licensing terms, it might be time to reconsider whether the WG should go forward with this work. IMHO- If the IPR disclosure is not updated with a reasonable and non-discriminatory, preferably royalty-free, licensing statement, the MRT work should be abandoned by RTGWG. Curtis From curtis@occnc.com Wed Jun 20 09:39:51 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2DD21F8745 for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 09:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.32 X-Spam-Level: X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[AWL=-1.320, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, 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 LyVUiLE-f4Rv for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 09:39:49 -0700 (PDT) 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 1E80E21F8743 for <rtgwg@ietf.org>; Wed, 20 Jun 2012 09:39:49 -0700 (PDT) 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 q5KGdU6J074798; Wed, 20 Jun 2012 09:39:31 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206201639.q5KGdU6J074798@gateway.ipv6.occnc.com> To: Iftekhar Hussain <IHussain@infinera.com> Subject: CL frameword xref diffs (was: Re: draft-so-yong-rtgwg-cl-framework) From: Curtis Villamizar <curtis@occnc.com> Date: Wed, 20 Jun 2012 12:39:30 -0400 Cc: RTGWG <rtgwg@ietf.org> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Jun 2012 16:39:51 -0000 Iftekhar, In a prior message my reply included: Actually it is not difficult in principle to provide cross references but it is somewhat time consuming. It also turns out that it isn't very useful. The reason is that documents covering many topics must consider certain groups of requirements such as backward compatibility and general network management. I did the exercise briefly, but didn't expand the text yet. I'll post diffs if it seems to add more clarity than bloat. Below are diffs that add cross references to the named groups of requirements in "Brief Review of Requirements" (Section 7.1). For each document or document topic called for in "Required Document Coverage" (Section 7.2) there are cross references to those groups of requirements. Another change is dropping the subsection "Component Group Metric" and adding the text (one paragraph) to the prior subsection "Component Link Grouping". Please comment on this change as well. The first diff chunk just adds comments that number the requirement groups. The remaining long diff chunk includes most of "Required Document Coverage" (Section 7.2) where the diffs are mostly addition of comments giving just the requirement groups cited and then a brief paragraph making the citation, referring directly to the requirement group names. The diffs at the very end drop the cross references to the "Component Group Metric" subsection (anchor=r.metric) which always accompany a cross reference to the "Component Link Grouping" subsection (r.bundle), the subsection that this paragraph was combined into. Again, if you thik this adds more clarity rather than added bloat, then I will keep the diffs. Otherwise, I will back out the diffs. Now that I've done this I can see where this could be a useful reminder to authors and reviewers of specific later documents, somewhat like a checklist that needs to be considered to see if the document completely addresses the requirements relevant to the topic. If this is considered very useful, then I'll change the requirement groups from a list with named entries into subsections so that I can use the XML anchor and xref to automate the cross references. Curtis cvs diff: Diffing . Index: draft-so-yong-rtgwg-cl-framework.xml =================================================================== RCS file: /home/cvs/CVS-occnc/customers/ietf/rtg-cl/draft-so-yong-rtgwg-cl-framework.xml,v retrieving revision 1.15 diff -w -U20 -r1.15 draft-so-yong-rtgwg-cl-framework.xml --- draft-so-yong-rtgwg-cl-framework.xml 15 Jun 2012 19:34:10 -0000 1.15 +++ draft-so-yong-rtgwg-cl-framework.xml 20 Jun 2012 16:11:58 -0000 @@ -1875,91 +1875,100 @@ <t> This section first summarizes and groups requirements. A set of documents coverage groupings are proposed with existing works-in-progress noted where applicable. The set of extensions are then grouped by protocol affected as a convenience to implementors. </t> <section anchor="sect.reqm-review" title="Brief Review of Requirements"> <t> The following list provides a categorization of requirements specified in <xref target="I-D.ietf-rtgwg-cl-requirement" /> along with a short phrase indication what topic the requirement covers. </t> <t> <list hangIndent="4" style="hanging"> + <!-- #1 --> <t hangText="routing information aggregation"> <vspace blankLines="0" /> FR#1 (routing summarization), FR#20 (composite link may be a component of another composite link) </t> + <!-- #2 --> <t hangText="restoration speed"> <vspace blankLines="0" /> FR#2 (restoration speed meeting NPO), FR#12 (minimally disruptive load rebalance), DR#6 (fast convergence), DR#7 (fast worst case failure convergence) </t> + <!-- #3 --> <t hangText="load distribution, stability, minimal disruption"> <vspace blankLines="0" /> FR#3 (automatic load distribution), FR#5 (must not oscillate), FR#11 (dynamic placement of flows), FR#12 (minimally disruptive load rebalance), FR#13 (bounded rearrangement frequency), FR#18 (flow placement must satisfy NPO), FR#19 (flow identification finer than per top level LSP), MR#6 (operator initiated flow rebalance) </t> + <!-- #4 --> <t hangText="backward compatibility and migration"> <vspace blankLines="0" /> FR#4 (smooth incremental deployment), FR#6 (management and diagnostics must continue to function), DR#1 (extend existing protocols), DR#2 (extend LDP, no LDP TE) </t> + <!-- #5 --> <t hangText="delay and delay variation"> <vspace blankLines="0" /> FR#7 (expose lower layer measured delay), FR#8 (precision of latency reporting), FR#9 (limit latency on per LSP basis), FR#15 (minimum delay path), FR#16 (bounded delay path), FR#17 (bounded jitter path) </t> + <!-- #6 --> <t hangText="admission control, preemption, traffic engineering"> <vspace blankLines="0" /> FR#10 (admission control, preemption), FR#14 (packet ordering), FR#21 (ingress specification of path), FR#22 (path symmetry), DR#3 (IP and LDP traffic), MR#3 (management specification of path) </t> + <!-- #7 --> <t hangText="single vs multiple domain"> <vspace blankLines="0" /> DR#4 (IGP extensions allowed within single domain), DR#5 (IGP extensions disallowed in multiple domain case) </t> + <!-- #8 --> <t hangText="general network management"> <vspace blankLines="0" /> MR#1 (polling, configuration, and notification), MR#2 (activation and de-activation) </t> + <!-- #9 --> <t hangText="path determination, connectivity verification"> <vspace blankLines="0" /> MR#4 (path trace), MR#5 (connectivity verification) </t> </list> </t> <t> The above list is not intended as a substitute for <xref target="I-D.ietf-rtgwg-cl-requirement" />, but rather as a concise grouping and reminder or requirements to serve as a means of more easily determining requirements coverage of a set of protocol documents. </t> </section> <section anchor="sect.doclist" title="Required Document Coverage"> @@ -1990,412 +1999,674 @@ <t> An index is needed that if included in an ERO would indicate the need to place the LSP on any one component within the group. </t> <t> A second index is needed that if included in an ERO would indicate the need to balance flows within the LSP across all components of the group. This is equivalent to the "all-ones" component for the entire bundle. </t> </list> <xref target="I-D.ospf-cc-stlv" /> can be extended to include multipath treatment capabilities. An ISIS solution is also needed. An extension of RSVP-TE signaling is needed to indicate multipath treatment preferences. </t> - </section> + <t> + If a component group is allowed to support all of the + parameters of a link bundle, then a group TE metric would + be accommodated. This can be supported with the component + TLV (C-TLV) defined in <xref target="I-D.ospf-cc-stlv" />. + </t> - <section anchor="r.metric" - title="Component Group Metric"> + <!-- #1 (routing information aggregation), + also: + #2 (restoration speed), + #4 (backward compatibility and migration), + #8 (general network management) + --> <t> - If a group is allowed to support all of the parameters of - a link bundle, then a group TE metric would be - accommodated. This can be supported with the component - TLV (C-TLV) defined in <xref target="I-D.ospf-cc-stlv" />. + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + is the "routing information aggregation" set of + requirements. The "restoration speed", "backward + compatibility and migration", and "general network + management" requirements must also be considered. </t> </section> <section anchor="r.delay" title="Delay and Jitter Extensions"> <t> A extension is needed in the IGP-TE advertisement to support delay and delay variation for links, link bundles, and forwarding adjacencies. Whatever mechanism is described must take precautions that insure that route oscillations cannot occur. <xref target="I-D.wang-ccamp-latency-te-metric" /> may be a good starting point. </t> + <!-- #5 (delay and delay variation), + also + #2 (restoration speed), + #4 (backward compatibility and migration), + #8 (general network management) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + is the "delay and delay variation" set of requirements. + The "restoration speed", "backward compatibility and + migration", and "general network management" requirements + must also be considered. + </t> + </section> <section anchor="r.path" title="Path Selection and Admission Control"> <t> Path selection and admission control changes must be documented in each document that proposes a protocol extension that advertises a new capability or parameter that must be supported by changes in path selection and admission control. </t> + <!-- #3 (load distribution, stability, minimal disruption), + #6 (admission control, preemption, traffic engineering), + also + #2 (restoration speed), + #9 (path determination, connectivity verification), + also + #4 (backward compatibility and migration), + #8 (general network management) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + are the "load distribution, stability, minimal disruption" + and "admission control, preemption, traffic engineering" + sets of requirements. The "restoration speed" and "path + determination, connectivity verification" requirements + must also be considered. The "backward compatibility and + migration", and "general network management" requirements + must also be considered. + </t> + </section> <section anchor="r.adaptive" title="Dynamic Multipath Balance"> <t> FR#11 explicitly calls for dynamic load balancing similar to existing adaptive multipath. In implementations where flow identification uses a coarse granularity, the adjustments would have to be equally coarse, in the worst case moving entire LSP. The impact of flow identification granularity and potential adaptive multipath approaches may need to be documented in greater detail than provided here. </t> + <!-- #2 (restoration speed), + #3 (load distribution, stability, minimal disruption), + also + #9 (path determination, connectivity verification), + also + #4 (backward compatibility and migration), + #8 (general network management) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + are the "restoration speed" and the "load distribution, + stability, minimal disruption" sets of requirements. The + "path determination, connectivity verification" + requirements must also be considered. The "backward + compatibility and migration", and "general network + management" requirements must also be considered. + </t> + </section> <section anchor="r.freq-balance" title="Frequency of Load Balance"> <t> IGP-TE and RSVP-TE extensions are needed to support frequency of load balancing rearrangement called for in FR#13, and FR#15-FR#17. Constraints are not defined in RSVP-TE, but could be modeled after administrative attribute affinities in RFC3209 and elsewhere. </t> + <!-- #3 (load distribution, stability, minimal disruption), + also + #9 (path determination, connectivity verification), + also + #4 (backward compatibility and migration), + #8 (general network management) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + is the "load distribution, stability, minimal disruption" + set of requirements. The "path determination, + connectivity verification" must also be considered. The + "backward compatibility and migration" and "general + network management" requirements must also be considered. + </t> + </section> <section anchor="r.ll-ul-leak" title="Inter-Layer Communication"> <t> Lower layer to upper layer communication called for in FR#7 and FR#20. This is addressed for a subset of parameters related to packet ordering in <xref target="I-D.villamizar-mpls-tp-multipath" /> where layers are MPLS. Remaining parameters, specifically delay and delay variation, need to be addressed. Passing information from a lower non-MPLS layer to an MPLS layer needs to be addressed, though this may largely be generic advice encouraging a coupling of MPLS to lower layer management plane or control plane interfaces. This topic can be addressed in each document proposing a protocol extension, where applicable. </t> + <!-- #2 (restoration speed), + also + #4 (backward compatibility and migration), + #8 (general network management) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + is the "restoration speed" set of requirements. The + "backward compatibility and migration" and "general + network management" requirements must also be considered. + </t> + </section> <section anchor="r.mp-tp" title="Packet Ordering Requirements"> <t> A document is needed to define extensions supporting various packet ordering requirements, ranging from requirements to preservce microflow ordering only, to requirements to preservce full LSP ordering (as in MPLS-TP). This is covered by <xref target="I-D.villamizar-mpls-tp-multipath" /> and <xref target="I-D.villamizar-mpls-tp-multipath-te-extn" />. </t> + <!-- #6 (admission control, preemption, traffic engineering), + #9 (path determination, connectivity verification), + also + #4 (backward compatibility and migration), + #8 (general network management) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + are the "admission control, preemption, traffic + engineering" and the "path determination, connectivity + verification" sets of requirements. The "backward + compatibility and migration" and "general network + management" requirements must also be considered. + </t> + </section> <section anchor="r.disrupt" title="Minimally Disruption Load Balance"> <t> The behavior of hash methods used in classic multipath needs to be described in terms of FR#12 which calls for minimally disruptive load adjustments. For example, reseeding the hash violates FR#12. Using modulo operations is significantly disruptive if a link comes or goes down, as pointed out in <xref target="RFC2992" />. In addition, backwards compatibility with older hardware needs to be accommodated. </t> + <!-- #3 (load distribution, stability, minimal disruption) --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + is the "load distribution, stability, minimal disruption" + set of requirements. + </t> + </section> <section anchor="r.symmetry" title="Path Symmetry"> <t> Protocol extensions are needed to support dynamic load balance as called for to meet FR#22 (path symmetry) and to meet FR#11 (dynamic placement of flows). Currently path symmetry can only be supported in link bundling if the path is pinned. When a flow is moved both ingress and egress must make the move as close to simultaneously as possible to satisfy FR#22 and FR#12 (minimally disruptive load rebalance). If a group of flows are identified using a hash, then the hash must be identical on the pair of LSR at the endpoint, using the same hash seed and with one side swapping source and destination. If the label stack is used, then either the entire label stack must be a special case flow identification, since the set of labels in either direction are not correlated, or the two LSR must conspire to use the same flow identifier. For example, using a common entropy label value, and using only the entropy label in the flow identification would satisfy this requirement. </t> + <!-- #3 (load distribution, stability, minimal disruption), + #6 (admission control, preemption, traffic engineering), + also + #4 (backward compatibility and migration), + #8 (general network management), + helps with + #9 (path determination, connectivity verification) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + are the "load distribution, stability, minimal disruption" + and the "admission control, preemption, traffic + engineering" sets of requirements. The "backward + compatibility and migration" and "general network + management" requirements must also be considered. Path + symetry simplifies support for the "path determination, + connectivity verification" set of requirements, but with + significant complexity added elsewhere. + </t> + </section> <section anchor="r.stability" title="Performance, Scalability, and Stability"> <t> A separate document providing analysis of performance, scalability, and stability impacts of changes may be needed. The topic of traffic adjustment oscillation must also be covered. If sufficient coverage is provided in each document covering a protocol extension, a separate document would not be needed. </t> + <!-- #2 (restoration speed), + impacts other documents, + should be cited by: + r.bundle, r.delay, r.path, r.symmetry, r.ip-ldp, + r.ldp-extn, r.pw-extn, r.multi-domain + possibly r.adaptive, r.freq-balance + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + is the "restoration speed" set of requirements. This is + not a simple topic and not a topic that is well served by + scattering it over multiple documents, therefore it may be + best to put this in a separate document and put citations + in documents called for in + <xref target="r.bundle" />, + <xref target="r.delay" />, + <xref target="r.path" />, + <xref target="r.symmetry" />, + <xref target="r.ip-ldp" />, + <xref target="r.ldp-extn" />, + <xref target="r.pw-extn" />, and + <xref target="r.multi-domain" />. + Citation may also be helpful in + <xref target="r.adaptive" />, and + <xref target="r.freq-balance" />. + </t> + </section> <section anchor="r.ip-ldp" title="IP and LDP Traffic"> <t> A document is needed to define the use of measurements native IP and native LDP traffic levels to reduce link advertised bandwidth amounts. </t> + <!-- #3 (load distribution, stability, minimal disruption), + #6 (admission control, preemption, traffic engineering), + also + #9 (path determination, connectivity verification), + also + #4 (backward compatibility and migration), + #8 (general network management) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + are the "load distribution, stability, minimal disruption" + and the "admission control, preemption, traffic + engineering" set of requirements. The "path + determination, connectivity verification" must also be + considered. The "backward compatibility and migration" + and "general network management" requirements must also be + considered. + </t> + </section> <section anchor="r.ldp-extn" title="LDP Extensions"> <t> Extending LDP is called for in DR#2. LDP can be extended to couple FEC admission control to local resource availability without providing LDP traffic engineering capability. Other LDP extensions such as signaling a bound on microflow size and LDP LSP requirements would provide useful information without providing LDP traffic engineering capability. </t> + <!-- #6 (admission control, preemption, traffic engineering), + also + #4 (backward compatibility and migration), + #8 (general network management) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + is the "admission control, preemption, traffic + engineering" set of requirements. The "backward + compatibility and migration" and "general network + management" requirements must also be considered. + </t> + </section> <section anchor="r.pw-extn" title="Pseudowire Extensions"> <t> PW extensions such as signaling a bound on microflow size and PW requirements would provide useful information. </t> + <!-- #6 (admission control, preemption, traffic engineering), + also + #4 (backward compatibility and migration), + #8 (general network management) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + is the "admission control, preemption, traffic + engineering" set of requirements. The "backward + compatibility and migration" and "general network + management" requirements must also be considered. + </t> + </section> <section anchor="r.multi-domain" title="Multi-Domain Composite Link"> <t> <!-- fix me --> DR#5 calls for Composite Link to span multiple network topologies. Component LSP may already span multiple network topologies, though most often in practice these are LDP signaled. Component LSP which are RSVP-TE signaled may also span multiple network topologies using at least three existing methods (per domain <xref target="RFC5152" />, BRPC <xref target="RFC5441" />, PCE <xref target="RFC4655" />). When such component links are combined in a Composite Link, the Composite Link spans multiple network topologies. It is not clear in which document this needs to be described or whether this description in the framework is sufficient. The authors and/or the WG may need to discuss this. DR#5 mandates that IGP-TE extension cannot be used. This would disallow the use of <xref target="RFC5316" /> or <xref target="RFC5392" /> in conjunction with <xref target="RFC5151" />. </t> + <!-- #7 (single vs multiple domain), + #6 (admission control, preemption, traffic engineering), + also + #1 (routing information aggregation), + #3 (load distribution, stability, minimal disruption), + #5 (delay and delay variation), + also + #4 (backward compatibility and migration), + #8 (general network management), + #9 (path determination, connectivity verification) + --> + + <t> + The primary focus of this document, among the sets of + requirements listed in <xref target="sect.reqm-review" /> + are "single vs multiple domain" and "admission control, + preemption, traffic engineering". The "routing + information aggregation" and "load distribution, + stability, minimal disruption" requirements need attention + due to their use of the IGP in single domain Composite + Link. Other requirements such as "delay and delay + variation", can more easily be accomodated by carrying + metrics within BGP. The "path determination, connectivity + verification" requirements need attention due to + requirements to restrict disclosure of topology + information across domains in multi-domain deployments. + The "backward compatibility and migration" and "general + network management" requirements must also be considered. + </t> + </section> </section> <section anchor="sect.open-issues" title="Open Issues Regarding Requirements"> <t> <!-- fix me --> Note to co-authors: This section needs to be reduced to an empty section and then removed. </t> <t> The following topics in the requirements document are not addressed. Since they are explicitly mentioned in the requirements document some mention of how they are supported is needed, even if to say nother needed to be done. If we conclude any particular topic is irrelevant, maybe the topic should be removed from the requirement document. At that point we could add the management requirements that have come up and were missed. <list style="numbers"> <t> L3VPN RFC 4364, RFC 4797,L2VPN RFC 4664, VPWS, VPLS RFC 4761, RFC 4762 and VPMS VPMS Framework (draft-ietf-l2vpn-vpms-frmwk-requirements). It is not clear what additional Composite Link requirements these references imply, if any. If no additional requirements are implied, then these references are considered to be informational only. + <!-- Dave added that, so Dave needs to answer this. --> </t> <t> Migration may not be adequately covered in <xref target="sect.compat" />. It might also be necessary to - say more here on performance, scalability, and - stability. Comments on this from co-authors or the WG? + say more here on performance, scalability, and stability + as it related to migration. Comments on this from + co-authors or the WG? + <!-- This might be a topic for r.bundle, r.metric --> </t> <t> We may need a performance section in this document to specifically address #DR6 (fast convergence), and #DR7 (fast worst case failure convergence), though we do already have scalability discussion. The performance section would have to say "no worse than before, except were there was no alternative to make it very slightly worse" (in a bit more detail than that). It would also have to better define the nature of the performance criteria. + <!-- need r.stability ? - or embed in other docs? --> </t> </list> </t> </section> <section anchor="sect.by-protocol" title="Framework Requirement Coverage by Protocol"> <t> As an aid to implementors, this section summarizes requirement coverage listed in <xref target="sect.doclist" /> by protocol or LSR functionality affected. </t> <t> Some documentation may be purely informational, proposing no changes and proposing usage at most. This includes <xref target="r.path" />, <xref target="r.disrupt" />, <xref target="r.stability" />, and <xref target="r.multi-domain" />. </t> <t> <xref target="r.symmetry" /> may require a new protocol. </t> <section anchor="sect.by-igp" title="OSPF-TE and ISIS-TE Protocol Extensions"> <t> Many of the changes listed in <xref target="sect.doclist" /> require IGP-TE changes, though most are small extensions to provide additional information. This set includes <xref target="r.bundle" />, <xref - target="r.metric" />, <xref target="r.delay" />, <xref - target="r.freq-balance" />, <xref target="r.ll-ul-leak" - />, and <xref target="r.mp-tp" />. An adjustment to - existing advertised parameters is suggested in <xref - target="r.ip-ldp" />. + target="r.delay" />, <xref target="r.freq-balance" />, + <xref target="r.ll-ul-leak" />, and <xref target="r.mp-tp" + />. An adjustment to existing advertised parameters is + suggested in <xref target="r.ip-ldp" />. </t> </section> <section anchor="sect.by-pw-extn" title="PW Protocol Extensions"> <t> The only suggestion of pseudowire (PW) extensions is in <xref target="r.pw-extn" />. </t> </section> <section anchor="sect.by-ldp-extn" title="LDP Protocol Extensions"> <t> Potential LDP extensions are described in <xref target="r.ldp-extn" />. </t> </section> <section anchor="sect.by-rsvp-te" title="RSVP-TE Protocol Extensions"> <t> RSVP-TE protocol extensions are called for in <xref - target="r.bundle" />, <xref target="r.metric" />, <xref - target="r.freq-balance" />, <xref target="r.mp-tp" />, and - <xref target="r.symmetry" />. + target="r.bundle" />, <xref target="r.freq-balance" />, + <xref target="r.mp-tp" />, and <xref target="r.symmetry" + />. </t> </section> <section anchor="sect.by-path-select" title="RSVP-TE Path Selection Changes"> <t> <xref target="r.path" /> calls for path selection to be addressed in individual documents that require change. These changes would include those proposed in <xref - target="r.bundle" />, <xref target="r.metric" />, <xref + target="r.bundle" />, <xref target="r.delay" />, <xref target="r.freq-balance" />, and <xref target="r.mp-tp" />. </t> </section> <section anchor="sect.by-ac" title="RSVP-TE Admission Control and Preemption"> <t> When a change is needed to path selection, a corresponding change is needed in admission control. The same set of sections applies: <xref target="r.bundle" />, <xref - target="r.metric" />, <xref target="r.delay" />, <xref - target="r.freq-balance" />, and <xref target="r.mp-tp" />. - Some resource changes such as a link delay change might - trigger preemption. The rules of preemption remain - unchanged, still based on holding priority. + target="r.delay" />, <xref target="r.freq-balance" />, and + <xref target="r.mp-tp" />. Some resource changes such as + a link delay change might trigger preemption. The rules + of preemption remain unchanged, still based on holding + priority. </t> </section> <section anchor="sect.by-forwarding" title="Flow Identification and Traffic Balance"> <t> The following describe either the state of the art in flow identification and traffic balance or propose changes: <xref target="r.adaptive" />, <xref target="r.freq-balance" />, <xref target="r.mp-tp" />, and <xref target="r.disrupt" />. </t> </section> </section> </section> From alvaro.retana@hp.com Wed Jun 20 09:45:03 2012 Return-Path: <alvaro.retana@hp.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27C221F8782 for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 09:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 gNwbKyJ2AMxV for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 09:45:02 -0700 (PDT) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by ietfa.amsl.com (Postfix) with ESMTP id 7657221F8639 for <rtgwg@ietf.org>; Wed, 20 Jun 2012 09:45:02 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id D9FAA385C1; Wed, 20 Jun 2012 16:44:58 +0000 (UTC) Received: from G1W3636G.americas.hpqcorp.net (16.193.48.87) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 20 Jun 2012 16:44:12 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.116]) by G1W3636G.americas.hpqcorp.net ([16.193.48.87]) with mapi id 14.02.0283.003; Wed, 20 Jun 2012 16:44:12 +0000 From: "Retana, Alvaro" <alvaro.retana@hp.com> To: "curtis@occnc.com" <curtis@occnc.com>, "Gabor.Sandor.Enyedi@ericsson.com" <Gabor.Sandor.Enyedi@ericsson.com>, "akatlas@juniper.net" <akatlas@juniper.net>, "rkebler@juniper.net" <rkebler@juniper.net>, "Andras.Csaszar@ericsson.com" <Andras.Csaszar@ericsson.com>, "mike@mshand.org.uk" <mike@mshand.org.uk>, "maciek@bgp.nu" <maciek@bgp.nu>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "stbryant@cisco.com" <stbryant@cisco.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "White, Russell" <riwhite@verisign.com> Subject: RE: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 Thread-Topic: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 Thread-Index: AQHNTvzLMUIbnYe+XU21FBZSOK1JP5cDZg2w Date: Wed, 20 Jun 2012 16:44:11 +0000 Message-ID: <C03AAF38AD209F4BB02BC0A34B774CE7060394@G2W2446.americas.hpqcorp.net> References: Your message of "Mon, 18 Jun 2012 08:50:48 PDT." <20120618155048.18575.97874.idtracker@ietfa.amsl.com> <201206201552.q5KFqsat072252@gateway.ipv6.occnc.com> In-Reply-To: <201206201552.q5KFqsat072252@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "patent.licensing@ericsson.com" <patent.licensing@ericsson.com> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Jun 2012 16:45:03 -0000 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. =20 http://www.ietf.org/ipr/policy.html To help in the evaluation, the following link is to the patent application = itself (provided by the authors): 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 =20 As a chair, my job is to remind the WG of the IETF policy -- the decision o= f whether we should continue to work on this item is to be made by the indi= viduals participating in the WG. Because the concern expressed by Curtis h= as come up several times (from different people), including at the meeting = in Taipei, I would like to hear other opinions specific to the impact of th= e terms of the IPR filing with respect to the architecture proposed. Thanks! Alvaro. > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Curtis Villamizar > Sent: Wednesday, June 20, 2012 11:53 AM > To: Gabor.Sandor.Enyedi@ericsson.com; akatlas@juniper.net; > rkebler@juniper.net; Andras.Csaszar@ericsson.com; russwh@cisco.com; > mike@mshand.org.uk; maciek@bgp.nu; adrian@olddog.co.uk; > stbryant@cisco.com; rtgwg@ietf.org > Cc: patent.licensing@ericsson.com > Subject: Re: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s > Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 >=20 >=20 > In message <20120618155048.18575.97874.idtracker@ietfa.amsl.com> > IETF Secretariat writes: >=20 > > > > Dear Gabor Sandor Envedi, Alia Atlas, Robert Kebler, Andras Csaszar, > > Russ White, Mike Shand, Maciek Konstantynowicz: > > > > An IPR disclosure that pertains to your Internet-Draft entitled "An > > Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees" > > (draft- ietf-rtgwg-mrt-frr-architecture) was submitted to the IETF > > Secretariat on 2012-06-18 and has been posted on the "IETF Page of > > Intellectual Property Rights Disclosures" > > (https://datatracker.ietf.org/ipr/1801/). The title of the IPR > > disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement > > about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01.""); > > > > The IETF Secretariat >=20 >=20 > Prior reasons to be hesitant about this work included the rather > substantial change to routing and forwarding, and the need to deploy > network wide (no accommodation for legacy equipment). Regardless, it > became a WG item. >=20 > Now that there is an IPR disclosure with no statement at all regarding > licensing terms, it might be time to reconsider whether the WG should > go forward with this work. >=20 > IMHO- If the IPR disclosure is not updated with a reasonable and > non-discriminatory, preferably royalty-free, licensing statement, the > MRT work should be abandoned by RTGWG. >=20 > Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From internet-drafts@ietf.org Wed Jun 20 10:06:10 2012 Return-Path: <internet-drafts@ietf.org> 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 EB30E21F8794; Wed, 20 Jun 2012 10:06:09 -0700 (PDT) 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 D9yfwLK5jvLa; Wed, 20 Jun 2012 10:06:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71D721F8772; Wed, 20 Jun 2012 10:06:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-cl-requirement-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120620170608.8998.285.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2012 10:06:08 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Jun 2012 17:06:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : 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-07.txt Pages : 16 Date : 2012-06-20 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-07 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-cl-requirement-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From curtis@occnc.com Wed Jun 20 10:17:05 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CD321F864C for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 10:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.568, 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 Yz77nOmY5WZ8 for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 10:17:04 -0700 (PDT) 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 61BE721F8642 for <rtgwg@ietf.org>; Wed, 20 Jun 2012 10:17:04 -0700 (PDT) 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 q5KHH0gS076184; Wed, 20 Jun 2012 10:17:00 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206201717.q5KHH0gS076184@gateway.ipv6.occnc.com> To: RTGWG <rtgwg@ietf.org> Subject: draft-ietf-rtgwg-cl-requirement-07 From: Curtis Villamizar <curtis@occnc.com> Date: Wed, 20 Jun 2012 13:17:00 -0400 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Jun 2012 17:17:05 -0000 The updated draft draft-ietf-rtgwg-cl-requirement-07 has been submitted with changes discussed on previously on the RTGWG mailing list. Changes from draft-ietf-rtgwg-cl-requirement -06 to -07: 1. Trivia: a. deleted some XML comments b. change document number (06 to 07) and date c. change author (Lucy) address information (office move) 2. Add requirements as per mailing list discussion: a. Power reduction allowed use: requirement wording: Load balancing MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction. clarification text outside of requirements list: As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. The network operator when configuring a network for power reduction should weigh the benefit of power reduction against the disadvantage of a minimal disruption. b. Three new management requirements: Component link fault notification MUST be sent to the management plane. Composite link fault notification MUST be sent to management plane and distribute via link state message in the IGP. An operator initiated optimization MUST be performed in a minimally disruptive manner as described in <xref target="multipath-diff" />. 3. Update to acknowledgements. The updated draft draft-ietf-rtgwg-cl-requirement-07 is available at: http://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement/ Text diffs are at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-cl-requirement-07 Curtis From curtis@occnc.com Wed Jun 20 11:16:04 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5FA21F8778 for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 11:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 QDWnIVJXcwCh for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 11:16:03 -0700 (PDT) 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 2F1F021F8775 for <rtgwg@ietf.org>; Wed, 20 Jun 2012 11:16:03 -0700 (PDT) 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 q5KIFxmL078500; Wed, 20 Jun 2012 11:15:59 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206201815.q5KIFxmL078500@gateway.ipv6.occnc.com> To: RTGWG <rtgwg@ietf.org> Subject: draft-symmvo-rtgwg-cl-use-cases-01 From: Curtis Villamizar <curtis@occnc.com> Date: Wed, 20 Jun 2012 14:15:59 -0400 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Jun 2012 18:16:04 -0000 The updated draft draft-symmvo-rtgwg-cl-use-cases-01 has been submitted. The only changes are: 1. Trivia: a. change document number (00 to 01) and date b. change author affiliation (Ning) c. change author (Lucy) address information (office move) 2. Update to acknowledgements. The updated draft draft-symmvo-rtgwg-cl-use-cases-01 is available at http://datatracker.ietf.org/doc/draft-symmvo-rtgwg-cl-use-cases Text diffs are at: http://tools.ietf.org/rfcdiff?url2=draft-symmvo-rtgwg-cl-use-cases-01 Since there were no changes of substance, the changes should not affect anyone reading this as part of the RTGWG poll regarding making this a working group document. Curtis From curtis@occnc.com Wed Jun 20 12:02:45 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA2221F86C3 for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 12:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.569, 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 Uysi9RkWMUXn for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 12:02:44 -0700 (PDT) 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 F3AAA21F875B for <rtgwg@ietf.org>; Wed, 20 Jun 2012 12:02:43 -0700 (PDT) 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 q5KJ2NpP080034; Wed, 20 Jun 2012 12:02:24 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206201902.q5KJ2NpP080034@gateway.ipv6.occnc.com> To: "Retana, Alvaro" <alvaro.retana@hp.com> From: Curtis Villamizar <curtis@occnc.com> Subject: Re: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 In-reply-to: Your message of "Wed, 20 Jun 2012 16:44:11 -0000." <C03AAF38AD209F4BB02BC0A34B774CE7060394@G2W2446.americas.hpqcorp.net> Date: Wed, 20 Jun 2012 15:02:23 -0400 Cc: "White, Russell" <riwhite@verisign.com>, "rkebler@juniper.net" <rkebler@juniper.net>, "mike@mshand.org.uk" <mike@mshand.org.uk>, "patent.licensing@ericsson.com" <patent.licensing@ericsson.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "akatlas@juniper.net" <akatlas@juniper.net>, "maciek@bgp.nu" <maciek@bgp.nu>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "stbryant@cisco.com" <stbryant@cisco.com> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Jun 2012 19:02:45 -0000 Alvaro, Please remind me. Has there been any discussion as to whether the XRO (exclude route object) in RSVP-TE (RFC 4874) would qualify as prior art, since the XRO specifies a "system and method of implementing a lightweight not-via fast reroute in a telecommunications network"? The patent seems to be a method patent and not a use patent. It appears to me that the only major difference between the XRO and the Ericson patent (which may affect not-via and use of redundant trees of which maximally redundant would be a subset), is that XRO is applied to RSVP-TE and was intended to aid in multi-domain use of RSVP-TE and the Ericson patent uses a functionally identical approach (indicate which resources to avoid) applied to IP rather than RSVP-TE. The XRO was introduced in draft-ietf-ccamp-rsvp-te-exclude-route-00 in June 2003 which became an RFC in 2007. The patent was submitted in 2006, three years after XRO publication (not counting individual submissions prior to the first WG draft). If this counts as prior art, the patent is invalid. I'm not sure how this could affect MRT but not affect the notvia work (no IPR disclosure from Ericson on that). The draft-bryant-shand-ipfrr-notvia-addresses-00 individual submission was published in March 2005. This also precedes the patent. The only reason I can see that notvia and XRO might be considered different is that they don't specify a redundant tree. Another question for legal types is whether computing redundant trees is an algorithm (specifically a graph theory algorithm) and therefore not patentable at all. Should a patent of this type specify the use of a redundant tree algorithm in IP or LDP? Can a patent apply to the use of *any* algorithm which falls within the classification of a redundant tree algorithm in IP or LDP? Of course, I am not an attorney so I cannot give a legal opinion on this matter or any other legal matter. I am asking if there has ever been such a discussion and whether my layperson legally uniformed opinion might by chance be accurate or close to accurate. If the patent is valid, does apply to the MRT work, and has no licensing specified, IMHO the WG should cease to work on this. Curtis In message <C03AAF38AD209F4BB02BC0A34B774CE7060394@G2W2446.americas.hpqcorp.net> "Retana, Alvaro" writes: As a reminder, having an IPR claim does not disqualify a draft from advancing in the IETF, being adopted 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 To help in the evaluation, the following link is to the patent application itself (provided by the authors): http://www.wipo.int/patentscope/search/en/detail.jsf?docId=WO2010055408&recNum=1&docAn=IB2009007467&queryString=FP:%28PCT/IB2009/007467%29&maxRec=1 As a chair, my job is to remind the WG of the IETF policy -- the decision of whether we should continue to work on this item is to be made by the individuals participating in the WG. Because the concern expressed by Curtis has come up several times (from different people), including at the meeting in Taipei, I would like to hear other opinions specific to the impact of the terms of the IPR filing with respect to the architecture proposed. Thanks! Alvaro. > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Curtis Villamizar > Sent: Wednesday, June 20, 2012 11:53 AM > To: Gabor.Sandor.Enyedi@ericsson.com; akatlas@juniper.net; > rkebler@juniper.net; Andras.Csaszar@ericsson.com; russwh@cisco.com; > mike@mshand.org.uk; maciek@bgp.nu; adrian@olddog.co.uk; > stbryant@cisco.com; rtgwg@ietf.org > Cc: patent.licensing@ericsson.com > Subject: Re: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s > Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 > > > In message <20120618155048.18575.97874.idtracker@ietfa.amsl.com> > IETF Secretariat writes: > > > > > Dear Gabor Sandor Envedi, Alia Atlas, Robert Kebler, Andras Csaszar, > > Russ White, Mike Shand, Maciek Konstantynowicz: > > > > An IPR disclosure that pertains to your Internet-Draft entitled "An > > Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees" > > (draft- ietf-rtgwg-mrt-frr-architecture) was submitted to the IETF > > Secretariat on 2012-06-18 and has been posted on the "IETF Page of > > Intellectual Property Rights Disclosures" > > (https://datatracker.ietf.org/ipr/1801/). The title of the IPR > > disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement > > about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01.""); > > > > The IETF Secretariat > > > Prior reasons to be hesitant about this work included the rather > substantial change to routing and forwarding, and the need to deploy > network wide (no accommodation for legacy equipment). Regardless, it > became a WG item. > > Now that there is an IPR disclosure with no statement at all regarding > licensing terms, it might be time to reconsider whether the WG should > go forward with this work. > > IMHO- If the IPR disclosure is not updated with a reasonable and > non-discriminatory, preferably royalty-free, licensing statement, the > MRT work should be abandoned by RTGWG. > > Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From curtis@occnc.com Wed Jun 20 12:16:49 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FEB21F8573 for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 12:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.537, 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 icaJ3E2w2HkM for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 12:16:48 -0700 (PDT) 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 7501B21F8564 for <rtgwg@ietf.org>; Wed, 20 Jun 2012 12:16:48 -0700 (PDT) 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 q5KJGiCL081261; Wed, 20 Jun 2012 12:16:45 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206201916.q5KJGiCL081261@gateway.ipv6.occnc.com> To: RTGWG <rtgwg@ietf.org> Subject: should I hold off on updating the CL framework draft? From: Curtis Villamizar <curtis@occnc.com> Date: Wed, 20 Jun 2012 15:16:44 -0400 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Jun 2012 19:16:49 -0000 RTGWG, We are in a poll on "Composite Link Framework in Multi Protocol Label Switching (MPLS)", aka the CL Framework (currently draft-so-yong-rtgwg-cl-framework-05, would be updated to -06). Are there any objections from the WG to updating the CL framework from the current -05 version to an -06 version to reflect the discussion on the WG mailing list and making those updates during the poll? BTW- Primary participants in the WG mailing list discussion were Iftekhar Hussain, Lucy Yong, and myself. Kireeti Kompella made comments in response to Iftekhar, but regarding requirements implied by the CL Framework. Curtis From alvaro.retana@hp.com Wed Jun 20 12:52:39 2012 Return-Path: <alvaro.retana@hp.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FC821F85E0 for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 12:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 7K3Tyw6tnOIE for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 12:52:37 -0700 (PDT) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6906D21F85B8 for <rtgwg@ietf.org>; Wed, 20 Jun 2012 12:52:37 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 4C6D4C; Wed, 20 Jun 2012 19:52:34 +0000 (UTC) Received: from G2W1954G.americas.hpqcorp.net (16.238.8.186) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 20 Jun 2012 19:51:46 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.116]) by G2W1954G.americas.hpqcorp.net ([16.238.8.186]) with mapi id 14.02.0283.003; Wed, 20 Jun 2012 19:51:46 +0000 From: "Retana, Alvaro" <alvaro.retana@hp.com> To: "curtis@occnc.com" <curtis@occnc.com> Subject: RE: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 Thread-Topic: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 Thread-Index: AQHNTxdKxUAObhIOfkOaOM2UK2QsDZcDmloQ Date: Wed, 20 Jun 2012 19:51:45 +0000 Message-ID: <C03AAF38AD209F4BB02BC0A34B774CE70605E2@G2W2446.americas.hpqcorp.net> References: Your message of "Wed, 20 Jun 2012 16:44:11 -0000." <C03AAF38AD209F4BB02BC0A34B774CE7060394@G2W2446.americas.hpqcorp.net> <201206201902.q5KJ2NpP080034@gateway.ipv6.occnc.com> In-Reply-To: <201206201902.q5KJ2NpP080034@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "White, Russell" <riwhite@verisign.com>, "rkebler@juniper.net" <rkebler@juniper.net>, "mike@mshand.org.uk" <mike@mshand.org.uk>, "patent.licensing@ericsson.com" <patent.licensing@ericsson.com>, "akatlas@juniper.net" <akatlas@juniper.net>, "maciek@bgp.nu" <maciek@bgp.nu>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "stbryant@cisco.com" <stbryant@cisco.com> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Jun 2012 19:52:39 -0000 Curtis: No, if that discussion has happened, it didn't take place in the rtgwg list= . Quoting from rfc3979 (IP in IETF Technology): "... Although the IETF can make no actual determination of validity, enforceability or applicability of any particular IPR claim, it is reasonable that a working group will take into account on their own opinions of the validity, enforceability or applicability of Intellectual Property Rights in their evaluation..." I am not a lawyer either, but it is clear to me that any discussion we (IET= F/rtgwg) could have would obviously be non-binding. It is not in our domai= n to determine what is or not prior art. Having said that, I would imagine (as a member of the WG) that the authors = have a clear picture of what is prior art and why some technologies may not= be. Again, not something for us to evaluate...but information that may be= useful in forming individual opinions. Alvaro. > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Wednesday, June 20, 2012 3:02 PM > To: Retana, Alvaro > Cc: curtis@occnc.com; Gabor.Sandor.Enyedi@ericsson.com; > akatlas@juniper.net; rkebler@juniper.net; Andras.Csaszar@ericsson.com; > mike@mshand.org.uk; maciek@bgp.nu; adrian@olddog.co.uk; > stbryant@cisco.com; rtgwg@ietf.org; White, Russell; > patent.licensing@ericsson.com > Subject: Re: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s > Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 >=20 >=20 > Alvaro, >=20 > Please remind me. Has there been any discussion as to whether the XRO > (exclude route object) in RSVP-TE (RFC 4874) would qualify as prior > art, since the XRO specifies a "system and method of implementing a > lightweight not-via fast reroute in a telecommunications network"? > The patent seems to be a method patent and not a use patent. It > appears to me that the only major difference between the XRO and the > Ericson patent (which may affect not-via and use of redundant trees of > which maximally redundant would be a subset), is that XRO is applied > to RSVP-TE and was intended to aid in multi-domain use of RSVP-TE and > the Ericson patent uses a functionally identical approach (indicate > which resources to avoid) applied to IP rather than RSVP-TE. >=20 > The XRO was introduced in draft-ietf-ccamp-rsvp-te-exclude-route-00 in > June 2003 which became an RFC in 2007. The patent was submitted in > 2006, three years after XRO publication (not counting individual > submissions prior to the first WG draft). If this counts as prior > art, the patent is invalid. >=20 > I'm not sure how this could affect MRT but not affect the notvia work > (no IPR disclosure from Ericson on that). The > draft-bryant-shand-ipfrr-notvia-addresses-00 individual submission was > published in March 2005. This also precedes the patent. >=20 > The only reason I can see that notvia and XRO might be considered > different is that they don't specify a redundant tree. >=20 > Another question for legal types is whether computing redundant trees > is an algorithm (specifically a graph theory algorithm) and therefore > not patentable at all. Should a patent of this type specify the use > of a redundant tree algorithm in IP or LDP? Can a patent apply to the > use of *any* algorithm which falls within the classification of a > redundant tree algorithm in IP or LDP? >=20 > Of course, I am not an attorney so I cannot give a legal opinion on > this matter or any other legal matter. I am asking if there has ever > been such a discussion and whether my layperson legally uniformed > opinion might by chance be accurate or close to accurate. >=20 > If the patent is valid, does apply to the MRT work, and has no > licensing specified, IMHO the WG should cease to work on this. >=20 > Curtis >=20 >=20 > In message > <C03AAF38AD209F4BB02BC0A34B774CE7060394@G2W2446.americas.hpqcorp.net> > "Retana, Alvaro" writes: >=20 > As a reminder, having an IPR claim does not disqualify a draft from > advancing in the IETF, being adopted by a working group or from > eventually becoming a standard. It just represents one more item to be > considered by the working group. >=20 > http://www.ietf.org/ipr/policy.html >=20 > To help in the evaluation, the following link is to the patent > application itself (provided by the authors): >=20 > http://www.wipo.int/patentscope/search/en/detail.jsf?docId=3DWO2010055408 > &recNum=3D1&docAn=3DIB2009007467&queryString=3DFP:%28PCT/IB2009/007467%29= &max > Rec=3D1 >=20 >=20 > As a chair, my job is to remind the WG of the IETF policy -- the > decision of whether we should continue to work on this item is to be > made by the individuals participating in the WG. Because the concern > expressed by Curtis has come up several times (from different people), > including at the meeting in Taipei, I would like to hear other opinions > specific to the impact of the terms of the IPR filing with respect to > the architecture proposed. >=20 > Thanks! >=20 > Alvaro. >=20 >=20 > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > Behalf > > Of Curtis Villamizar > > Sent: Wednesday, June 20, 2012 11:53 AM > > To: Gabor.Sandor.Enyedi@ericsson.com; akatlas@juniper.net; > > rkebler@juniper.net; Andras.Csaszar@ericsson.com; russwh@cisco.com; > > mike@mshand.org.uk; maciek@bgp.nu; adrian@olddog.co.uk; > > stbryant@cisco.com; rtgwg@ietf.org > > Cc: patent.licensing@ericsson.com > > Subject: Re: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s > > Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture- > 01 > > > > > > In message <20120618155048.18575.97874.idtracker@ietfa.amsl.com> > > IETF Secretariat writes: > > > > > > > > Dear Gabor Sandor Envedi, Alia Atlas, Robert Kebler, Andras > Csaszar, > > > Russ White, Mike Shand, Maciek Konstantynowicz: > > > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "An > > > Architecture for IP/LDP Fast-Reroute Using Maximally Redundant > Trees" > > > (draft- ietf-rtgwg-mrt-frr-architecture) was submitted to the IETF > > > Secretariat on 2012-06-18 and has been posted on the "IETF Page of > > > Intellectual Property Rights Disclosures" > > > (https://datatracker.ietf.org/ipr/1801/). The title of the IPR > > > disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement > > > about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01.""); > > > > > > The IETF Secretariat > > > > > > Prior reasons to be hesitant about this work included the rather > > substantial change to routing and forwarding, and the need to deploy > > network wide (no accommodation for legacy equipment). Regardless, it > > became a WG item. > > > > Now that there is an IPR disclosure with no statement at all > regarding > > licensing terms, it might be time to reconsider whether the WG should > > go forward with this work. > > > > IMHO- If the IPR disclosure is not updated with a reasonable and > > non-discriminatory, preferably royalty-free, licensing statement, the > > MRT work should be abandoned by RTGWG. > > > > Curtis > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg From mach.chen@huawei.com Thu Jun 21 00:43:50 2012 Return-Path: <mach.chen@huawei.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6A121F8592 for <rtgwg@ietfa.amsl.com>; Thu, 21 Jun 2012 00:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 MPUbq95DAxH8 for <rtgwg@ietfa.amsl.com>; Thu, 21 Jun 2012 00:43:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 913C521F858F for <rtgwg@ietf.org>; Thu, 21 Jun 2012 00:43:49 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHC12585; Thu, 21 Jun 2012 03:43:47 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 21 Jun 2012 00:43:31 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 21 Jun 2012 00:43:29 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.177]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Thu, 21 Jun 2012 15:43:25 +0800 From: Mach Chen <mach.chen@huawei.com> To: Alia Atlas <akatlas@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org> Subject: =?gb2312?B?tPC4tDogcG9sbCB0byBhZG9wdCBkcmFmdC1zby15b25nLXJ0Z3dnLWNsLWZy?= =?gb2312?Q?amework-05_as_a_WG_draft?= Thread-Topic: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG draft Thread-Index: AQHNSNt4rBHR6lGLFEeWhbbRxAjcVpcEcUeA Date: Thu, 21 Jun 2012 07:43:25 +0000 Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE22C9C59B4@SZXEML511-MBS.china.huawei.com> References: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> In-Reply-To: <CAG4d1rf6X2u55iddNGk4hWD-OZbrPeXmyH4HyL9R-ao6Tgo+Gg@mail.gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.34] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 21 Jun 2012 06:55:07 -0700 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 21 Jun 2012 07:43:51 -0000 U3VwcG9ydC4NCg0KQmVzdCByZWdhcmRzLA0KTWFjaA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiC3orz+yMs6IHJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGd3Zy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIEFsaWENCj4gQXRsYXMNCj4gt6LLzcqxvOQ6IDIwMTLE6jbUwjEzyNUgNDoz OQ0KPiDK1bz+yMs6IHJ0Z3dnQGlldGYub3JnDQo+INb3zOI6IHBvbGwgdG8gYWRvcHQgZHJhZnQt c28teW9uZy1ydGd3Zy1jbC1mcmFtZXdvcmstMDUgYXMgYSBXRyBkcmFmdA0KPiANCj4gVGhpcyBl bWFpbCBpcyB0byBzdGFydCBhIHBvbGwgYW5kIGRpc2N1c3Npb24gb24gd2hldGhlciB0byBhZG9w dA0KPiBkcmFmdC1zby15b25nLXJ0Z3dnLWNsLWZyYW1ld29yay0wNSBhcyBhbiBSVEdXRyBkcmFm dC4NCj4gUGxlYXNlIHJlc3BvbmQgd2l0aCBvcGluaW9ucywgY29tbWVudHMsIGFuZCB3aGV0aGVy IHlvdSBoYXZlIHJlYWQgdGhlIGRyYWZ0Lg0KPiBMYXN0IElFVEYsIHRoZXJlIHdlcmUgdmVyeSBm ZXcgcGVvcGxlIHdobyBoYWQgcmVhZCB0aGUgZHJhZnQuDQo+IA0KPiBBdXRob3JzLCBwbGVhc2Ug aW5kaWNhdGUgaWYgdGhlcmUgaXMgYW55IElQUiBhc3NvY2lhdGVkIHdpdGggdGhpcyBkcmFmdC4N Cj4gDQo+IFRoYW5rcywNCj4gQWxpYQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBydGd3ZyBtYWlsaW5nIGxpc3QNCj4gcnRnd2dAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zw0K From mach.chen@huawei.com Thu Jun 21 00:45:49 2012 Return-Path: <mach.chen@huawei.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C3221F85A0 for <rtgwg@ietfa.amsl.com>; Thu, 21 Jun 2012 00:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 mgLv1-CE9WUK for <rtgwg@ietfa.amsl.com>; Thu, 21 Jun 2012 00:45:48 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CB8BA21F859F for <rtgwg@ietf.org>; Thu, 21 Jun 2012 00:45:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHJ42714; Thu, 21 Jun 2012 03:45:48 -0400 (EDT) Received: from DFWEML405-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.323.3; Thu, 21 Jun 2012 00:43:42 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 21 Jun 2012 00:43:47 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.177]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Thu, 21 Jun 2012 15:43:42 +0800 From: Mach Chen <mach.chen@huawei.com> To: Alia Atlas <akatlas@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org> Subject: =?gb2312?B?tPC4tDogcG9sbCBvbiBhZG9wdGluZyBkcmFmdC1zeW1tdm8tcnRnd2ctY2wt?= =?gb2312?Q?use-cases-00_as_WG_draft?= Thread-Topic: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG draft Thread-Index: AQHNSNsf8tDrXuG/+E+YcQWWDotGf5cEcWWA Date: Thu, 21 Jun 2012 07:43:42 +0000 Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE22C9C59BB@SZXEML511-MBS.china.huawei.com> References: <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> In-Reply-To: <CAG4d1re2mY6-tiapwfP_qYmdP7+uMeFApkHAfzODXHK6AosaLw@mail.gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.34] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 21 Jun 2012 06:55:07 -0700 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 21 Jun 2012 07:45:49 -0000 U3VwcG9ydC4NCg0KQmVzdCByZWdhcmRzLA0KTWFjaA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiC3orz+yMs6IHJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGd3Zy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIEFsaWENCj4gQXRsYXMNCj4gt6LLzcqxvOQ6IDIwMTLE6jbUwjEzyNUgNDoz Nw0KPiDK1bz+yMs6IHJ0Z3dnQGlldGYub3JnDQo+INb3zOI6IHBvbGwgb24gYWRvcHRpbmcgZHJh ZnQtc3ltbXZvLXJ0Z3dnLWNsLXVzZS1jYXNlcy0wMCBhcyBXRyBkcmFmdA0KPiANCj4gVGhpcyBp cyB0byBzdGFydCBhIHBvbGwgYW5kIGRpc2N1c3Npb24gYWJvdXQgd2hldGhlciBSVEdXRyBzaG91 bGQgYWRvcHQNCj4gZHJhZnQtc3ltbXZvLXJ0Z3dnLWNsLXVzZS1jYXNlcy0wMCBhcyBhIFdHIGRy YWZ0Lg0KPiANCj4gUGxlYXNlIHJlc3BvbmQgd2l0aCBjb21tZW50cyBhbmQgcmVhc29uaW5nIGFu ZCBpZiB5b3UgaGF2ZSByZWFkIHRoZSBkcmFmdC4NCj4gQXQgb3VyIGxhc3QgbWVldGluZywgdmVy eSBmZXcgcGVvcGxlIGluZGljYXRlZCB0aGF0IHRoZXkgaGFkIHJlYWQgdGhlIGRyYWZ0Lg0KPiAN Cj4gQXV0aG9ycywgcGxlYXNlIGluZGljYXRlIGluIGVtYWlsIHdoZXRoZXIgdGhlcmUgaXMgYW55 IElQUiBhc3NvY2lhdGVkDQo+IHdpdGggdGhlIGRyYWZ0Lg0KPiANCj4gVGhhbmtzLA0KPiBBbGlh DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0 Z3dnIG1haWxpbmcgbGlzdA0KPiBydGd3Z0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQo= From akatlas@gmail.com Thu Jun 21 07:51:01 2012 Return-Path: <akatlas@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C673721F8707 for <rtgwg@ietfa.amsl.com>; Thu, 21 Jun 2012 07:51:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2XcVV1aLf23 for <rtgwg@ietfa.amsl.com>; Thu, 21 Jun 2012 07:51:00 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B84F421F8718 for <rtgwg@ietf.org>; Thu, 21 Jun 2012 07:50:58 -0700 (PDT) Received: by ggnc4 with SMTP id c4so608394ggn.31 for <rtgwg@ietf.org>; Thu, 21 Jun 2012 07:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2m+2hXhezSrnLugoK0FbobT+vVwkVKbkQuq70khtezw=; b=Kyz8NAqwQz4oYsW2KKxgSYQor9TUhiZym1bBO3kojPtlpQN9AmTbB+Bn75NlA3VeVS y2TY5JwXFOqwlnQ75HG9CW4rwhJtbPRNy6ZSVJ0pAW9xcr+8zKPEfjHasU3c0lQlV3RS fTusbtLgNZp/KKs2/rRVh5T5W5gXKjPI6HsB27PCabB9FwhaCuCYFyA9euZbV342TsHU JHJVaG6t2rXPFD26tlypsOGCkFhRN1yHgzPbvuJUg1ppL/YHURKc4D7SIVZaKSzGtQnc PDZ+JWoO6w11/a+WIQUQoitUgE/A06FoNEfaMQA+DEhGrQiXxTclX4MAwNv1yLeXZFAO F58Q== MIME-Version: 1.0 Received: by 10.43.46.1 with SMTP id um1mr13218719icb.0.1340290258065; Thu, 21 Jun 2012 07:50:58 -0700 (PDT) Received: by 10.50.6.193 with HTTP; Thu, 21 Jun 2012 07:50:57 -0700 (PDT) In-Reply-To: <201206201552.q5KFqsat072252@gateway.ipv6.occnc.com> References: <20120618155048.18575.97874.idtracker@ietfa.amsl.com> <201206201552.q5KFqsat072252@gateway.ipv6.occnc.com> Date: Thu, 21 Jun 2012 10:50:57 -0400 Message-ID: <CAG4d1reJdVtBYXgMs4Jz9gAbqtykou12_8np+EyUrc6uMJpe9A@mail.gmail.com> Subject: Re: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 From: Alia Atlas <akatlas@gmail.com> To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: russwh@cisco.com, rkebler@juniper.net, mike@mshand.org.uk, patent.licensing@ericsson.com, akatlas@juniper.net, maciek@bgp.nu, adrian@olddog.co.uk, rtgwg@ietf.org, stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 21 Jun 2012 14:51:02 -0000 Curtis, First, this is EXACTLY the same IPR claim that was attached to the original draft before it became a WG draft. While I, personally, am not thrilled with the terms, the WG made a decision to accept the draft at the time regardless of those terms. Second, the MRT solution has changed somewhat from the original draft - including the ability to pre-select the alternate. Third, MRT is NOT a solution that has to be deployed across the entire network to be useful. Nor does it change normal forwarding and routing. For the LDP case, it simply provides additional forwarding paths using existing MPLS mechanisms. Naturally, it computes those forwarding paths with a algorithm other than basic SPF to obtain the desired results. I would certainly welcome your thoughtful comments on the drafts and would encourage you to read the more recent version. Alia (wg-chair hat off) On Wed, Jun 20, 2012 at 11:52 AM, Curtis Villamizar <curtis@occnc.com> wrot= e: > > In message <20120618155048.18575.97874.idtracker@ietfa.amsl.com> > IETF Secretariat writes: > >> >> Dear Gabor Sandor Envedi, Alia Atlas, Robert Kebler, Andras Csaszar, >> Russ White, Mike Shand, Maciek Konstantynowicz: >> >> =A0An IPR disclosure that pertains to your Internet-Draft entitled "An >> Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees" >> (draft- ietf-rtgwg-mrt-frr-architecture) was submitted to the IETF >> Secretariat on 2012-06-18 and has been posted on the "IETF Page of >> Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1801/). The title of the IPR >> disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement >> about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01.""); >> >> The IETF Secretariat > > > Prior reasons to be hesitant about this work included the rather > substantial change to routing and forwarding, and the need to deploy > network wide (no accommodation for legacy equipment). =A0Regardless, it > became a WG item. > > Now that there is an IPR disclosure with no statement at all regarding > licensing terms, it might be time to reconsider whether the WG should > go forward with this work. > > IMHO- If the IPR disclosure is not updated with a reasonable and > non-discriminatory, preferably royalty-free, licensing statement, the > MRT work should be abandoned by RTGWG. > > Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From N.Leymann@telekom.de Mon Jun 25 06:38:05 2012 Return-Path: <N.Leymann@telekom.de> 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 D8BAC21F8621 for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 06:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 EP7Siv6qFoUn for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 06:38:00 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB7C21F8647 for <rtgwg@ietf.org>; Mon, 25 Jun 2012 06:38:00 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 25 Jun 2012 15:37:58 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.126]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%15]) with mapi; Mon, 25 Jun 2012 15:37:03 +0200 From: <N.Leymann@telekom.de> To: <akatlas@gmail.com>, <rtgwg@ietf.org>, <pim-chairs@tools.ietf.org> Date: Mon, 25 Jun 2012 15:37:57 +0200 Subject: AW: poll on draft-karan-mofrr-02 to become a WG draft Thread-Topic: poll on draft-karan-mofrr-02 to become a WG draft Thread-Index: Ac1I28/eTgDoNqWcQH+x72xvIljcNQJ+91uw Message-ID: <9762ACF04FA26B4388476841256BDE020115F58EBF32@HE111543.emea1.cds.t-internal.com> References: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> In-Reply-To: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Jun 2012 13:38:05 -0000 Support! Regards Nic -----Urspr=FCngliche Nachricht----- Von: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] Im Auftrag von = Alia Atlas Gesendet: Dienstag, 12. Juni 2012 22:42 An: rtgwg@ietf.org; pim-chairs@tools.ietf.org Betreff: poll on draft-karan-mofrr-02 to become a WG draft This email is to start a poll and discussion on whether draft-karan-mofrr-02 should become an RTGWG draft. Please include comments, details, and whether you = have read the draft. The earlier version was presented positively to the PIM WG as well. Authors, please indicate whether there is any IPR associated with this draf= t. Thanks, Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From ice@cisco.com Mon Jun 25 06:45:35 2012 Return-Path: <ice@cisco.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AAD21F84D8 for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 06:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 9OZ2LPT3CtM5 for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 06:45:31 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6288D21F84CD for <rtgwg@ietf.org>; Mon, 25 Jun 2012 06:45:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-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 q5PDe6bI012785 for <rtgwg@ietf.org>; Mon, 25 Jun 2012 15:40:06 +0200 (CEST) Received: from ams-iwijnand-8719.cisco.com (ams-iwijnand-8719.cisco.com [10.55.191.154]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5PDe6Gx021964; Mon, 25 Jun 2012 15:40:06 +0200 (CEST) Subject: Re: poll on draft-karan-mofrr-02 to become a WG draft Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: IJsbrand Wijnands <ice@cisco.com> In-Reply-To: <8DCD771BDA4A394E9BCBA8932E839297783E30F23B@ESESSCMS0363.eemea.ericsson.se> Date: Mon, 25 Jun 2012 15:40:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0F771D1D-0038-4DE4-9673-32DD61845CF0@cisco.com> References: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> <8DCD771BDA4A394E9BCBA8932E839297783E30F23B@ESESSCMS0363.eemea.ericsson.se> To: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= <Andras.Csaszar@ericsson.com> X-Mailer: Apple Mail (2.1257) Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>, "pim-chairs@tools.ietf.org" <pim-chairs@tools.ietf.org> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Jun 2012 13:45:35 -0000 Hi Andras, > I started to realise I'm often too long, sorry for that :-) For this time we'll see it through the fingers (Dutch joke) :-) So in short, you're supporting the draft but some updates need to be = made, right? Thx! Ice. >=20 > Andr=E1s >=20 >=20 >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On = Behalf >> Of Alia Atlas >> Sent: 2012. j=FAnius 12. 22:42 >> To: rtgwg@ietf.org; pim-chairs@tools.ietf.org >> Subject: poll on draft-karan-mofrr-02 to become a WG draft >>=20 >> This email is to start a poll and discussion on whether >> draft-karan-mofrr-02 should >> become an RTGWG draft. Please include comments, details, and = whether >> you have >> read the draft. >>=20 >> The earlier version was presented positively to the PIM WG as well. >>=20 >> Authors, please indicate whether there is any IPR associated with = this >> draft. >>=20 >> Thanks, >> Alia >> _______________________________________________ >> 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 >=20 From Uwe.Joorde@telekom.de Mon Jun 25 06:59:41 2012 Return-Path: <Uwe.Joorde@telekom.de> 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 01CA521F85AD for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 06:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 moARBCeXqyZ4 for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 06:59:36 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7347D21F84FF for <rtgwg@ietf.org>; Mon, 25 Jun 2012 06:59:36 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 25 Jun 2012 15:59:35 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 25 Jun 2012 15:59:35 +0200 From: <Uwe.Joorde@telekom.de> To: <akatlas@gmail.com> Date: Mon, 25 Jun 2012 15:59:34 +0200 Subject: Re: poll on draft-karan-mofrr-02 to become a WG draft Thread-Topic: Re: poll on draft-karan-mofrr-02 to become a WG draft Thread-Index: Ac1S2sBg6W2hEbmBSz+G+Y2YGLvlCA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D14350E452E@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rtgwg@ietf.org, pim-chairs@tools.ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Jun 2012 13:59:41 -0000 Hi Alia, > This email is to start a poll and discussion on whether > draft-karan-mofrr-02 should > become an RTGWG draft. Please include comments, details, and whether yo= u have > read the draft. I support this draft to become a WG document. I am looking forward for future improvements of this draft. Cheers, Uwe Kind regards Uwe Joorde Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering Deutschland Uwe Joorde Hammer Str. 216-226, 48153 M=FCnster, Germany +49 2517985406 (Phone) E-Mail: mailto:uwe.joorde@telekom.de http://www.telekom.de Life is for sharing. Deutsche Telekom Netzproduktion GmbH Supervisory Board: Dr. Thomas Knoll (Chairman) Board of Management: Dr. Bruno Jacobfeuerborn (Chairman), Albert Matheis, K= laus Peren Commercial register: Amtsgericht Bonn HRB 14190 Registered office: Bonn VAT identification no. DE 814645262 Big changes start small - conserve resources by not printing every e-mail. From zali@cisco.com Mon Jun 25 07:03:53 2012 Return-Path: <zali@cisco.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B56821F85BD for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:03:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-Po15jRYeVS for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:03:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E07E721F8552 for <rtgwg@ietf.org>; Mon, 25 Jun 2012 07:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=1607; q=dns/txt; s=iport; t=1340633029; x=1341842629; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=o0K4tGUlT9CtVmSlFdOd/n8A9gUPeDUkmh4FJDACvqw=; b=kCsFu0qZBba/qUtVFLYgLZSGQQVBCEdJM1AzXvDFqeFFo0e0+thXKbYM 8fYhv1hRJxYOBZgNcB1UYNSVc9VSQkhoB2jlhLcnlOtVPdWRbcqdA5roX Pc2uZ7cKzA3fbPa3Wpi9tcCtjZjUthC78Jnfij3iiNxl+Z5Z6lRtlvfvM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFRv6E+tJXG//2dsb2JhbABEtiuBB4IYAQEBBAEBAQ8BHT4LDAQCAQgRBAEBCwYXAQYBIAYfCQgBAQQBEggRCYdbAwsLmQWVdg2JTopQYxqFCGADiBUzl2iDGYFmgn2BQQ X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="95673210" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jun 2012 14:03:47 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5PE3kdN022919; Mon, 25 Jun 2012 14:03:46 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jun 2012 09:03:45 -0500 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: poll on draft-karan-mofrr-02 to become a WG draft Date: Mon, 25 Jun 2012 09:03:43 -0500 Message-ID: <7CC717E2F49DAA4A827DA3FEA237111B08297BA0@XMB-RCD-103.cisco.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D14350E452E@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: poll on draft-karan-mofrr-02 to become a WG draft Thread-Index: Ac1S2sBg6W2hEbmBSz+G+Y2YGLvlCAAAHMEQ References: <580BEA5E3B99744AB1F5BFF5E9A3C67D14350E452E@HE111648.emea1.cds.t-internal.com> From: "Zafar Ali (zali)" <zali@cisco.com> To: <Uwe.Joorde@telekom.de>, <akatlas@gmail.com> X-OriginalArrivalTime: 25 Jun 2012 14:03:45.0278 (UTC) FILETIME=[55B3E1E0:01CD52DB] Cc: pim-chairs@tools.ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Jun 2012 14:03:53 -0000 Support++;=20 Thanks Regards ... Zafar=20 > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Uwe.Joorde@telekom.de > Sent: Monday, June 25, 2012 10:00 AM > To: akatlas@gmail.com > Cc: rtgwg@ietf.org; pim-chairs@tools.ietf.org > Subject: Re: poll on draft-karan-mofrr-02 to become a WG draft >=20 > Hi Alia, >=20 > > This email is to start a poll and discussion on whether > > draft-karan-mofrr-02 should > > become an RTGWG draft. Please include comments, details, and = whether > you have > > read the draft. >=20 > I support this draft to become a WG document. >=20 > I am looking forward for future improvements of this draft. >=20 > Cheers, Uwe >=20 >=20 >=20 >=20 >=20 > Kind regards > Uwe Joorde >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Fixed Mobile Engineering Deutschland > Uwe Joorde > Hammer Str. 216-226, 48153 M=FCnster, Germany > +49 2517985406 (Phone) > E-Mail: mailto:uwe.joorde@telekom.de > http://www.telekom.de >=20 > Life is for sharing. >=20 > Deutsche Telekom Netzproduktion GmbH > Supervisory Board: Dr. Thomas Knoll (Chairman) > Board of Management: Dr. Bruno Jacobfeuerborn (Chairman), Albert > Matheis, Klaus Peren > Commercial register: Amtsgericht Bonn HRB 14190 > Registered office: Bonn > VAT identification no. DE 814645262 >=20 > Big changes start small - conserve resources by not printing every e- > mail. > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From gjshep@gmail.com Mon Jun 25 07:18:47 2012 Return-Path: <gjshep@gmail.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B4D21F8617 for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 yYiREFJ7ka79 for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:18:43 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1F821F8623 for <rtgwg@ietf.org>; Mon, 25 Jun 2012 07:18:42 -0700 (PDT) Received: by bkty8 with SMTP id y8so3635321bkt.31 for <rtgwg@ietf.org>; Mon, 25 Jun 2012 07:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=o96WfroFPB7E+zZTjeEhofE/bqT3MWqmWLzWwmHZXhg=; b=xebw7B5rMRH1uvsB3z3NLt6TgKGD+HaytFivjQswvsEjNjwSmedspnHz0Ws7B7+aW9 w7av2yfz8AAxoAuZfdBxdibwdybtejgx03FjSyQ7ZQhIB6AmRjHW8KIcWj5PA2brOpAN YNOFxyn9bgkVqo2QCyu9sVJQR8EzS74yrIBQFp98bVBkoTHxP7EM7fnJi9ItvN+sY9g1 woUPSMeXXgIxlTVmqbutyE22cRZ2TEpizMkMusOcpsy6Wu0Zr6jG3qkm8PrwPKoDen1U 40mO+vnUF9Pk0ZWvd/xsuWEJsRPvpNdHEvmxoM5sPl0WYGXiyooDQH15MCbWYrjE7Pt5 0rZQ== MIME-Version: 1.0 Received: by 10.204.149.216 with SMTP id u24mr4043303bkv.36.1340633922054; Mon, 25 Jun 2012 07:18:42 -0700 (PDT) Received: by 10.204.68.13 with HTTP; Mon, 25 Jun 2012 07:18:42 -0700 (PDT) In-Reply-To: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> References: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> Date: Mon, 25 Jun 2012 07:18:42 -0700 Message-ID: <CABFReBopY1jRk-TpPifOKhekGdp9w9N4+BuJJM52fPnOUerW0A@mail.gmail.com> Subject: Re: poll on draft-karan-mofrr-02 to become a WG draft From: Greg Shepherd <gjshep@gmail.com> To: Alia Atlas <akatlas@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pim-chairs@tools.ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Jun 2012 14:18:47 -0000 I'm in support of this draft becoming a WG item. Greg On Tue, Jun 12, 2012 at 1:41 PM, Alia Atlas <akatlas@gmail.com> wrote: > This email is to start a poll and discussion on whether > draft-karan-mofrr-02 should > become an RTGWG draft. =A0 Please include comments, details, and whether = you have > read the draft. > > The earlier version was presented positively to the PIM WG as well. > > Authors, please indicate whether there is any IPR associated with this dr= aft. > > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From bruno.decraene@orange.com Mon Jun 25 07:27:33 2012 Return-Path: <bruno.decraene@orange.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B345F21F8642 for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, 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 kPwTV9hgXCW0 for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:27:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABB721F8469 for <rtgwg@ietf.org>; Mon, 25 Jun 2012 07:27:29 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id F1FB6264316; Mon, 25 Jun 2012 16:27:27 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D508B35C048; Mon, 25 Jun 2012 16:27:27 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 25 Jun 2012 16:27:27 +0200 From: <bruno.decraene@orange.com> To: Alia Atlas <akatlas@gmail.com> Subject: RE: poll on draft-karan-mofrr-02 to become a WG draft Thread-Topic: poll on draft-karan-mofrr-02 to become a WG draft Thread-Index: AQHNSNvPrulU6TZceUqORrDGTDjtF5cLKQfA Date: Mon, 25 Jun 2012 14:27:26 +0000 Message-ID: <25936_1340634447_4FE8754F_25936_10259_1_53C29892C857584299CBF5D05346208A09493D@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> In-Reply-To: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.25.134515 Cc: "pim-chairs@tools.ietf.org" <pim-chairs@tools.ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Jun 2012 14:27:33 -0000 Hi Alia, >From: Alia Atlas >Sent: Tuesday, June 12, 2012 10:42 PM > >This email is to start a poll and discussion on whether >draft-karan-mofrr-02 should >become an RTGWG draft. Please include comments, details, and whether you= have >read the draft. I've read this draft and support it to become a WG document. >The earlier version was presented positively to the PIM WG as well. > >Authors, please indicate whether there is any IPR associated with this dra= ft. I'm not aware of any IPR on my side. (For the sake of exhaustively, I'm aware of the IPR already disclosed in th= e datatracker: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_s= earch&document_search=3Ddraft-karan-mofrr ) Thanks, Bruno >Thanks, >Alia >_______________________________________________ >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 authorisation. 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 is not liable for message= s that have been modified, changed or falsified. Thank you. From alvaro.retana@hp.com Mon Jun 25 07:38:57 2012 Return-Path: <alvaro.retana@hp.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1091611E809B for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.598 X-Spam-Level: X-Spam-Status: No, score=-108.598 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 npG8xU8KUWrJ for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:38:56 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by ietfa.amsl.com (Postfix) with ESMTP id 57BBF11E8089 for <rtgwg@ietf.org>; Mon, 25 Jun 2012 07:38:54 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id 60B6CC37F; Mon, 25 Jun 2012 14:38:53 +0000 (UTC) Received: from G2W1954G.americas.hpqcorp.net (16.238.8.186) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Mon, 25 Jun 2012 14:38:36 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.116]) by G2W1954G.americas.hpqcorp.net ([16.238.8.186]) with mapi id 14.02.0283.003; Mon, 25 Jun 2012 14:38:35 +0000 From: "Retana, Alvaro" <alvaro.retana@hp.com> To: "'rtgwg@ietf.org'" <rtgwg@ietf.org> Subject: WGLC:draft-ietf-rtgwg-ordered-fib Thread-Topic: WGLC:draft-ietf-rtgwg-ordered-fib Thread-Index: Ac0uxCycKs5WB71IQmyvMcD/pptCDQ== Date: Mon, 25 Jun 2012 14:38:35 +0000 Message-ID: <C19072A5E9CD3C4B837A355526B16ED5594A834EDB@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.14] Content-Type: multipart/alternative; boundary="_000_C19072A5E9CD3C4B837A355526B16ED5594A834EDBGVW1338EXAame_" MIME-Version: 1.0 Cc: "'draft-ietf-rtgwg-ordered-fib@tools.ietf.org'" <draft-ietf-rtgwg-ordered-fib@tools.ietf.org> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Jun 2012 14:38:57 -0000 --_000_C19072A5E9CD3C4B837A355526B16ED5594A834EDBGVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! This message is to start the Working Group Last Call for 'Loop-free converg= ence using oFIB' (http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-0= 6). This last call will end on July 9, 2012. The intent is to publish this document as an Informational RFC...as has bee= n discussed in the mailing list and live meetings. Send any comments to the WG list. Please reply to this message if you are NOT in favor of having this documen= t progress. Thanks! Alvaro. --_000_C19072A5E9CD3C4B837A355526B16ED5594A834EDBGVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} h1 {mso-style-priority:9; mso-style-link:"Heading 1 Char"; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:24.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.Heading1Char {mso-style-name:"Heading 1 Char"; mso-style-priority:9; mso-style-link:"Heading 1"; font-family:"Times New Roman","serif"; font-weight:bold;} span.EmailStyle18 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hi!<o:p></o:p></p> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">This message is to start the Working Gr= oup Last Call for ‘Loop-free convergence using oFIB’ (<a href= =3D"http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-06">http://tool= s.ietf.org/html/draft-ietf-rtgwg-ordered-fib-06</a>).<o:p></o:p></span></h1= > <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">This last call will end on July 9, 2012= .<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">The intent is to publish this document = as an Informational RFC…as has been discussed in the mailing list and= live meetings.<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Send any comments to the WG list. <o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Please reply to this message if you are= NOT in favor of having this document progress.<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Thanks!<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Alvaro.<o:p></o:p></span></h1> </div> </body> </html> --_000_C19072A5E9CD3C4B837A355526B16ED5594A834EDBGVW1338EXAame_-- From alvaro.retana@hp.com Mon Jun 25 07:42:01 2012 Return-Path: <alvaro.retana@hp.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE6921F8644 for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.098 X-Spam-Level: X-Spam-Status: No, score=-108.098 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 zD-digIDy5qZ for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:41:59 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by ietfa.amsl.com (Postfix) with ESMTP id 62F5D21F8637 for <rtgwg@ietf.org>; Mon, 25 Jun 2012 07:41:59 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id 10550C359; Mon, 25 Jun 2012 14:41:59 +0000 (UTC) Received: from G1W3636G.americas.hpqcorp.net (16.193.48.87) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Mon, 25 Jun 2012 14:41:35 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.116]) by G1W3636G.americas.hpqcorp.net ([16.193.48.87]) with mapi id 14.02.0283.003; Mon, 25 Jun 2012 14:41:35 +0000 From: "Retana, Alvaro" <alvaro.retana@hp.com> To: "'rtgwg@ietf.org'" <rtgwg@ietf.org> Subject: WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses Thread-Topic: WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses Thread-Index: Ac1S4JzjIYpRCidZSaGbUZp9oKOliA== Date: Mon, 25 Jun 2012 14:41:33 +0000 Message-ID: <C03AAF38AD209F4BB02BC0A34B774CE7064A4B@G2W2446.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.14] Content-Type: multipart/alternative; boundary="_000_C03AAF38AD209F4BB02BC0A34B774CE7064A4BG2W2446americashp_" MIME-Version: 1.0 Cc: "draft-ietf-rtgwg-ipfrr-notvia-addresses@tools.ietf.org" <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 <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Jun 2012 14:42:01 -0000 --_000_C03AAF38AD209F4BB02BC0A34B774CE7064A4BG2W2446americashp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! This message is to start the Working Group Last Call for 'IP Fast Reroute U= sing Not-via Addresses' (http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-= notvia-addresses-09). This last call will end on July 9, 2012. The intent is to publish this document as an Informational RFC...as has bee= n discussed in the mailing list and live meetings. Send any comments to the WG list. Please reply to this message if you are NOT in favor of having this documen= t progress. Thanks! Alvaro. --_000_C03AAF38AD209F4BB02BC0A34B774CE7064A4BG2W2446americashp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} h1 {mso-style-priority:9; mso-style-link:"Heading 1 Char"; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:24.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.Heading1Char {mso-style-name:"Heading 1 Char"; mso-style-priority:9; mso-style-link:"Heading 1"; font-family:"Times New Roman","serif"; font-weight:bold;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hi!<o:p></o:p></p> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">This message is to start the Working Gr= oup Last Call for ‘</span><span style=3D"font-size:11.0pt;font-family= :"Calibri","sans-serif";font-weight:normal">IP Fast Rer= oute Using Not-via Addresses</span><span style=3D"font-size:11.0pt;font-family:"= Calibri","sans-serif";font-weight:normal">’ (<a href= =3D"http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-notvia-addresses-09">= http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-notvia-addresses-09</a>).= </span><span style=3D"font-size:11.0pt;font-family:"Calibri",&quo= t;sans-serif";font-weight:normal"><o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">This last call will end on July 9, 2012= .<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">The intent is to publish this document = as an Informational RFC…as has been discussed in the mailing list and= live meetings.<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Send any comments to the WG list. <o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Please reply to this message if you are= NOT in favor of having this document progress.<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Thanks!<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Alvaro.<o:p></o:p></span></h1> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_C03AAF38AD209F4BB02BC0A34B774CE7064A4BG2W2446americashp_-- From alvaro.retana@hp.com Mon Jun 25 07:44:53 2012 Return-Path: <alvaro.retana@hp.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F319011E8089 for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.798 X-Spam-Level: X-Spam-Status: No, score=-107.798 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 zwwERwxY51VH for <rtgwg@ietfa.amsl.com>; Mon, 25 Jun 2012 07:44:48 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by ietfa.amsl.com (Postfix) with ESMTP id D1B3121F8647 for <rtgwg@ietf.org>; Mon, 25 Jun 2012 07:44:47 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (gvt0525.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id 33808C323; Mon, 25 Jun 2012 14:44:47 +0000 (UTC) Received: from G1W3625G.americas.hpqcorp.net (16.193.48.83) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.2.283.4; Mon, 25 Jun 2012 14:44:16 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.116]) by G1W3625G.americas.hpqcorp.net ([16.193.48.83]) with mapi id 14.02.0283.003; Mon, 25 Jun 2012 14:44:13 +0000 From: "Retana, Alvaro" <alvaro.retana@hp.com> To: "'rtgwg@ietf.org'" <rtgwg@ietf.org> Subject: RE: WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses Thread-Topic: WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses Thread-Index: Ac1S4JzjIYpRCidZSaGbUZp9oKOliAAADnag Date: Mon, 25 Jun 2012 14:44:11 +0000 Message-ID: <C03AAF38AD209F4BB02BC0A34B774CE7064A75@G2W2446.americas.hpqcorp.net> References: <C03AAF38AD209F4BB02BC0A34B774CE7064A4B@G2W2446.americas.hpqcorp.net> In-Reply-To: <C03AAF38AD209F4BB02BC0A34B774CE7064A4B@G2W2446.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.14] Content-Type: multipart/alternative; boundary="_000_C03AAF38AD209F4BB02BC0A34B774CE7064A75G2W2446americashp_" MIME-Version: 1.0 Cc: "draft-ietf-rtgwg-ipfrr-notvia-addresses@tools.ietf.org" <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 <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Jun 2012 14:44:53 -0000 --_000_C03AAF38AD209F4BB02BC0A34B774CE7064A75G2W2446americashp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ooops...sorry, got too excited about WGLCs. We already went through the WGLC of this draft at the start of this year. := ) Alvaro. From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of R= etana, Alvaro Sent: Monday, June 25, 2012 10:42 AM To: 'rtgwg@ietf.org' Cc: draft-ietf-rtgwg-ipfrr-notvia-addresses@tools.ietf.org Subject: WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses Hi! This message is to start the Working Group Last Call for 'IP Fast Reroute U= sing Not-via Addresses' (http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-= notvia-addresses-09). This last call will end on July 9, 2012. The intent is to publish this document as an Informational RFC...as has bee= n discussed in the mailing list and live meetings. Send any comments to the WG list. Please reply to this message if you are NOT in favor of having this documen= t progress. Thanks! Alvaro. --_000_C03AAF38AD209F4BB02BC0A34B774CE7064A75G2W2446americashp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} h1 {mso-style-priority:9; mso-style-link:"Heading 1 Char"; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:24.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.Heading1Char {mso-style-name:"Heading 1 Char"; mso-style-priority:9; mso-style-link:"Heading 1"; font-family:"Times New Roman","serif"; font-weight:bold;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Ooops…sorry, got= too excited about WGLCs.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">We already went throug= h the WGLC of this draft at the start of this year. </span><span style=3D"font-family:Wingdings;color:#1F497D">J</span><span st= yle=3D"color:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Alvaro.<o:p></o:p></sp= an></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> rtgwg-bo= unces@ietf.org [mailto:rtgwg-bounces@ietf.org] <b>On Behalf Of </b>Retana, Alvaro<br> <b>Sent:</b> Monday, June 25, 2012 10:42 AM<br> <b>To:</b> 'rtgwg@ietf.org'<br> <b>Cc:</b> draft-ietf-rtgwg-ipfrr-notvia-addresses@tools.ietf.org<br> <b>Subject:</b> WGLC:draft-ietf-rtgwg-ipfrr-notvia-addresses<o:p></o:p></sp= an></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Hi!<o:p></o:p></p> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">This message is to start the Working Gr= oup Last Call for ‘IP Fast Reroute Using Not-via Addresses’ (<a= href=3D"http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-notvia-addresses= -09">http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-notvia-addresses-09<= /a>).<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">This last call will end on July 9, 2012= .<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">The intent is to publish this document = as an Informational RFC…as has been discussed in the mailing list and= live meetings.<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Send any comments to the WG list. <o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Please reply to this message if you are= NOT in favor of having this document progress.<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Thanks!<o:p></o:p></span></h1> <h1><span style=3D"font-size:11.0pt;font-family:"Calibri","s= ans-serif";font-weight:normal">Alvaro.<o:p></o:p></span></h1> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </body> </html> --_000_C03AAF38AD209F4BB02BC0A34B774CE7064A75G2W2446americashp_-- From alvaro.retana@hp.com Thu Jun 28 17:53:44 2012 Return-Path: <alvaro.retana@hp.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4C11E80A2 for <rtgwg@ietfa.amsl.com>; Thu, 28 Jun 2012 17:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 HEMXzgk7JaUu for <rtgwg@ietfa.amsl.com>; Thu, 28 Jun 2012 17:53:43 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAE311E809F for <rtgwg@ietf.org>; Thu, 28 Jun 2012 17:53:42 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t0006.atlanta.hp.com (Postfix) with ESMTPS id 8D863C356 for <rtgwg@ietf.org>; Fri, 29 Jun 2012 00:53:39 +0000 (UTC) Received: from G2W1814G.americas.hpqcorp.net (16.238.8.213) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Fri, 29 Jun 2012 00:52:11 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.116]) by G2W1814G.americas.hpqcorp.net ([16.238.8.213]) with mapi id 14.02.0283.003; Fri, 29 Jun 2012 00:52:11 +0000 From: "Retana, Alvaro" <alvaro.retana@hp.com> To: "'rtgwg@ietf.org'" <rtgwg@ietf.org> Subject: FW: rtgwg - Requested session has been scheduled for IETF 84 Thread-Topic: rtgwg - Requested session has been scheduled for IETF 84 Thread-Index: AQHNVWjBAc+3r2BvFU6+oTxOPdTEqJcQd17Q Date: Fri, 29 Jun 2012 00:52:10 +0000 Message-ID: <C03AAF38AD209F4BB02BC0A34B774CE706DA95@G2W2446.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.25] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 Jun 2012 00:53:44 -0000 RllJDQoNClRoaXMgaXMgdGhlIGluaXRpYWwgYXNzaWdubWVudCBvZiBhIHNsb3QgaW4gVmFuY291 dmVyLg0KDQpQbGVhc2Ugc3RhcnQgdGhpbmtpbmcgYWJvdXQgYWdlbmRhIGl0ZW1zLg0KDQpUaGFu a3MhDQoNCkFsdmFyby4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206ICJJRVRG IFNlY3JldGFyaWF0IiBbbWFpbHRvOmFnZW5kYUBpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwg SnVuZSAyOCwgMjAxMiA0OjAxIFBNDQpUbzogYXJldGFuYUBjaXNjby5jb20NCkNjOiBydGd3Zy1h ZHNAdG9vbHMuaWV0Zi5vcmc7IFJldGFuYSwgQWx2YXJvOyBha2F0bGFzQGdtYWlsLmNvbTsgd2xv QGFtc2wuY29tDQpTdWJqZWN0OiBydGd3ZyAtIFJlcXVlc3RlZCBzZXNzaW9uIGhhcyBiZWVuIHNj aGVkdWxlZCBmb3IgSUVURiA4NA0KDQpEZWFyIEFsdmFybyBSZXRhbmEsDQoNClRoZSBzZXNzaW9u KHMpIHRoYXQgeW91IGhhdmUgcmVxdWVzdGVkIGhhdmUgYmVlbiBzY2hlZHVsZWQuDQpCZWxvdyBp cyB0aGUgc2NoZWR1bGVkIHNlc3Npb24gaW5mb3JtYXRpb24gZm9sbG93ZWQgYnkNCnRoZSBvcmln aW5hbCByZXF1ZXN0LiANCg0KcnRnd2cgU2Vzc2lvbiAxICgxOjMwOjAwKQ0KICAgIFR1ZXNkYXks IEFmdGVybm9vbiBTZXNzaW9uIElJIDE1MjAtMTY1MA0KICAgIFJvb20gTmFtZTogUmVnZW5jeSBF DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAg DQoNCg== From Andras.Csaszar@ericsson.com Fri Jun 29 04:31:53 2012 Return-Path: <Andras.Csaszar@ericsson.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAD021F86C3 for <rtgwg@ietfa.amsl.com>; Fri, 29 Jun 2012 04:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsxoag1cxq-n for <rtgwg@ietfa.amsl.com>; Fri, 29 Jun 2012 04:31:53 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B0FFC21F86B8 for <rtgwg@ietf.org>; Fri, 29 Jun 2012 04:31:52 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc26d000005908-ea-4fed922737b3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 88.11.22792.7229DEF4; Fri, 29 Jun 2012 13:31:51 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.82]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 29 Jun 2012 13:31:51 +0200 From: =?utf-8?B?QW5kcsOhcyBDc8Ohc3rDoXI=?= <Andras.Csaszar@ericsson.com> To: IJsbrand Wijnands <ice@cisco.com> Date: Fri, 29 Jun 2012 13:31:48 +0200 Subject: RE: poll on draft-karan-mofrr-02 to become a WG draft Thread-Topic: poll on draft-karan-mofrr-02 to become a WG draft Thread-Index: Ac1S2AlDk7h02kFJRLi2rYAC/QqobwDErS/A Message-ID: <8DCD771BDA4A394E9BCBA8932E839297872B14C490@ESESSCMS0363.eemea.ericsson.se> References: <CAG4d1rdwJ281N2okVpP+mwDoy-Nhhqnju2efnq2ooJerZaxYuA@mail.gmail.com> <8DCD771BDA4A394E9BCBA8932E839297783E30F23B@ESESSCMS0363.eemea.ericsson.se> <0F771D1D-0038-4DE4-9673-32DD61845CF0@cisco.com> In-Reply-To: <0F771D1D-0038-4DE4-9673-32DD61845CF0@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvra76pLf+BrvbTCw+PbzEbPFqzh1m i58N55gtLrz5zezA4jHl90ZWj52z7rJ7LFnyk8njy+XPbAEsUVw2Kak5mWWpRfp2CVwZ+xcs YytYJFhxYtI09gbGFwJdjJwcEgImEo0d+5khbDGJC/fWs3UxcnEICZxilHi2YS4LhDOHUeLn 1c+MIFVsAh4S96//BesQEVCVOHJsLztIEbNAA6PEtd8b2UASLECJr092s4DYwgJ2EosWTAYq 4gBqsJdYdUgWotdIovvqJlYQm1cgXOLXnsWMEMsuMkpcbdsGNodTwFZi6tYLrCC9jAKyEg/X WoCEmQXEJW49mc8EcbWAxJI956E+EJV4+fgf2ExGARmJD0sPsYG0MgtoSqzfpQ/Rqigxpfsh O8RaQYmTM5+wTGAUm4Vk6iyEjllIOmYh6VjAyLKKUTg3MTMnvdxQL7UoM7m4OD9Przh1EyMw wg5u+a27g/HUOZFDjNIcLErivFxJ+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MGZv4Vt9 sfMVp3Byzn/nBq4VE7PLVJ4zcW53kmW9/nkpQ9VytfZHW354xX75pPO9N/pr6qee6w6NUTO0 FSfwy9gu+tETmJjWeNfn6Yd/dwV0mouflFTVF+/dPs9GoPmQ0m+99zmCt2V12HOS5p6refRT Kv2I2oxr9+53HSt5H7fj3z82j0iuH0osxRmJhlrMRcWJADpkznJ+AgAA Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>, "pim-chairs@tools.ietf.org" <pim-chairs@tools.ietf.org> X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 Jun 2012 11:31:53 -0000 WWVzLCBhYnNvbHV0ZWx5Lg0KQW5kcsOhcw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IElKc2JyYW5kIFdpam5hbmRzIFttYWlsdG86aWNlQGNpc2NvLmNvbV0NCj4gU2Vu dDogMjAxMi4gasO6bml1cyAyNS4gMTU6NDANCj4gVG86IEFuZHLDoXMgQ3PDoXN6w6FyDQo+IENj OiBBbGlhIEF0bGFzOyBydGd3Z0BpZXRmLm9yZzsgcGltLWNoYWlyc0B0b29scy5pZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogcG9sbCBvbiBkcmFmdC1rYXJhbi1tb2Zyci0wMiB0byBiZWNvbWUgYSBX RyBkcmFmdA0KPiANCj4gSGkgQW5kcmFzLA0KPiANCj4gPiBJIHN0YXJ0ZWQgdG8gcmVhbGlzZSBJ J20gb2Z0ZW4gdG9vIGxvbmcsIHNvcnJ5IGZvciB0aGF0IDotKQ0KPiANCj4gRm9yIHRoaXMgdGlt ZSB3ZSdsbCBzZWUgaXQgdGhyb3VnaCB0aGUgZmluZ2VycyAoRHV0Y2ggam9rZSkgOi0pDQo+IA0K PiBTbyBpbiBzaG9ydCwgeW91J3JlIHN1cHBvcnRpbmcgdGhlIGRyYWZ0IGJ1dCBzb21lIHVwZGF0 ZXMgbmVlZCB0byBiZQ0KPiBtYWRlLCByaWdodD8NCj4gDQo+IFRoeCENCj4gDQo+IEljZS4NCj4g DQo+ID4NCj4gPiBBbmRyw6FzDQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+PiBGcm9tOiBydGd3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRnd2ctYm91 bmNlc0BpZXRmLm9yZ10gT24NCj4gPj4gQmVoYWxmIE9mIEFsaWEgQXRsYXMNCj4gPj4gU2VudDog MjAxMi4gasO6bml1cyAxMi4gMjI6NDINCj4gPj4gVG86IHJ0Z3dnQGlldGYub3JnOyBwaW0tY2hh aXJzQHRvb2xzLmlldGYub3JnDQo+ID4+IFN1YmplY3Q6IHBvbGwgb24gZHJhZnQta2FyYW4tbW9m cnItMDIgdG8gYmVjb21lIGEgV0cgZHJhZnQNCj4gPj4NCj4gPj4gVGhpcyBlbWFpbCBpcyB0byBz dGFydCBhIHBvbGwgYW5kIGRpc2N1c3Npb24gb24gd2hldGhlcg0KPiA+PiBkcmFmdC1rYXJhbi1t b2Zyci0wMiBzaG91bGQNCj4gPj4gYmVjb21lIGFuIFJUR1dHIGRyYWZ0LiAgIFBsZWFzZSBpbmNs dWRlIGNvbW1lbnRzLCBkZXRhaWxzLCBhbmQNCj4gd2hldGhlcg0KPiA+PiB5b3UgaGF2ZQ0KPiA+ PiByZWFkIHRoZSBkcmFmdC4NCj4gPj4NCj4gPj4gVGhlIGVhcmxpZXIgdmVyc2lvbiB3YXMgcHJl c2VudGVkIHBvc2l0aXZlbHkgdG8gdGhlIFBJTSBXRyBhcyB3ZWxsLg0KPiA+Pg0KPiA+PiBBdXRo b3JzLCBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB0aGVyZSBpcyBhbnkgSVBSIGFzc29jaWF0ZWQg d2l0aA0KPiA+PiB0aGlzIGRyYWZ0Lg0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+ID4+IEFsaWENCj4g Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4g cnRnd2cgbWFpbGluZyBsaXN0DQo+ID4+IHJ0Z3dnQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHJ0Z3dnIG1haWxpbmcgbGlzdA0KPiA+ IHJ0Z3dnQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGd3Zw0KPiA+DQoNCg== From curtis@occnc.com Fri Jun 29 07:22:17 2012 Return-Path: <curtis@occnc.com> X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8CE21F8683 for <rtgwg@ietfa.amsl.com>; Fri, 29 Jun 2012 07:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.509, 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 V00RkGLctkjr for <rtgwg@ietfa.amsl.com>; Fri, 29 Jun 2012 07:22:16 -0700 (PDT) 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 EC1B721F8513 for <rtgwg@ietf.org>; Fri, 29 Jun 2012 07:22:15 -0700 (PDT) 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 q5TEMAde081284; Fri, 29 Jun 2012 07:22:10 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201206291422.q5TEMAde081284@gateway.ipv6.occnc.com> To: RTGWG <rtgwg@ietf.org> Subject: fwd: should I hold off on updating the CL framework draft? From: Curtis Villamizar <curtis@occnc.com> Date: Fri, 29 Jun 2012 10:22:10 -0400 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:rtgwg@ietf.org> List-Help: <mailto:rtgwg-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 Jun 2012 14:22:17 -0000 There were no objections. Therefore draft-so-yong-rtgwg-cl-framework-06 has been submited. The draft is at http://datatracker.ietf.org/doc/draft-so-yong-rtgwg-cl-framework/ Diifs are at http://tools.ietf.org/rfcdiff?url2=draft-so-yong-rtgwg-cl-framework-06 Briefly diffs are: date and version number Consolidate text on IP and LDP. Split "Section 4.2.4. Accounting for IP and LDP Traffic " into "Section 4.2.4. Accounting for IP and LDP Traffic" and "Section 4.2.5. IP and LDP Limitations". Numerous minor wording changes. Added summary list to bottom of "Section 2.1. Flow Identification" Consolidated discussion of scalability, moving text to one place and using cross reference rather than partial duplication. Say a little about what a "large network" is (provider network). Remove "Section 7.2.2. Component Group Metric". Move text (one paragraph) into "Section 7.2.1. Component Link Grouping". Add cross references back from subsections 7.2.x (in "Section 7.2. Required Document Coverage") listing the set of requirement groups that each suggested document focuses on and list the set of requirement groups that must be considered. Change Ning So's affiliation. Change Lucy Yong's address. Brief addition to acknowledgements. These diffs were already sent to the RTGWG mailing list so there should be no surprises. Curtis ------- Forwarded Message Message-Id: <201206201916.q5KJGiCL081261@gateway.ipv6.occnc.com> To: RTGWG <rtgwg@ietf.org> cc: curtis@occnc.com Reply-To: curtis@occnc.com Subject: should I hold off on updating the CL framework draft? From: Curtis Villamizar <curtis@occnc.com> Date: Wed, 20 Jun 2012 15:16:44 -0400 RTGWG, We are in a poll on "Composite Link Framework in Multi Protocol Label Switching (MPLS)", aka the CL Framework (currently draft-so-yong-rtgwg-cl-framework-05, would be updated to -06). Are there any objections from the WG to updating the CL framework from the current -05 version to an -06 version to reflect the discussion on the WG mailing list and making those updates during the poll? BTW- Primary participants in the WG mailing list discussion were Iftekhar Hussain, Lucy Yong, and myself. Kireeti Kompella made comments in response to Iftekhar, but regarding requirements implied by the CL Framework. Curtis ------- End of Forwarded Message