From wenhu.lu@ericsson.com Wed Nov 3 16:59:46 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680353A69FB for ; Wed, 3 Nov 2010 16:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF4e8nwnplJV for ; Wed, 3 Nov 2010 16:59:45 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 9D5293A69FA for ; Wed, 3 Nov 2010 16:59:45 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oA3NxrJV030905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Nov 2010 18:59:53 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 3 Nov 2010 19:59:52 -0400 From: Wenhu Lu To: "rtgwg@ietf.org" Date: Wed, 3 Nov 2010 19:59:51 -0400 Subject: Review request for draft-lu-fast-notification-framework-00.txt Thread-Topic: Review request for draft-lu-fast-notification-framework-00.txt Thread-Index: Act7szQzbZX2lm5CT2OZOBR5uqD7Qw== Message-ID: <8249B703AE8442429AF89B86E8206AA26EEB5F091A@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8249B703AE8442429AF89B86E8206AA26EEB5F091AEUSAACMS0703e_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 23:59:46 -0000 --_000_8249B703AE8442429AF89B86E8206AA26EEB5F091AEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, We would like to solicit comments and inputs of the new draft "Fast Notific= ation Framework". This document describes an architectural work that competes with the IP Fast Re-Route (IPFRR) solution which aims to minimize the network down time in the event of equipments failure. The work provides a layered framework based upon which applications such as the domain- wide fast convergence may be achieved through the transport layer fast delivery of failure notifications. We plan to give a presentation on this in the upcoming IETF79. The draft can be found at http://tools.ietf.org/html/draft-lu-fast-notifica= tion-framework-00 Your review and comments are greatly appreciated. Thank you, -wenhu --_000_8249B703AE8442429AF89B86E8206AA26EEB5F091AEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
 
We would like to solicit comments and inputs of the new draft "Fa= st Notification Framework".
 
   This document describes an architectural work that compet= es with the
   IP Fast Re-Route (IPFRR) solution which aims to minimize = the network
   down time in the event of equipments failure.  The w= ork provides a
   layered framework based upon which applications such as t= he domain-
   wide fast convergence may be achieved through the transpo= rt layer
   fast delivery of failure notifications.
 
We plan to give a presentation on this in the upcoming IETF79.
 
Your review and comments are greatly appreciated.
 
Thank you,
-wenhu
 
 --_000_8249B703AE8442429AF89B86E8206AA26EEB5F091AEUSAACMS0703e_-- From mshand@cisco.com Thu Nov 4 02:07:41 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6C93A69F6 for ; Thu, 4 Nov 2010 02:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubbe+cdB5Uw6 for ; Thu, 4 Nov 2010 02:07:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D4CD53A6A5C for ; Thu, 4 Nov 2010 02:05:24 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4EAKQT0kyQ/khNgWdsb2JhbACTb44EFQEBFiIiojabLIVGBIpVgwg X-IronPort-AV: E=Sophos;i="4.58,294,1286150400"; d="scan'208";a="68291831" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2010 09:05:33 +0000 Received: from [10.61.92.137] (ams3-vpn-dhcp7306.cisco.com [10.61.92.137]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oA495XeW012583 for ; Thu, 4 Nov 2010 09:05:33 GMT Message-ID: <4CD2775D.2070602@cisco.com> Date: Thu, 04 Nov 2010 09:05:33 +0000 From: mike shand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: Review request for draft-lu-fast-notification-framework-00.txt References: <8249B703AE8442429AF89B86E8206AA26EEB5F091A@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <8249B703AE8442429AF89B86E8206AA26EEB5F091A@EUSAACMS0703.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 09:07:41 -0000 This draft seems to completely miss the point. It focusses on attempting to improve the time to distribute failure information (although it is not clear that the proposed methods offer significantly faster propagation of information than that already achieved by a well tuned IGP flooding process). But it completely ignores the time taken to process that information and update the hardware forwarding tables, which, as is well known, is the rate determining step. Mike On 03/11/2010 23:59, Wenhu Lu wrote: > Dear all, > We would like to solicit comments and inputs of the new draft "Fast > Notification Framework". > This document describes an architectural work that competes with the > IP Fast Re-Route (IPFRR) solution which aims to minimize the network > down time in the event of equipments failure. The work provides a > layered framework based upon which applications such as the domain- > wide fast convergence may be achieved through the transport layer > fast delivery of failure notifications. > We plan to give a presentation on this in the upcoming IETF79. > The draft can be found at > _http://tools.ietf.org/html/draft-lu-fast-notification-framework-00_ > Your review and comments are greatly appreciated. > Thank you, > -wenhu > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg -- For corporate legal information go to: www.cisco.com/web/about/doing_business/legal/cri From wenhu.lu@ericsson.com Thu Nov 4 14:28:39 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980CD3A6A46 for ; Thu, 4 Nov 2010 14:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wsm92KTGdMj1 for ; Thu, 4 Nov 2010 14:28:38 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 0FB8B3A6A3B for ; Thu, 4 Nov 2010 14:28:37 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oA4LoqtI009544 for ; Thu, 4 Nov 2010 16:50:53 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 4 Nov 2010 17:27:59 -0400 From: Wenhu Lu To: "rtgwg@ietf.org" Date: Thu, 4 Nov 2010 17:27:58 -0400 Subject: RE: Review request for draft-lu-fast-notification-framework-00.txt Thread-Topic: Review request for draft-lu-fast-notification-framework-00.txt Thread-Index: Act7//rOpJARWI62S5W69+Ui0v9hwwAYB68g Message-ID: <8249B703AE8442429AF89B86E8206AA26EEB63ED16@EUSAACMS0703.eamcs.ericsson.se> References: <8249B703AE8442429AF89B86E8206AA26EEB5F091A@EUSAACMS0703.eamcs.ericsson.se> <4CD2775D.2070602@cisco.com> In-Reply-To: <4CD2775D.2070602@cisco.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.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 21:28:39 -0000 Hi Mike, Thank you very much for the review and comments. Let me outline what this draft intends to achieve. The proposed framework separates the domain-wide total convergence time int= o Network delay + local delay. These two delays are independent and can be improved independently. Do you = agree? The network delay part can be minimized or even eliminated if some good fas= t notification measure is employed in the transport layer. This is part of = the goals of this draft. We will discuss this in detail in the upcoming IET= F meeting when we get chance. The local delay is also very important. It is an integral part of the overa= ll convergence. We didn't ignore this and mentioned it in section 4.4.=20 However this should not be a reason to drag the effort in reducing the netw= ork prapagation delay. Do you agree? As for the local delay, we understand that for now the route download time = is a significant factor of convergence. But who can say this won't change g= iven the time and so many smart brains. Regards, -wenhu -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of m= ike shand Sent: Thursday, November 04, 2010 2:06 AM To: rtgwg@ietf.org Subject: Re: Review request for draft-lu-fast-notification-framework-00.txt This draft seems to completely miss the point. It focusses on attempting = to improve the time to distribute failure information (although it is not c= lear that the proposed methods offer significantly faster propagation of in= formation than that already achieved by a well tuned IGP flooding process).= But it completely ignores the time taken to process that information and u= pdate the hardware forwarding tables, which, as is well known, is the rate = determining step. Mike On 03/11/2010 23:59, Wenhu Lu wrote: > Dear all, > We would like to solicit comments and inputs of the new draft "Fast=20 > Notification Framework". > This document describes an architectural work that competes with the > IP Fast Re-Route (IPFRR) solution which aims to minimize the network > down time in the event of equipments failure. The work provides a > layered framework based upon which applications such as the domain- > wide fast convergence may be achieved through the transport layer > fast delivery of failure notifications. > We plan to give a presentation on this in the upcoming IETF79. > The draft can be found at > _http://tools.ietf.org/html/draft-lu-fast-notification-framework-00_ > Your review and comments are greatly appreciated. > Thank you, > -wenhu > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg -- For corporate legal information go to: www.cisco.com/web/about/doing_business/legal/cri _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From olivier.bonaventure@uclouvain.be Thu Nov 4 15:17:42 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD0828C0EF for ; Thu, 4 Nov 2010 15:17:42 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyMlvC2drrvB for ; Thu, 4 Nov 2010 15:17:41 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 0332D28C0E6 for ; Thu, 4 Nov 2010 15:17:40 -0700 (PDT) Received: from mbpobo.local (ip-83-134-219-25.dsl.scarlet.be [83.134.219.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 62E16F2790; Thu, 4 Nov 2010 23:17:30 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be 62E16F2790 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1288909050; bh=hb/3aFrx73wMb9KdKvE2pVbjhUeduBnOBRfA87A5Lfg=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Dliu+zH4yXbEd3OS/rCOuumOrfEOAj9JY3xFhlWlPTiwFrZuTijm2WUPNxv0u7e1R nbvin+K7tZKUFkvMFeia1FYFOn6yVqXsuxV3Jx9IdiCJvLlIBaTZ4ssCi0AUIVW4Br SLwjzUUDlWh2jlgAbzcv6XbZ80+7txYmptILW30I= Message-ID: <4CD330F9.20708@uclouvain.be> Date: Thu, 04 Nov 2010 23:17:29 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b3pre Thunderbird/3.1.6 MIME-Version: 1.0 To: Wenhu Lu Subject: Re: Review request for draft-lu-fast-notification-framework-00.txt References: <8249B703AE8442429AF89B86E8206AA26EEB5F091A@EUSAACMS0703.eamcs.ericsson.se> <4CD2775D.2070602@cisco.com> <8249B703AE8442429AF89B86E8206AA26EEB63ED16@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <8249B703AE8442429AF89B86E8206AA26EEB63ED16@EUSAACMS0703.eamcs.ericsson.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.4-exp at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 62E16F2790.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 22:17:42 -0000 Wenhu, > > Thank you very much for the review and comments. > > Let me outline what this draft intends to achieve. > The proposed framework separates the domain-wide total convergence time into > Network delay + local delay. > These two delays are independent and can be improved independently. Do you agree? > > The network delay part can be minimized or even eliminated if some good fast notification measure is employed in the transport layer. This is part of the goals of this draft. We will discuss this in detail in the upcoming IETF meeting when we get chance. > The local delay is also very important. It is an integral part of the overall convergence. We didn't ignore this and mentioned it in section 4.4. > However this should not be a reason to drag the effort in reducing the network prapagation delay. Do you agree? I'm not sure that reducing the network delay will have an impact on the overall performance. In a 2005 paper, we performed simulations to study the factors that influence the convergence time of routing protocols in ISP networks and found that as Mike noted that the propagation delay of the failure notification did not influence the convergence time significantly. See http://inl.info.ucl.ac.be/publications/achieving-sub-second-igp-convergence- and look e.g. for the simulation results for the convergence time in a worldwide network were all link delays are set to 1 millisecond instead of the actual propagation delay Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From wenhu.lu@ericsson.com Thu Nov 4 15:46:45 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2480D28C0E2 for ; Thu, 4 Nov 2010 15:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfHKaYpeowPk for ; Thu, 4 Nov 2010 15:46:44 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id F381A3A6948 for ; Thu, 4 Nov 2010 15:46:43 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oA4MksUu029321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Nov 2010 17:46:54 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 4 Nov 2010 18:46:53 -0400 From: Wenhu Lu To: "rtgwg@ietf.org" Date: Thu, 4 Nov 2010 18:46:52 -0400 Subject: RE: Review request for draft-lu-fast-notification-framework-00.txt Thread-Topic: Review request for draft-lu-fast-notification-framework-00.txt Thread-Index: Act8bjw+V/gC8QmOQIyplRtk6BReGwAA4wyA Message-ID: <8249B703AE8442429AF89B86E8206AA26EEB63EDAD@EUSAACMS0703.eamcs.ericsson.se> References: <8249B703AE8442429AF89B86E8206AA26EEB5F091A@EUSAACMS0703.eamcs.ericsson.se> <4CD2775D.2070602@cisco.com> <8249B703AE8442429AF89B86E8206AA26EEB63ED16@EUSAACMS0703.eamcs.ericsson.se> <4CD330F9.20708@uclouvain.be> In-Reply-To: <4CD330F9.20708@uclouvain.be> 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.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 22:46:45 -0000 Thanks Olivier for the pointer, will take a look of your 2005 paper. -wenhu=20 -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Thursday, November 04, 2010 3:17 PM To: Wenhu Lu Cc: rtgwg@ietf.org Subject: Re: Review request for draft-lu-fast-notification-framework-00.txt Wenhu, >=20 > Thank you very much for the review and comments. >=20 > Let me outline what this draft intends to achieve. > The proposed framework separates the domain-wide total convergence=20 > time into Network delay + local delay. > These two delays are independent and can be improved independently. Do yo= u agree? >=20 > The network delay part can be minimized or even eliminated if some good f= ast notification measure is employed in the transport layer. This is part o= f the goals of this draft. We will discuss this in detail in the upcoming I= ETF meeting when we get chance. > The local delay is also very important. It is an integral part of the ove= rall convergence. We didn't ignore this and mentioned it in section 4.4.=20 > However this should not be a reason to drag the effort in reducing the ne= twork prapagation delay. Do you agree? I'm not sure that reducing the network delay will have an impact on the ove= rall performance. In a 2005 paper, we performed simulations to study the fa= ctors that influence the convergence time of routing protocols in ISP netwo= rks and found that as Mike noted that the propagation delay of the failure = notification did not influence the convergence time significantly. See http://inl.info.ucl.ac.be/publications/achieving-sub-second-igp-convergence= - and look e.g. for the simulation results for the convergence time in a worl= dwide network were all link delays are set to 1 millisecond instead of the = actual propagation delay Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From stephane.litkowski@orange-ftgroup.com Mon Nov 8 00:28:12 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18E53A6892 for ; Mon, 8 Nov 2010 00:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.248 X-Spam-Level: * X-Spam-Status: No, score=1.248 tagged_above=-999 required=5 tests=[AWL=3.497, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIykK4DLjGog for ; Mon, 8 Nov 2010 00:28:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 82BC63A67D4 for ; Mon, 8 Nov 2010 00:28:11 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 400F9C02EE; Mon, 8 Nov 2010 09:28:31 +0100 (CET) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 0DC0B158062; Mon, 8 Nov 2010 09:28:31 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 09:28:30 +0100 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: Review request for draft-lu-fast-notification-framework-00.txt Date: Mon, 8 Nov 2010 09:28:24 +0100 Message-ID: <4289_1289204911_4CD7B4AF_4289_453788_1_4FC3556A36EE3646A09DAA60429F533505649C50@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4CD330F9.20708@uclouvain.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review request for draft-lu-fast-notification-framework-00.txt Thread-Index: Act8biphNNbzxFotTEWsc9dSNwHw/gAh+Wuw References: <8249B703AE8442429AF89B86E8206AA26EEB5F091A@EUSAACMS0703.eamcs.ericsson.se><4CD2775D.2070602@cisco.com><8249B703AE8442429AF89B86E8206AA26EEB63ED16@EUSAACMS0703.eamcs.ericsson.se> <4CD330F9.20708@uclouvain.be> From: To: , "Wenhu Lu" X-OriginalArrivalTime: 08 Nov 2010 08:28:30.0530 (UTC) FILETIME=[EC97AA20:01CB7F1E] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.11.8.20316 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 08:28:12 -0000 Olivier, I agree with your point of view about the network delays. Wenhu, Moreover I think that network wide convergence will never permit to achieve the same level of service (in term of packet loss) than local protection mechanism like LFA, or FRR using MPLS TE. So if you to achieve tens of msec packet loss, LR is needed absolutely. Other point, when you talk about current mechanism of LSP ack mechanism in current IGPs (paragraph 3) that involves control plane and so slow down the network wide convergence, you are right (purely theorically) but this is clearly necessary I think. It would be bad if you start flooding corrupted information network wide ... Some vendors like CISCO already implements some fast-flooding mechanism not in the same way you propose, but that can theorically permit to save some extra computation on nodes. Other point, how are you planning to manage churn of events with your framework ? There is still a need like in most IGP to slowdown event propagation in case of churn. Fastconvergence is good for a single event, but you still need to adapt to churn and slowing down convergence to prevent life of you nodes :) Last point, is that here you deal only with IGP convergence, but on a node which is running multiple routing protocols, an IGP event as directly an effect on other routing protocols (PIM, BGP ...). And we already saw on our network, that concurrence of protocols inside a node is a major issue for fast IGP convergence (BGP slowing down IGP convergence for example due to bad process prioritization) and here we are dependent of vendor implementations. On some router OS, there is a huge work on this with vendors. To conclude from my point of view, I'm not sure there will be a gain in network wide convergence with your proposal. Regards, =20 Stephane Litkowski France Telecom =20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From wenhu.lu@ericsson.com Mon Nov 8 12:02:27 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808B63A688D for ; Mon, 8 Nov 2010 12:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS3fiq8YKmBx for ; Mon, 8 Nov 2010 12:02:26 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 82A213A6888 for ; Mon, 8 Nov 2010 12:02:26 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oA8KPj3t015864 for ; Mon, 8 Nov 2010 14:25:46 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 8 Nov 2010 15:02:40 -0500 From: Wenhu Lu To: "rtgwg@ietf.org" Date: Mon, 8 Nov 2010 15:02:38 -0500 Subject: RE: Review request for draft-lu-fast-notification-framework-00.txt Thread-Topic: Review request for draft-lu-fast-notification-framework-00.txt Thread-Index: Act8biphNNbzxFotTEWsc9dSNwHw/gAh+WuwAJ6JcYA= Message-ID: <8249B703AE8442429AF89B86E8206AA26EEB63FB89@EUSAACMS0703.eamcs.ericsson.se> References: <8249B703AE8442429AF89B86E8206AA26EEB5F091A@EUSAACMS0703.eamcs.ericsson.se><4CD2775D.2070602@cisco.com><8249B703AE8442429AF89B86E8206AA26EEB63ED16@EUSAACMS0703.eamcs.ericsson.se> <4CD330F9.20708@uclouvain.be> <4289_1289204911_4CD7B4AF_4289_453788_1_4FC3556A36EE3646A09DAA60429F533505649C50@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4289_1289204911_4CD7B4AF_4289_453788_1_4FC3556A36EE3646A09DAA60429F533505649C50@PUEXCBL0.nanterre.francetelecom.fr> 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.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 20:02:27 -0000 Hi Stephane, Thanks for your comments. Please see my responses inline started with [luw]. -----Original Message----- From: stephane.litkowski@orange-ftgroup.com [mailto:stephane.litkowski@oran= ge-ftgroup.com]=20 Sent: Monday, November 08, 2010 12:28 AM To: Olivier.Bonaventure@uclouvain.be; Wenhu Lu Cc: rtgwg@ietf.org Subject: RE: Review request for draft-lu-fast-notification-framework-00.txt Olivier, I agree with your point of view about the network delays. Wenhu, Moreover I think that network wide convergence will never permit to achieve= the same level of service (in term of packet loss) than local protection m= echanism like LFA, or FRR using MPLS TE. So if you to achieve tens of msec = packet loss, LR is needed absolutely. [luw] What is the base of this conclusion? Even RFC[5714] itself admits tha= t it cannot guarantee 100% coverage. Other point, when you talk about current mechanism of LSP ack mechanism in = current IGPs (paragraph 3) that involves control plane and so slow down the= network wide convergence, you are right (purely theorically) but this is c= learly necessary I think. It would be bad if you start flooding corrupted i= nformation network wide ... [luw] Were you talking about paragraph 3 under "Introduction"? That paragra= ph simply says "if only others know our situations...". Some vendors like CISCO already implements some fast-flooding mechanism not= in the same way you propose, but that can theorically permit to save some = extra computation on nodes. [luw] I'm not familiar with that. Other point, how are you planning to manage churn of events with your frame= work ? There is still a need like in most IGP to slowdown event propagation= in case of churn. Fastconvergence is good for a single event, but you stil= l need to adapt to churn and slowing down convergence to prevent life of yo= u nodes :) [luw] Quite opposite. The curent IPFRR solutions will incur lot of work on = the affected routers. It takes lots of churns for the network to recover fr= om the events and become ready for the next hit. Last point, is that here you deal only with IGP convergence, but on a node = which is running multiple routing protocols, an IGP event as directly an ef= fect on other routing protocols (PIM, BGP ...). And we already saw on our n= etwork, that concurrence of protocols inside a node is a major issue for fa= st IGP convergence (BGP slowing down IGP convergence for example due to bad= process prioritization) and here we are dependent of vendor implementation= s. On some router OS, there is a huge work on this with vendors. [luw] This is a good problem to have, right? There are two choices: a. Forbid IGP's improvement and make PIM, BGP happy; b. Improve PIM, BGP ... accordingly.=20 The choice is obvious. To conclude from my point of view, I'm not sure there will be a gain in net= work wide convergence with your proposal. [luw] Please note that this draft proposes a fast notification framework wh= ich aims to achieve the seamless link state synchronization. It doesn't exc= lude the improvement in other areas. In fact, it encourages the improvement= /innovation in various areas such as control plane processing, data plane u= pdating, and the communication between them. Please also note that it's not our purpose to cut down the transmission del= ay (i.e. travelling the wire). The transmission delay cannot be cut or shor= tened. It is governed by the law of Physics. It can however be compensated = (see section 5.2). Best Regards, -wenhu Regards, =20 Stephane Litkowski France Telecom =20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From stephane.litkowski@orange-ftgroup.com Mon Nov 8 13:00:02 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2523528C0D6 for ; Mon, 8 Nov 2010 13:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.811 X-Spam-Level: X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[AWL=3.059, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nlMDu6GaeHc for ; Mon, 8 Nov 2010 13:00:00 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 6B33928B23E for ; Mon, 8 Nov 2010 12:59:59 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4501F2AC731 for ; Mon, 8 Nov 2010 22:00:20 +0100 (CET) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 281E4158072 for ; Mon, 8 Nov 2010 22:00:20 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 22:00:18 +0100 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: Review request for draft-lu-fast-notification-framework-00.txt Date: Mon, 8 Nov 2010 22:00:18 +0100 Message-ID: <12060_1289250020_4CD864E4_12060_295596_1_4FC3556A36EE3646A09DAA60429F53350564A1A9@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <8249B703AE8442429AF89B86E8206AA26EEB63FB89@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review request for draft-lu-fast-notification-framework-00.txt Thread-Index: Act8biphNNbzxFotTEWsc9dSNwHw/gAh+WuwAJ6JcYAABSJZ0A== References: <8249B703AE8442429AF89B86E8206AA26EEB5F091A@EUSAACMS0703.eamcs.ericsson.se><4CD2775D.2070602@cisco.com><8249B703AE8442429AF89B86E8206AA26EEB63ED16@EUSAACMS0703.eamcs.ericsson.se><4CD330F9.20708@uclouvain.be><4289_1289204911_4CD7B4AF_4289_453788_1_4FC3556A36EE3646A09DAA60429F533505649C50@PUEXCBL0.nanterre.francetelecom.fr> <8249B703AE8442429AF89B86E8206AA26EEB63FB89@EUSAACMS0703.eamcs.ericsson.se> From: To: X-OriginalArrivalTime: 08 Nov 2010 21:00:18.0966 (UTC) FILETIME=[F350C360:01CB7F87] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.11.8.200614 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 21:00:02 -0000 =20 >>>Moreover I think that network wide convergence will never permit to achieve the same level of service (in term of=20 >>>packet loss) than local protection mechanism like LFA, or FRR using MPLS TE. So if you to achieve tens of msec packet >>>loss, LR is needed absolutely. [luw] What is the base of this conclusion? Even RFC[5714] itself admits that it cannot guarantee 100% coverage. [sli] clearly with LFA you can't have 100% coverage inside a network (except if you build it based on LFA limitations :) ) but there is some solutions that can permit to approach the 100% coverage. But to be more clear about what I said : protection/local repair mechanism have not the same purpose than network wide convergence. And you will never be able to achieve a network wide convergence with the same level of packet loss than the one proposed by protection mechanism like TE or LFA : basically, in protection mechanism, there is no computation involved when the failure occurs (pre computation is done), the FIB/LFIBs are just switching states. So both are complementary, LFA/TE are not there to replace network wide convergence, it's just a temporary mechanism until convergence occurs. >>Other point, when you talk about current mechanism of LSP ack mechanism in current IGPs (paragraph 3) that involves=20 >>control plane and so slow down the network wide convergence, you are right (purely theorically) but this is clearly >>necessary I think. It would be bad if you start flooding corrupted information network wide ... [luw] Were you talking about paragraph 3 under "Introduction"? That paragraph simply says "if only others know our situations...". [sli] Here was the statement I was referencing : "Regular routing protocol performs the flooding in store-and-forward manner. While this is reliable (retransmission) and secure (adjacency check), it involves control plane operation and the control plane to data plane communication. It inevitably drags the network wide convergence" >>Other point, how are you planning to manage churn of events with your framework ? There is still a need like in mostIGP=20 >>to slowdown event propagation in case of churn. Fastconvergence is good for a single event, but you still need to adapt >>to churn and slowing down convergence to prevent life of you nodes :)=20 [luw] Quite opposite. The curent IPFRR solutions will incur lot of work on the affected routers. It takes lots of churns for the network to recover from the events and become ready for the next hit. [sli] can you explain a bit what you mean by "It takes lots of churns for the network to recover from the events and become ready for the next hit." to be sure I'm undertanding correctly. If you mean than protection mechanism are not well designed for churns, you are totally right (I share this opinion) but some other mechanism need to be implemented (IGP backoff, dampening ...) to limit churns.=20 >>Last point, is that here you deal only with IGP convergence, but on a node which is running multiple routing protocols, >>an IGP event as directly an effect on other routing protocols (PIM, BGP ...). And we already saw on our network, that >>concurrence of protocols inside a node is a major issue for fast IGP convergence (BGP slowing down IGP convergence for >>example due to bad process prioritization) and here we are dependent of vendor implementations. On some router OS, >>there is a huge work on this with vendors. [luw] This is a good problem to have, right? There are two choices: a. Forbid IGP's improvement and make PIM, BGP happy; b. Improve PIM, BGP ... accordingly.=20 The choice is obvious. [sli] Yes clearly !! Regards, Stephane ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From wenhu.lu@ericsson.com Mon Nov 8 15:32:30 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F7928C0E8 for ; Mon, 8 Nov 2010 15:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mzx0szaMeKiS for ; Mon, 8 Nov 2010 15:32:27 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 17A5E3A6914 for ; Mon, 8 Nov 2010 15:32:26 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oA8NtmLL015599 for ; Mon, 8 Nov 2010 17:55:49 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 8 Nov 2010 18:32:43 -0500 From: Wenhu Lu To: "rtgwg@ietf.org" Date: Mon, 8 Nov 2010 18:32:41 -0500 Subject: RE: Review request for draft-lu-fast-notification-framework-00.txt Thread-Topic: Review request for draft-lu-fast-notification-framework-00.txt Thread-Index: Act8biphNNbzxFotTEWsc9dSNwHw/gAh+WuwAJ6JcYAABSJZ0AADysCA Message-ID: <8249B703AE8442429AF89B86E8206AA26EEB6A98EF@EUSAACMS0703.eamcs.ericsson.se> References: <8249B703AE8442429AF89B86E8206AA26EEB5F091A@EUSAACMS0703.eamcs.ericsson.se><4CD2775D.2070602@cisco.com><8249B703AE8442429AF89B86E8206AA26EEB63ED16@EUSAACMS0703.eamcs.ericsson.se><4CD330F9.20708@uclouvain.be><4289_1289204911_4CD7B4AF_4289_453788_1_4FC3556A36EE3646A09DAA60429F533505649C50@PUEXCBL0.nanterre.francetelecom.fr> <8249B703AE8442429AF89B86E8206AA26EEB63FB89@EUSAACMS0703.eamcs.ericsson.se> <12060_1289250020_4CD864E4_12060_295596_1_4FC3556A36EE3646A09DAA60429F53350564A1A9@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <12060_1289250020_4CD864E4_12060_295596_1_4FC3556A36EE3646A09DAA60429F53350564A1A9@PUEXCBL0.nanterre.francetelecom.fr> 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.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 23:32:30 -0000 Hi Stephane, Please see my comments inline [luw2].=20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of s= tephane.litkowski@orange-ftgroup.com Sent: Monday, November 08, 2010 1:00 PM To: rtgwg@ietf.org Subject: RE: Review request for draft-lu-fast-notification-framework-00.txt =20 >>>Moreover I think that network wide convergence will never permit to achieve the same level of service (in term of=20 >>>packet loss) than local protection mechanism like LFA, or FRR using MPLS TE. So if you to achieve tens of msec packet >>>loss, LR is needed absolutely. [luw] What is the base of this conclusion? Even RFC[5714] itself admits tha= t it cannot guarantee 100% coverage. [sli] clearly with LFA you can't have 100% coverage inside a network (excep= t if you build it based on LFA limitations :) ) but there is some solutions= that can permit to approach the 100% coverage. But to be more clear about = what I said : protection/local repair mechanism have not the same purpose t= han network wide convergence. And you will never be able to achieve a netwo= rk wide convergence with the same level of packet loss than the one propose= d by protection mechanism like TE or LFA : basically, in protection mechanism, there is no computation involved when t= he failure occurs (pre computation is done), the FIB/LFIBs are just switchi= ng states. So both are complementary, LFA/TE are not there to replace netwo= rk wide convergence, it's just a temporary mechanism until convergence occu= rs. [luw2] Exactly, it's a temporary workaround. As good as IETF, IMHO we shoul= dn't settle on workaround and not seeking excellence. I understand and agre= e with you that by now most other solutions do not switch as crispy as LFA = does. But I dare not say never. >>Other point, when you talk about current mechanism of LSP ack mechanism in current IGPs (paragraph 3) that involves=20 >>control plane and so slow down the network wide convergence, you are right (purely theorically) but this is clearly >>necessary I think. It would be bad if you start flooding corrupted information network wide ... [luw] Were you talking about paragraph 3 under "Introduction"? That paragra= ph simply says "if only others know our situations...". [sli] Here was the statement I was referencing : "Regular routing protocol = performs the flooding in store-and-forward manner. While this is reliable (retransmission) and secure (adjacency check), it involves control plane operation and the control plane to data plane communication. It inevitably drags the netw= ork wide convergence" [luw2] Here the point is to skip the middle-men's store-and-forward. >>Other point, how are you planning to manage churn of events with your framework ? There is still a need like in mostIGP=20 >>to slowdown event propagation in case of churn. Fastconvergence is good for a single event, but you still need to adapt >>to churn and slowing down convergence to prevent life of you nodes :) [luw] Quite opposite. The curent IPFRR solutions will incur lot of work on = the affected routers. It takes lots of churns for the network to recover fr= om the events and become ready for the next hit. [sli] can you explain a bit what you mean by "It takes lots of churns for t= he network to recover from the events and become ready for the next hit." t= o be sure I'm undertanding correctly. If you mean than protection mechanism= are not well designed for churns, you are totally right (I share this opin= ion) but some other mechanism need to be implemented (IGP backoff, dampenin= g ...) to limit churns.=20 [luw2] I was referring: one of current IPFRR solutions requires after the t= opology change, "m" SPFs on multiple routers in the network, where "m" is t= he number of neighbors (can be fewer). Regards, -wenhu >>Last point, is that here you deal only with IGP convergence, but on a node which is running multiple routing protocols, >>an IGP event as directl= y an effect on other routing protocols (PIM, BGP ...). And we already saw o= n our network, that >>concurrence of protocols inside a node is a major iss= ue for fast IGP convergence (BGP slowing down IGP convergence for >>example= due to bad process prioritization) and here we are dependent of vendor imp= lementations. On some router OS, >>there is a huge work on this with vendor= s. [luw] This is a good problem to have, right? There are two choices: a. Forbid IGP's improvement and make PIM, BGP happy; b. Improve PIM, BGP ... accordingly.=20 The choice is obvious. [sli] Yes clearly !! Regards, Stephane ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From albert.tian@ericsson.com Mon Nov 8 22:02:54 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E63E3A69EB for ; Mon, 8 Nov 2010 22:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQLUk60twD2g for ; Mon, 8 Nov 2010 22:02:54 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 3F89E3A69AE for ; Mon, 8 Nov 2010 22:02:54 -0800 (PST) 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 oA96QJMd032018; Tue, 9 Nov 2010 00:26:21 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 9 Nov 2010 01:03:10 -0500 From: Albert Tian To: "stephane.litkowski@orange-ftgroup.com" Date: Tue, 9 Nov 2010 01:03:07 -0500 Subject: FW: Review request for draft-lu-fast-notification-framework-00.txt Thread-Topic: Review request for draft-lu-fast-notification-framework-00.txt Thread-Index: Act/vNW7sas6JLkWQZ+eDZfTifOh6QAABFpA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 06:02:54 -0000 Hi Stephane/Oliver, thanks very much for all your valuable comments. What we are saying essentially are: A) fast convergence is important in its own right. LFA and other LR mechani= sms provide benefits but they can not replace fast convergence, for coverag= e issues, for additional complexity etc. B) there are several aspects in fast convergence: detection time, propergat= ion time, SPF time, RIB/FIB time etc. We need to attack and reduce all of t= hem. The flooding time is one part of the propergation delay, and that is w= hat we are trying to reduce in this draft.=20 C) We do not want to be tied down to a specific fast notification solution = at this stage, and want to be able to change the engine down the road. Alia= has pointed out some race conditions yesterday among many other things and= we really appreciate that. D) we started with fast convergence as an application, but we think in the = future other application may also benefit from a fast notification framewor= k. BTW are you at the IETF Beijing? If so we could meet at the back of routing= -area open meeting (Tue@1700 or end of meeting, which ever is earlier) if y= ou are around. Others are also welcome to join us. Thanks, Albert On Mon, Nov 8, 2010 at 1:00 PM, wr= ote: > >>>>Moreover I think that network wide convergence will never permit to > achieve the same level of service (in term of >>>>packet loss) than local protection mechanism like LFA, or FRR using > MPLS TE. So if you to achieve tens of msec packet >>>>loss, LR is needed absolutely. > [luw] What is the base of this conclusion? Even RFC[5714] itself=20 > admits that it cannot guarantee 100% coverage. > > [sli] clearly with LFA you can't have 100% coverage inside a network=20 > (except if you build it based on LFA limitations :) ) but there is=20 > some solutions that can permit to approach the 100% coverage. But to=20 > be more clear about what I said : protection/local repair mechanism=20 > have not the same purpose than network wide convergence. And you will=20 > never be able to achieve a network wide convergence with the same=20 > level of packet loss than the one proposed by protection mechanism like T= E or LFA : > basically, in protection mechanism, there is no computation involved=20 > when the failure occurs (pre computation is done), the FIB/LFIBs are=20 > just switching states. So both are complementary, LFA/TE are not there=20 > to replace network wide convergence, it's just a temporary mechanism=20 > until convergence occurs. > >>>Other point, when you talk about current mechanism of LSP ack > mechanism in current IGPs (paragraph 3) that involves >>>control plane and so slow down the network wide convergence, you are > right (purely theorically) but this is clearly >>>necessary I think. It would be bad if you start flooding corrupted > information network wide ... > > [luw] Were you talking about paragraph 3 under "Introduction"? That=20 > paragraph simply says "if only others know our situations...". > > [sli] Here was the statement I was referencing : "Regular routing=20 > protocol performs the flooding in store-and-forward > =A0 manner. =A0While this is reliable (retransmission) and secure > =A0 (adjacency check), it involves control plane operation and the > =A0 control plane to data plane communication. =A0It inevitably drags the= =20 > network wide convergence" > >>>Other point, how are you planning to manage churn of events with your > framework ? There is still a need like in mostIGP >>>to slowdown event propagation in case of churn. Fastconvergence is > good for a single event, but you still need to adapt >>>to churn and slowing down convergence to prevent life of you nodes :) > > [luw] Quite opposite. The curent IPFRR solutions will incur lot of=20 > work on the affected routers. It takes lots of churns for the network=20 > to recover from the events and become ready for the next hit. > > [sli] can you explain a bit what you mean by "It takes lots of churns=20 > for the network to recover from the events and become ready for the=20 > next hit." to be sure I'm undertanding correctly. If you mean than=20 > protection mechanism are not well designed for churns, you are totally=20 > right (I share this opinion) but some other mechanism need to be=20 > implemented (IGP backoff, dampening ...) to limit churns. > >>>Last point, is that here you deal only with IGP convergence, but on a > node which is running multiple routing protocols, >>an IGP event as=20 > directly an effect on other routing protocols (PIM, BGP ...). And we=20 > already saw on our network, that >>concurrence of protocols inside a=20 > node is a major issue for fast IGP convergence (BGP slowing down IGP=20 > convergence for >>example due to bad process prioritization) and here=20 > we are dependent of vendor implementations. On some router OS, >>there=20 > is a huge work on this with vendors. > [luw] This is a good problem to have, right? There are two choices: > =A0 =A0 =A0a. Forbid IGP's improvement and make PIM, BGP happy; > =A0 =A0 =A0b. Improve PIM, BGP ... accordingly. > =A0 =A0 =A0 =A0The choice is obvious. > [sli] Yes clearly !! > > > Regards, > > Stephane > > ********************************* > This message and any attachments (the "message") are confidential and int= ended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, chan= ged or falsified. > If you are not the intended addressee of this message, please cancel it i= mmediately and inform the sender. > ******************************** > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From mshand@cisco.com Tue Nov 9 00:53:11 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF52D3A69EC for ; Tue, 9 Nov 2010 00:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5Ta+v5Rbl5x for ; Tue, 9 Nov 2010 00:53:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3080B3A69EE for ; Tue, 9 Nov 2010 00:53:09 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAPaa2EyQ/khLgWdsb2JhbACiHhUBARYiIqFjm2iFSgSKVYMM X-IronPort-AV: E=Sophos;i="4.59,174,1288569600"; d="scan'208";a="68725312" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2010 08:53:32 +0000 Received: from [10.61.88.247] (ams3-vpn-dhcp6392.cisco.com [10.61.88.247]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oA98rWsU002605 for ; Tue, 9 Nov 2010 08:53:32 GMT Message-ID: <4CD90C0B.6020006@cisco.com> Date: Tue, 09 Nov 2010 08:53:31 +0000 From: mike shand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: FW: Review request for draft-lu-fast-notification-framework-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 08:53:11 -0000 Albert On 09/11/2010 06:03, Albert Tian wrote: > Hi Stephane/Oliver, > > thanks very much for all your valuable comments. > > What we are saying essentially are: > > A) fast convergence is important in its own right. LFA and other LR mechanisms provide benefits but they can not replace fast convergence, for coverage issues, for additional complexity etc. I completely agree. Fast convergence is certainly important in its own right. Indeed, fast convergence and FRR are complementary and synergistic. > B) there are several aspects in fast convergence: detection time, propergation time, SPF time, RIB/FIB time etc. We need to attack and reduce all of them. The flooding time is one part of the propergation delay, and that is what we are trying to reduce in this draft. Yes, but as others have shown, it is not the most significant. And the most significant part of the propagation delay is probably the time of flight of the messages anyway. > C) We do not want to be tied down to a specific fast notification solution at this stage, and want to be able to change the engine down the road. Alia has pointed out some race conditions yesterday among many other things and we really appreciate that. Indeed. Fast convergence mechanism have to preserve the correctness properties of the existing convergence mechanisms themselves. It has been mentioned that FRR mechanisms are complex, but the crucial difference is that the complexity does not interfere with the normal convergence process. i.e. the "complex" FRR computations only take place after normal (fast) convergence has taken place, in preparation for protecting the next failure. In the even of topology churn, the normal convergence always takes preference, even to the extent that no FRR computations take place until the topology has stabilised. And they have no effect on the correctness of the normal convergence, which is unchanged. i.e. following a failure event, packets will first be re-routed using the repair paths computed BEFORE the failure, then as convergence takes place they will be routed using the correct new topology information and THEN the FRR computations will prepare for the NEXT failure. > D) we started with fast convergence as an application, but we think in the future other application may also benefit from a fast notification framework. > > BTW are you at the IETF Beijing? If so we could meet at the back of routing-area open meeting (Tue@1700 or end of meeting, which ever is earlier) if you are around. Others are also welcome to join us. Sorry. I'm not in Beijing. Mike > Thanks, > Albert > > > On Mon, Nov 8, 2010 at 1:00 PM, wrote: >>>>> Moreover I think that network wide convergence will never permit to >> achieve the same level of service (in term of >>>>> packet loss) than local protection mechanism like LFA, or FRR using >> MPLS TE. So if you to achieve tens of msec packet >>>>> loss, LR is needed absolutely. >> [luw] What is the base of this conclusion? Even RFC[5714] itself >> admits that it cannot guarantee 100% coverage. >> >> [sli] clearly with LFA you can't have 100% coverage inside a network >> (except if you build it based on LFA limitations :) ) but there is >> some solutions that can permit to approach the 100% coverage. But to >> be more clear about what I said : protection/local repair mechanism >> have not the same purpose than network wide convergence. And you will >> never be able to achieve a network wide convergence with the same >> level of packet loss than the one proposed by protection mechanism like TE or LFA : >> basically, in protection mechanism, there is no computation involved >> when the failure occurs (pre computation is done), the FIB/LFIBs are >> just switching states. So both are complementary, LFA/TE are not there >> to replace network wide convergence, it's just a temporary mechanism >> until convergence occurs. >> >>>> Other point, when you talk about current mechanism of LSP ack >> mechanism in current IGPs (paragraph 3) that involves >>>> control plane and so slow down the network wide convergence, you are >> right (purely theorically) but this is clearly >>>> necessary I think. It would be bad if you start flooding corrupted >> information network wide ... >> >> [luw] Were you talking about paragraph 3 under "Introduction"? That >> paragraph simply says "if only others know our situations...". >> >> [sli] Here was the statement I was referencing : "Regular routing >> protocol performs the flooding in store-and-forward >> manner. While this is reliable (retransmission) and secure >> (adjacency check), it involves control plane operation and the >> control plane to data plane communication. It inevitably drags the >> network wide convergence" >> >>>> Other point, how are you planning to manage churn of events with your >> framework ? There is still a need like in mostIGP >>>> to slowdown event propagation in case of churn. Fastconvergence is >> good for a single event, but you still need to adapt >>>> to churn and slowing down convergence to prevent life of you nodes :) >> [luw] Quite opposite. The curent IPFRR solutions will incur lot of >> work on the affected routers. It takes lots of churns for the network >> to recover from the events and become ready for the next hit. >> >> [sli] can you explain a bit what you mean by "It takes lots of churns >> for the network to recover from the events and become ready for the >> next hit." to be sure I'm undertanding correctly. If you mean than >> protection mechanism are not well designed for churns, you are totally >> right (I share this opinion) but some other mechanism need to be >> implemented (IGP backoff, dampening ...) to limit churns. >> >>>> Last point, is that here you deal only with IGP convergence, but on a >> node which is running multiple routing protocols,>>an IGP event as >> directly an effect on other routing protocols (PIM, BGP ...). And we >> already saw on our network, that>>concurrence of protocols inside a >> node is a major issue for fast IGP convergence (BGP slowing down IGP >> convergence for>>example due to bad process prioritization) and here >> we are dependent of vendor implementations. On some router OS,>>there >> is a huge work on this with vendors. >> [luw] This is a good problem to have, right? There are two choices: >> a. Forbid IGP's improvement and make PIM, BGP happy; >> b. Improve PIM, BGP ... accordingly. >> The choice is obvious. >> [sli] Yes clearly !! >> >> >> Regards, >> >> Stephane >> >> ********************************* >> This message and any attachments (the "message") are confidential and intended solely for the addressees. >> Any unauthorised use or dissemination is prohibited. >> Messages are susceptible to alteration. >> France Telecom Group shall not be liable for the message if altered, changed or falsified. >> If you are not the intended addressee of this message, please cancel it immediately and inform the sender. >> ******************************** >> >> _______________________________________________ >> 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: www.cisco.com/web/about/doing_business/legal/cri From alberttian@gmail.com Tue Nov 9 09:46:37 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490273A6907 for ; Tue, 9 Nov 2010 09:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfA3Tas3ATvj for ; Tue, 9 Nov 2010 09:46:36 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 5AF0D3A6A1E for ; Tue, 9 Nov 2010 09:46:36 -0800 (PST) Received: by pvc21 with SMTP id 21so608699pvc.31 for ; Tue, 09 Nov 2010 09:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=O/H4Bd07CLe9F1xu946E+tdFvOhsxZe4x0U0AxBtMlM=; b=kI6yEYKP8sWF9nmDviL5FQ84cu14BUA+EpqZjRauk2+S6eKmIn5q4GD+Q5Ow/CAV72 ijDK48uESkpDjoUMlPGF6ZbfonMA8R2xdNaYoqkpkeQeW/GxIZxLjO3GQVyg24GTNqqi YhijGbrcolQZ93uHKAqOFVQXKGOWUvux2QJJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=bLzBXUrgtW/02JBfBiv8LRx/XholdaCRTwc6+j3RQm5SnXa9m4DVd0mo9BAm5OCxSf 8dtSpBNBUVl8/y6mZ+h0ScduGJHS8BdFDe81WHQYkUpx7FzGA5L7r4YtooSoS/23W+U1 YBoKZKHeOfJ71aW+3QSNM7fDKURvEKRGUG5EI= MIME-Version: 1.0 Received: by 10.42.165.200 with SMTP id l8mr3535389icy.326.1289324817068; Tue, 09 Nov 2010 09:46:57 -0800 (PST) Sender: alberttian@gmail.com Received: by 10.231.36.139 with HTTP; Tue, 9 Nov 2010 09:46:56 -0800 (PST) In-Reply-To: <4CD90C0B.6020006@cisco.com> References: <4CD90C0B.6020006@cisco.com> Date: Wed, 10 Nov 2010 01:46:56 +0800 X-Google-Sender-Auth: YCF7o33VYsF5cau3U7WUzErNT4o Message-ID: Subject: Re: FW: Review request for draft-lu-fast-notification-framework-00.txt From: Albert Tian To: mike shand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: albert.tian@ericsson.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 17:46:37 -0000 Hi Mike, Thanks very much for your feedback. Some comments inlined below, see [tian]= . >> B) there are several aspects in fast convergence: detection time, >> propergation time, SPF time, RIB/FIB time etc. We need to attack and red= uce >> all of them. The flooding time is one part of the propergation delay, an= d >> that is what we are trying to reduce in this draft. > > Yes, but as others have shown, it is not the most significant. And the mo= st > significant part of the propagation delay is probably the time of flight = of > the messages anyway. [tian] Yes you are right in that some other part, in particular RIB/FIB time, was the most significant. Thanks to the earlier researches that have exposed the problem, people have been focusing on reducing that: reduce the IGP table size, prioritized prefix, proper use of recursive routes, etc. These have all shown to be effective techniques. We have not forgotten these, and will continue to improve along those lines. Also those are mostly implementation issues and can be done outside of IETF. [tian] the propagation delay on the wire is indeed a very interesting topic. Unfortunately we have to report that we were not able to reduce the propagation delay on the wire ;-) However, our conjecture is that the propagation delay on the wire will NOT contribute to packet loss, only to packet re-ordering. In other words, if in a perfect world where each router converges instantaneously upon the reception of the failure notification, and the failure notifications can be propagated without any additional delay, then there would be no packet loss during convergence, regardless how long the wires are (assuming packets can be queued up). We can proof some simple cases. The key fact here is that the wire is also a FIFO buffer. This may also be the reason why the whole micro-loop problem is not as bad as everyone is expecting (otherwise the whole FRR would be completely useless). >> >> C) We do not want to be tied down to a specific fast notification soluti= on >> at this stage, and want to be able to change the engine down the road. A= lia >> has pointed out some race conditions yesterday among many other things a= nd >> we really appreciate that. > > Indeed. Fast convergence mechanism have to preserve the correctness > properties of the existing convergence mechanisms themselves. It has been > mentioned that FRR mechanisms are complex, but the crucial difference is > that the complexity does not interfere with the normal convergence proces= s. > i.e. the "complex" FRR computations only take place after normal (fast) > convergence has taken place, in preparation for protecting the next failu= re. > In the even of topology churn, the normal convergence always takes > preference, even to the extent that no FRR computations take place until = the > topology has stabilised. And they have no effect on the correctness of th= e > normal convergence, which is unchanged. > > i.e. following a failure event, packets will first be re-routed using the > repair paths computed BEFORE the failure, then as convergence takes place > they will be routed using the correct new topology information and THEN = =A0the > FRR computations will prepare for the NEXT failure. [tian] yes you are absolutely right that the correctness must be guaranteed. We are trying to make the fast notification a pure optimization on top of the existing flooding mechanisms such that the correctness is not impacted. The current thinking is that the fast notification will occupy a sequence number on the originator. Then we can use the existing mechanism to deal with all re-ordering issues and race conditions, which are more likely to happen here. The notification can take the form of a normal IGP database update (though does not have to), and can be flooded further following the normal flooding procedure, as if it were received on a regular interface. In other words, the slow flooding will fix everything and guarantee the correctness. >> >> D) we started with fast convergence as an application, but we think in t= he >> future other application may also benefit from a fast notification >> framework. >> >> BTW are you at the IETF Beijing? If so we could meet at the back of >> routing-area open meeting (Tue@1700 or end of meeting, which ever is >> earlier) if you are around. Others are also welcome to join us. > > Sorry. I'm not in Beijing. [tian] too bad, you missed the Peking Ducks :-) Thanks, Albert From akatlas@gmail.com Tue Nov 9 21:16:04 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D713A67F2 for ; Tue, 9 Nov 2010 21:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+E5JRqwZ+Mi for ; Tue, 9 Nov 2010 21:16:03 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id A21B33A67D6 for ; Tue, 9 Nov 2010 21:16:03 -0800 (PST) Received: by qwb7 with SMTP id 7so303744qwb.31 for ; Tue, 09 Nov 2010 21:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=9g8HtjDZSB3d2NAMegut2aJ0C+nd+eZdGYdtj97l6HQ=; b=G0DOFq+Mn5IUtKYa80aISQIJkS9FcVOerCJKbFWDK0t161bKFTCF4VyGZFIUQxCy7F KjjmHmP3Uw2aEa+t1EIQQzDlUO7GKiH385zBIlwSeAGigYVUQ/hLNlbOBaAALjU51I7U C4lOFCmt8TsGUvURm7iw5TIRTI3XZSsRLoUos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AUttwpSyEK8Se0/JrB1Jdvoe6P8je2B6gwZjxIFsHC/xECZOAKQVEh4jgdwJljotNv ihRGwwnz6qHGwszoS+Hb4RIsW7m6O4+W3OnR7IGFMY2jU65FD1l5+HJFddD+Hq+IdbEn x0X5bqn8GwKAUgoMqYQQKr3KZOzr3Dfqfoapk= MIME-Version: 1.0 Received: by 10.229.218.143 with SMTP id hq15mr7307280qcb.34.1289366189428; Tue, 09 Nov 2010 21:16:29 -0800 (PST) Received: by 10.229.231.75 with HTTP; Tue, 9 Nov 2010 21:16:29 -0800 (PST) Date: Wed, 10 Nov 2010 00:16:29 -0500 Message-ID: Subject: interest in composite links work? From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:16:04 -0000 We would like to better understand the interest level in the current composite links work. Do you: From akatlas@gmail.com Tue Nov 9 21:22:49 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34363A67D6 for ; Tue, 9 Nov 2010 21:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjZuIrH4ccN6 for ; Tue, 9 Nov 2010 21:22:48 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 68E383A677C for ; Tue, 9 Nov 2010 21:22:48 -0800 (PST) Received: by qwb7 with SMTP id 7so308131qwb.31 for ; Tue, 09 Nov 2010 21:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=0QgCTJfx4UJ/8arY/fRsjlKHnaeDxATGmEdDYX80/B8=; b=pWF+tTo/XTMLZpuMHLM1H03NHJcUJWjTiEoVZdBkyVTYqQB+jBhdvl9EWmSq9QPYfo vH4hdvUAsaSUVwqZlDnTB2HJ54MXofXdgi54xCL7rqdq5sAmKf4sRlnTg39GPERU7sXW 52Fr54sLjaLvjt+Khchn5WkHnLuTMMVM9ko5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nBKtcQAQXW9D0YW/VXV6Qg8IIbsOtPI43CvhOdPb8HW/1zWf53bKoZTa0PIMXGbcUf kpKCPPVOa98+tazEB24M7qgnmjy7ZWLpf6C8A7+2Q1Y2+WCQ2l2rqmPpRKqQBohsZHv7 dEwfS1f9s8rXJPAywBJ7sf8ak9+Z3ykcJ3hHY= MIME-Version: 1.0 Received: by 10.224.76.81 with SMTP id b17mr6239165qak.146.1289366594332; Tue, 09 Nov 2010 21:23:14 -0800 (PST) Received: by 10.229.231.75 with HTTP; Tue, 9 Nov 2010 21:23:14 -0800 (PST) Date: Wed, 10 Nov 2010 00:23:14 -0500 Message-ID: Subject: retry: interest in composite links From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:22:50 -0000 I would like to better understand the interest and enthusiasm for the composite links work. Do you: a) Agree/disagree that the problem exists and is interesting? b) Look to it to solve existing known issues in your networks (or those of your customers)? c) Plan to actively contribute by doing timely reviewing and commenting on drafts? d) Intend to submit related solutions architecture drafts to meet the requirements? e) I'm just watching - do you have more popcorn? What timeframe do you want to see this work move along in? i) Yesterday would have been good... ii) Can we reach consensus on an implementable solution in the next year? iii) It'll take years - and that's ok. iv) It's supposed to complete sometime? There has been very little discussion on the mailing list. More is the best way of helping progress to occur between meetings. Thanks, Alia P.S. Sorry for the missend. From tony.li@tony.li Tue Nov 9 21:31:05 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF27A3A67D6 for ; Tue, 9 Nov 2010 21:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j727ra7KbBog for ; Tue, 9 Nov 2010 21:31:04 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 814863A63EB for ; Tue, 9 Nov 2010 21:31:04 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id VHBo1f0010mv7h054HXXps; Wed, 10 Nov 2010 05:31:31 +0000 Received: from tky-vpn-client-230-63.cisco.com ([64.104.46.217]) by omta11.westchester.pa.mail.comcast.net with comcast id VHXF1f0044h8y6w3XHXMyp; Wed, 10 Nov 2010 05:31:29 +0000 Subject: Re: retry: interest in composite links Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Wed, 10 Nov 2010 13:31:12 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alia Atlas X-Mailer: Apple Mail (2.1081) Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:31:05 -0000 > a) Agree/disagree that the problem exists and is interesting? Agree. > b) Look to it to solve existing known issues in your networks (or > those of your customers)? Yes. We are coming to an interesting point where our usual economics = for link upgrades no longer apply. Parallelism will reign. Simple link = bundling will NOT suffice in the long term. > c) Plan to actively contribute by doing timely reviewing and > commenting on drafts? Yes. > d) Intend to submit related solutions architecture drafts to meet > the requirements? Some, but I'm hoping not to do everything myself. > e) I'm just watching - do you have more popcorn? I'm in Beijing, so moon cakes or chasu bao, please. ;-) >=20 > What timeframe do you want to see this work move along in? > i) Yesterday would have been good... > ii) Can we reach consensus on an implementable solution in the next = year? > iii) It'll take years - and that's ok. > iv) It's supposed to complete sometime? i) There are numerous implementation changes to be made. Tony From dave.mcdysan@verizon.com Tue Nov 9 22:16:02 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5F83A68C6 for ; Tue, 9 Nov 2010 22:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADh2V0hrShw4 for ; Tue, 9 Nov 2010 22:16:01 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 3CEA23A68C5 for ; Tue, 9 Nov 2010 22:16:01 -0800 (PST) Received: from irvintrmemf3.verizon.com (irvintrmemf3.verizon.com [138.83.34.103]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id oAA6GMqX007460; Wed, 10 Nov 2010 01:16:22 -0500 (EST) X-AuditID: 8a532267-b7b45ae000003f9b-79-4cda38b53e61 Received: from smtptpa4.verizon.com ( [138.83.71.177]) by irvintrmemf3.verizon.com (Symantec Mail Security) with SMTP id 71.C9.16283.5B83ADC4; Wed, 10 Nov 2010 00:16:22 -0600 (CST) Received: from FHDP1LUMXC7HB04.us.one.verizon.com (fhdp1lumxc7hb04.verizon.com [166.68.59.191]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id oAA6GKUm024350; Wed, 10 Nov 2010 01:16:21 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Wed, 10 Nov 2010 01:16:21 -0500 From: "Mcdysan, David E" To: Alia Atlas , "rtgwg@ietf.org" Date: Wed, 10 Nov 2010 01:16:20 -0500 Subject: RE: retry: interest in composite links Thread-Topic: retry: interest in composite links Thread-Index: AcuAl2afQICzT9DSQ42Zkquk0ONsSAABYMku Message-ID: <2464076D83FAED4D985BF2622111AAC40F95CCF872@FHDP1LUMXC7V11.us.one.verizon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 06:16:02 -0000 As a co-author, my response may be biased, but here it is. :) Thanks, Dave ________________________________________ From: rtgwg-bounces@ietf.org [rtgwg-bounces@ietf.org] On Behalf Of Alia Atl= as [akatlas@gmail.com] Sent: Wednesday, November 10, 2010 12:23 AM To: rtgwg@ietf.org Subject: retry: interest in composite links I would like to better understand the interest and enthusiasm for the composite links work. Do you: a) Agree/disagree that the problem exists and is interesting? YES b) Look to it to solve existing known issues in your networks (or those of your customers)? YES c) Plan to actively contribute by doing timely reviewing and commenting on drafts? YES d) Intend to submit related solutions architecture drafts to meet the requirements? YES. Composite link framework. Some solution drafts are already emerging, ones which cite this requirement= s draft are: - http://tools.ietf.org/id/draft-wang-ccamp-latency-te-metric-01.txt -=20 Other drafts are emerging that may meet some of the requirements, and I sug= gest that people interested in this topic take a look at them and comment: - http://tools.ietf.org/id/draft-zhang-ccamp-srlg-fa-configuration-01.txt - http://tools.ietf.org/id/draft-polk-tsvwg-intserv-multiple-tspec-05.txt - http://tools.ietf.org/id/draft-kompella-mpls-entropy-label-01.txt - http://tools.ietf.org/id/draft-kompella-mpls-rsvp-ecmp-00.txt e) I'm just watching - do you have more popcorn? What timeframe do you want to see this work move along in? i) Yesterday would have been good... YES. ii) Can we reach consensus on an implementable solution in the next year? I hope so. iii) It'll take years - and that's ok. Unfortunately, that is increasingly becoming the IETF way. :( iv) It's supposed to complete sometime? There has been very little discussion on the mailing list. More is the best way of helping progress to occur between meetings. Thanks, Alia P.S. Sorry for the missend. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg= From dave.mcdysan@verizon.com Tue Nov 9 22:45:19 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9DD3A68F2 for ; Tue, 9 Nov 2010 22:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSV2aOjUl31K for ; Tue, 9 Nov 2010 22:44:20 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 9F5063A68FA for ; Tue, 9 Nov 2010 22:44:16 -0800 (PST) Received: from irvintrmemf3.verizon.com (irvintrmemf3.verizon.com [138.83.34.103]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id oAA6ifea012739; Wed, 10 Nov 2010 01:44:41 -0500 (EST) X-AuditID: 8a532267-b7b45ae000003f9b-d9-4cda3f59d47b Received: from smtptpa4.verizon.com ( [138.83.71.177]) by irvintrmemf3.verizon.com (Symantec Mail Security) with SMTP id 73.3A.16283.95F3ADC4; Wed, 10 Nov 2010 00:44:41 -0600 (CST) Received: from FHDP1LUMXC7HB03.us.one.verizon.com (fhdp1lumxc7hb03.verizon.com [166.68.59.190]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id oAA6ievw010835; Wed, 10 Nov 2010 01:44:40 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:3bbe::a644:3bbe]) with mapi; Wed, 10 Nov 2010 01:44:40 -0500 From: "Mcdysan, David E" To: "Mcdysan, David E" , Alia Atlas , "rtgwg@ietf.org" Date: Wed, 10 Nov 2010 01:43:54 -0500 Subject: RE: retry: interest in composite links Thread-Topic: retry: interest in composite links Thread-Index: AcuAl2afQICzT9DSQ42Zkquk0ONsSAABYMkuAAFuvIA= Message-ID: <2464076D83FAED4D985BF2622111AAC40F95CCF874@FHDP1LUMXC7V11.us.one.verizon.com> References: , <2464076D83FAED4D985BF2622111AAC40F95CCF872@FHDP1LUMXC7V11.us.one.verizon.com> In-Reply-To: <2464076D83FAED4D985BF2622111AAC40F95CCF872@FHDP1LUMXC7V11.us.one.verizon.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-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 06:45:20 -0000 I forgot to include another draft that is also a potential solution to some= composite link requirements: http://tools.ietf.org/id/draft-yong-pwe3-lfc-fat-pw-01.txt Thanks, Dave ________________________________________ From: Mcdysan, David E Sent: Wednesday, November 10, 2010 1:16 AM To: Alia Atlas; rtgwg@ietf.org Subject: RE: retry: interest in composite links As a co-author, my response may be biased, but here it is. :) Thanks, Dave ________________________________________ From: rtgwg-bounces@ietf.org [rtgwg-bounces@ietf.org] On Behalf Of Alia Atl= as [akatlas@gmail.com] Sent: Wednesday, November 10, 2010 12:23 AM To: rtgwg@ietf.org Subject: retry: interest in composite links I would like to better understand the interest and enthusiasm for the composite links work. Do you: a) Agree/disagree that the problem exists and is interesting? YES b) Look to it to solve existing known issues in your networks (or those of your customers)? YES c) Plan to actively contribute by doing timely reviewing and commenting on drafts? YES d) Intend to submit related solutions architecture drafts to meet the requirements? YES. Composite link framework. Some solution drafts are already emerging, ones which cite this requirement= s draft are: - http://tools.ietf.org/id/draft-wang-ccamp-latency-te-metric-01.txt - Other drafts are emerging that may meet some of the requirements, and I sug= gest that people interested in this topic take a look at them and comment: - http://tools.ietf.org/id/draft-zhang-ccamp-srlg-fa-configuration-01.txt - http://tools.ietf.org/id/draft-polk-tsvwg-intserv-multiple-tspec-05.txt - http://tools.ietf.org/id/draft-kompella-mpls-entropy-label-01.txt - http://tools.ietf.org/id/draft-kompella-mpls-rsvp-ecmp-00.txt e) I'm just watching - do you have more popcorn? What timeframe do you want to see this work move along in? i) Yesterday would have been good... YES. ii) Can we reach consensus on an implementable solution in the next year? I hope so. iii) It'll take years - and that's ok. Unfortunately, that is increasingly becoming the IETF way. :( iv) It's supposed to complete sometime? There has been very little discussion on the mailing list. More is the best way of helping progress to occur between meetings. Thanks, Alia P.S. Sorry for the missend. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg= From cdl@asgaard.org Tue Nov 9 22:42:01 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF303A67D3 for ; Tue, 9 Nov 2010 22:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv9rkaWWExEj for ; Tue, 9 Nov 2010 22:41:54 -0800 (PST) Received: from asgaard.org (ratatosk.asgaard.org [204.29.150.73]) by core3.amsl.com (Postfix) with ESMTP id A8D223A67F7 for ; Tue, 9 Nov 2010 22:41:53 -0800 (PST) Received: from dhcp-6302.meeting.ietf.org (dhcp-6302.meeting.ietf.org [130.129.99.2]) by asgaard.org (Postfix) with ESMTP id 54E529D1150; Wed, 10 Nov 2010 06:42:18 +0000 (UTC) Subject: Re: retry: interest in composite links Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-125--320993506 From: Christopher LILJENSTOLPE In-Reply-To: Date: Wed, 10 Nov 2010 17:42:15 +1100 Message-Id: References: To: Alia Atlas X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Tue, 09 Nov 2010 23:08:16 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 06:42:01 -0000 --Apple-Mail-125--320993506 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 10Nov2010, at 16.23, Alia Atlas wrote: > I would like to better understand the interest and enthusiasm for the > composite links work. >=20 > Do you: > a) Agree/disagree that the problem exists and is interesting? 't > b) Look to it to solve existing known issues in your networks (or > those of your customers)? 't > c) Plan to actively contribute by doing timely reviewing and > commenting on drafts? 't=20 > d) Intend to submit related solutions architecture drafts to meet > the requirements? 't > e) I'm just watching - do you have more popcorn? >=20 > What timeframe do you want to see this work move along in? > i) Yesterday would have been good... > ii) Can we reach consensus on an implementable solution in the next = year? 't > iii) It'll take years - and that's ok. > iv) It's supposed to complete sometime? >=20 >=20 > There has been very little discussion on the mailing list. More is > the best way of helping progress > to occur between meetings. >=20 > Thanks, > Alia >=20 > P.S. Sorry for the missend. > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg >=20 --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc --Apple-Mail-125--320993506 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I = would like to better understand the interest and enthusiasm for = the
composite links work.

Do you:
   a) = Agree/disagree that the problem exists and is = interesting?

't

<= div>
   b) Look to it to = solve existing known issues in your networks (or
those of your = customers)?

't

   c) Plan to actively contribute = by doing timely reviewing and
commenting on = drafts?

't 

   d) Intend to submit related = solutions architecture drafts to meet
the = requirements?

't

   e) I'm just watching - do = you have more popcorn?

What timeframe do you want to see this = work move along in?
  i) Yesterday would have been = good...
 ii) Can we reach consensus on an implementable = solution in the next = year?

't

iii) It'll take years - and that's ok.
iv) It's = supposed to complete sometime?


There has been very little = discussion on the mailing list.  More is
the best way of helping = progress
to occur between = meetings.

Thanks,
Alia

P.S.  Sorry for the = missend.
_______________________________________________
rtgwg = mailing list
rtgwg@ietf.org
https://www.ietf.org/= mailman/listinfo/rtgwg



= --Apple-Mail-125--320993506-- From ning.so@verizonbusiness.com Wed Nov 10 02:07:36 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733DE28C0EF for ; Wed, 10 Nov 2010 02:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TChcnlXheU1g for ; Wed, 10 Nov 2010 02:07:35 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id 0F6983A6807 for ; Wed, 10 Nov 2010 02:07:34 -0800 (PST) Received: from omzismtp01.vzbi.com ([unknown] [165.122.46.164]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LBN0042MYTD8U90@firewall.verizonbusiness.com> for rtgwg@ietf.org; Wed, 10 Nov 2010 10:08:01 +0000 (GMT) Received: from omzismtp01.vzbi.com ([unknown] [127.0.0.1]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LBN00M95YTC0H00@omzismtp01.vzbi.com> for rtgwg@ietf.org; Wed, 10 Nov 2010 10:08:00 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LBN00M1LYTB0O00@omzismtp01.vzbi.com> for rtgwg@ietf.org; Wed, 10 Nov 2010 10:08:00 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.147]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 10:07:59 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CB80BF.262D3F5E" Subject: Re: retry: interest in composite links Date: Wed, 10 Nov 2010 10:07:57 +0000 Message-id: <14584D6EE26B314187A4F68BA20606000485ED70@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: retry: interest in composite links Thread-index: AcuAl2afQICzT9DSQ42Zkquk0ONsSAABYMkuAAFuvIAAByBY4A== From: "So, Ning" To: "McDysan, David E (Dave)" , akatlas@gmail.com, rtgwg@ietf.org X-OriginalArrivalTime: 10 Nov 2010 10:07:59.0288 (UTC) FILETIME=[27135B80:01CB80BF] X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 10:07:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB80BF.262D3F5E Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBhbSB2ZXJ5IG11Y2ggaW4gc3luY2ggd2l0aCBEYXZlJ3MgY29tbWVudHMuICBBcyBhIGNvLWF1 dGhvciwgSSB3b3VsZCBoYXZlIGxpa2UgdG8gc2VlIHRoZSBjYXBhYmlsaXR5IGluIG91ciBuZXR3 b3JrIGxhc3QgeWVhciA6KSANCg0KTmluZyANCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LQ0KRnJvbTogcnRnd2ctYm91bmNlc0BpZXRmLm9yZyA8cnRnd2ctYm91bmNlc0BpZXRmLm9yZz4N ClRvOiBNY0R5c2FuLCBEYXZpZCBFIChEYXZlKTsgQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5j b20+OyBydGd3Z0BpZXRmLm9yZyA8cnRnd2dAaWV0Zi5vcmc+DQpTZW50OiBXZWQgTm92IDEwIDA2 OjQzOjU0IDIwMTANClN1YmplY3Q6IFJFOiByZXRyeTogaW50ZXJlc3QgaW4gY29tcG9zaXRlIGxp bmtzDQoNCkkgZm9yZ290IHRvIGluY2x1ZGUgYW5vdGhlciBkcmFmdCB0aGF0IGlzIGFsc28gYSBw b3RlbnRpYWwgc29sdXRpb24gdG8gc29tZSBjb21wb3NpdGUgbGluayByZXF1aXJlbWVudHM6DQoN Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC15b25nLXB3ZTMtbGZjLWZhdC1wdy0wMS50 eHQNCg0KVGhhbmtzLA0KDQpEYXZlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb206IE1jZHlzYW4sIERhdmlkIEUNClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1i ZXIgMTAsIDIwMTAgMToxNiBBTQ0KVG86IEFsaWEgQXRsYXM7IHJ0Z3dnQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogcmV0cnk6IGludGVyZXN0IGluIGNvbXBvc2l0ZSBsaW5rcw0KDQpBcyBhIGNvLWF1 dGhvciwgbXkgcmVzcG9uc2UgbWF5IGJlIGJpYXNlZCwgYnV0IGhlcmUgaXQgaXMuIDopDQoNClRo YW5rcywNCg0KRGF2ZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpGcm9tOiBydGd3Zy1ib3VuY2VzQGlldGYub3JnIFtydGd3Zy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQWxpYSBBdGxhcyBbYWthdGxhc0BnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDEwLCAyMDEwIDEyOjIzIEFNDQpUbzogcnRnd2dAaWV0Zi5vcmcNClN1Ympl Y3Q6IHJldHJ5OiBpbnRlcmVzdCBpbiBjb21wb3NpdGUgbGlua3MNCg0KSSB3b3VsZCBsaWtlIHRv IGJldHRlciB1bmRlcnN0YW5kIHRoZSBpbnRlcmVzdCBhbmQgZW50aHVzaWFzbSBmb3IgdGhlDQpj b21wb3NpdGUgbGlua3Mgd29yay4NCg0KRG8geW91Og0KICAgIGEpIEFncmVlL2Rpc2FncmVlIHRo YXQgdGhlIHByb2JsZW0gZXhpc3RzIGFuZCBpcyBpbnRlcmVzdGluZz8NCllFUw0KICAgIGIpIExv b2sgdG8gaXQgdG8gc29sdmUgZXhpc3Rpbmcga25vd24gaXNzdWVzIGluIHlvdXIgbmV0d29ya3Mg KG9yDQp0aG9zZSBvZiB5b3VyIGN1c3RvbWVycyk/DQpZRVMNCiAgICBjKSBQbGFuIHRvIGFjdGl2 ZWx5IGNvbnRyaWJ1dGUgYnkgZG9pbmcgdGltZWx5IHJldmlld2luZyBhbmQNCmNvbW1lbnRpbmcg b24gZHJhZnRzPw0KWUVTDQogICAgZCkgSW50ZW5kIHRvIHN1Ym1pdCByZWxhdGVkIHNvbHV0aW9u cyBhcmNoaXRlY3R1cmUgZHJhZnRzIHRvIG1lZXQNCnRoZSByZXF1aXJlbWVudHM/DQpZRVMuIENv bXBvc2l0ZSBsaW5rIGZyYW1ld29yay4NClNvbWUgc29sdXRpb24gZHJhZnRzIGFyZSBhbHJlYWR5 IGVtZXJnaW5nLCBvbmVzIHdoaWNoIGNpdGUgdGhpcyByZXF1aXJlbWVudHMgZHJhZnQgYXJlOg0K LSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FuZy1jY2FtcC1sYXRlbmN5LXRlLW1l dHJpYy0wMS50eHQNCi0NCg0KT3RoZXIgZHJhZnRzIGFyZSBlbWVyZ2luZyB0aGF0IG1heSBtZWV0 IHNvbWUgb2YgdGhlIHJlcXVpcmVtZW50cywgYW5kIEkgc3VnZ2VzdCB0aGF0IHBlb3BsZSBpbnRl cmVzdGVkIGluIHRoaXMgdG9waWMgdGFrZSBhIGxvb2sgYXQgdGhlbSBhbmQgY29tbWVudDoNCi0g aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXpoYW5nLWNjYW1wLXNybGctZmEtY29uZmln dXJhdGlvbi0wMS50eHQNCi0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXBvbGstdHN2 d2ctaW50c2Vydi1tdWx0aXBsZS10c3BlYy0wNS50eHQNCi0gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2lkL2RyYWZ0LWtvbXBlbGxhLW1wbHMtZW50cm9weS1sYWJlbC0wMS50eHQNCi0gaHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LWtvbXBlbGxhLW1wbHMtcnN2cC1lY21wLTAwLnR4dA0KDQog ICAgZSkgSSdtIGp1c3Qgd2F0Y2hpbmcgLSBkbyB5b3UgaGF2ZSBtb3JlIHBvcGNvcm4/DQoNCldo YXQgdGltZWZyYW1lIGRvIHlvdSB3YW50IHRvIHNlZSB0aGlzIHdvcmsgbW92ZSBhbG9uZyBpbj8N CiAgIGkpIFllc3RlcmRheSB3b3VsZCBoYXZlIGJlZW4gZ29vZC4uLg0KWUVTLg0KICBpaSkgQ2Fu IHdlIHJlYWNoIGNvbnNlbnN1cyBvbiBhbiBpbXBsZW1lbnRhYmxlIHNvbHV0aW9uIGluIHRoZSBu ZXh0IHllYXI/DQpJIGhvcGUgc28uDQogaWlpKSBJdCdsbCB0YWtlIHllYXJzIC0gYW5kIHRoYXQn cyBvay4NClVuZm9ydHVuYXRlbHksIHRoYXQgaXMgaW5jcmVhc2luZ2x5IGJlY29taW5nIHRoZSBJ RVRGIHdheS4gOigNCiBpdikgSXQncyBzdXBwb3NlZCB0byBjb21wbGV0ZSBzb21ldGltZT8NCg0K DQpUaGVyZSBoYXMgYmVlbiB2ZXJ5IGxpdHRsZSBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxp c3QuICBNb3JlIGlzDQp0aGUgYmVzdCB3YXkgb2YgaGVscGluZyBwcm9ncmVzcw0KdG8gb2NjdXIg YmV0d2VlbiBtZWV0aW5ncy4NCg0KVGhhbmtzLA0KQWxpYQ0KDQpQLlMuICBTb3JyeSBmb3IgdGhl IG1pc3NlbmQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KcnRnd2cgbWFpbGluZyBsaXN0DQpydGd3Z0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnJ0Z3dnIG1haWxpbmcgbGlzdA0KcnRnd2dAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCg== ------_=_NextPart_001_01CB80BF.262D3F5E Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTUuMTAiPg0KPFRJVExFPlJlOiByZXRyeTog aW50ZXJlc3QgaW4gY29tcG9zaXRlIGxpbmtzPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPCEt LSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT4NCg0KPFA+PEZPTlQgU0laRT0y PkkgYW0gdmVyeSBtdWNoIGluIHN5bmNoIHdpdGggRGF2ZSdzIGNvbW1lbnRzLiZuYnNwOyBBcyBh IGNvLWF1dGhvciwgSSB3b3VsZCBoYXZlIGxpa2UgdG8gc2VlIHRoZSBjYXBhYmlsaXR5IGluIG91 ciBuZXR3b3JrIGxhc3QgeWVhciA6KTxCUj4NCjxCUj4NCk5pbmc8QlI+DQo8QlI+DQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tPEJSPg0KRnJvbTogcnRnd2ctYm91bmNlc0BpZXRmLm9yZyAm bHQ7cnRnd2ctYm91bmNlc0BpZXRmLm9yZyZndDs8QlI+DQpUbzogTWNEeXNhbiwgRGF2aWQgRSAo RGF2ZSk7IEFsaWEgQXRsYXMgJmx0O2FrYXRsYXNAZ21haWwuY29tJmd0OzsgcnRnd2dAaWV0Zi5v cmcgJmx0O3J0Z3dnQGlldGYub3JnJmd0OzxCUj4NClNlbnQ6IFdlZCBOb3YgMTAgMDY6NDM6NTQg MjAxMDxCUj4NClN1YmplY3Q6IFJFOiByZXRyeTogaW50ZXJlc3QgaW4gY29tcG9zaXRlIGxpbmtz PEJSPg0KPEJSPg0KSSBmb3Jnb3QgdG8gaW5jbHVkZSBhbm90aGVyIGRyYWZ0IHRoYXQgaXMgYWxz byBhIHBvdGVudGlhbCBzb2x1dGlvbiB0byBzb21lIGNvbXBvc2l0ZSBsaW5rIHJlcXVpcmVtZW50 czo8QlI+DQo8QlI+DQo8QSBIUkVGPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQteW9u Zy1wd2UzLWxmYy1mYXQtcHctMDEudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt eW9uZy1wd2UzLWxmYy1mYXQtcHctMDEudHh0PC9BPjxCUj4NCjxCUj4NClRoYW5rcyw8QlI+DQo8 QlI+DQpEYXZlPEJSPg0KPEJSPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxCUj4NCkZyb206IE1jZHlzYW4sIERhdmlkIEU8QlI+DQpTZW50OiBXZWRuZXNkYXksIE5v dmVtYmVyIDEwLCAyMDEwIDE6MTYgQU08QlI+DQpUbzogQWxpYSBBdGxhczsgcnRnd2dAaWV0Zi5v cmc8QlI+DQpTdWJqZWN0OiBSRTogcmV0cnk6IGludGVyZXN0IGluIGNvbXBvc2l0ZSBsaW5rczxC Uj4NCjxCUj4NCkFzIGEgY28tYXV0aG9yLCBteSByZXNwb25zZSBtYXkgYmUgYmlhc2VkLCBidXQg aGVyZSBpdCBpcy4gOik8QlI+DQo8QlI+DQpUaGFua3MsPEJSPg0KPEJSPg0KRGF2ZTxCUj4NCjxC Uj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+DQpGcm9tOiBy dGd3Zy1ib3VuY2VzQGlldGYub3JnIFtydGd3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQWxpYSBBdGxhcyBbYWthdGxhc0BnbWFpbC5jb21dPEJSPg0KU2VudDogV2VkbmVzZGF5LCBO b3ZlbWJlciAxMCwgMjAxMCAxMjoyMyBBTTxCUj4NClRvOiBydGd3Z0BpZXRmLm9yZzxCUj4NClN1 YmplY3Q6IHJldHJ5OiBpbnRlcmVzdCBpbiBjb21wb3NpdGUgbGlua3M8QlI+DQo8QlI+DQpJIHdv dWxkIGxpa2UgdG8gYmV0dGVyIHVuZGVyc3RhbmQgdGhlIGludGVyZXN0IGFuZCBlbnRodXNpYXNt IGZvciB0aGU8QlI+DQpjb21wb3NpdGUgbGlua3Mgd29yay48QlI+DQo8QlI+DQpEbyB5b3U6PEJS Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGEpIEFncmVlL2Rpc2FncmVlIHRoYXQgdGhlIHByb2JsZW0g ZXhpc3RzIGFuZCBpcyBpbnRlcmVzdGluZz88QlI+DQpZRVM8QlI+DQombmJzcDsmbmJzcDsmbmJz cDsgYikgTG9vayB0byBpdCB0byBzb2x2ZSBleGlzdGluZyBrbm93biBpc3N1ZXMgaW4geW91ciBu ZXR3b3JrcyAob3I8QlI+DQp0aG9zZSBvZiB5b3VyIGN1c3RvbWVycyk/PEJSPg0KWUVTPEJSPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IGMpIFBsYW4gdG8gYWN0aXZlbHkgY29udHJpYnV0ZSBieSBkb2lu ZyB0aW1lbHkgcmV2aWV3aW5nIGFuZDxCUj4NCmNvbW1lbnRpbmcgb24gZHJhZnRzPzxCUj4NCllF UzxCUj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBkKSBJbnRlbmQgdG8gc3VibWl0IHJlbGF0ZWQgc29s dXRpb25zIGFyY2hpdGVjdHVyZSBkcmFmdHMgdG8gbWVldDxCUj4NCnRoZSByZXF1aXJlbWVudHM/ PEJSPg0KWUVTLiBDb21wb3NpdGUgbGluayBmcmFtZXdvcmsuPEJSPg0KU29tZSBzb2x1dGlvbiBk cmFmdHMgYXJlIGFscmVhZHkgZW1lcmdpbmcsIG9uZXMgd2hpY2ggY2l0ZSB0aGlzIHJlcXVpcmVt ZW50cyBkcmFmdCBhcmU6PEJSPg0KLSA8QSBIUkVGPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQv ZHJhZnQtd2FuZy1jY2FtcC1sYXRlbmN5LXRlLW1ldHJpYy0wMS50eHQiPmh0dHA6Ly90b29scy5p ZXRmLm9yZy9pZC9kcmFmdC13YW5nLWNjYW1wLWxhdGVuY3ktdGUtbWV0cmljLTAxLnR4dDwvQT48 QlI+DQotPEJSPg0KPEJSPg0KT3RoZXIgZHJhZnRzIGFyZSBlbWVyZ2luZyB0aGF0IG1heSBtZWV0 IHNvbWUgb2YgdGhlIHJlcXVpcmVtZW50cywgYW5kIEkgc3VnZ2VzdCB0aGF0IHBlb3BsZSBpbnRl cmVzdGVkIGluIHRoaXMgdG9waWMgdGFrZSBhIGxvb2sgYXQgdGhlbSBhbmQgY29tbWVudDo8QlI+ DQotIDxBIEhSRUY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC16aGFuZy1jY2FtcC1z cmxnLWZhLWNvbmZpZ3VyYXRpb24tMDEudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJh ZnQtemhhbmctY2NhbXAtc3JsZy1mYS1jb25maWd1cmF0aW9uLTAxLnR4dDwvQT48QlI+DQotIDxB IEhSRUY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1wb2xrLXRzdndnLWludHNlcnYt bXVsdGlwbGUtdHNwZWMtMDUudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtcG9s ay10c3Z3Zy1pbnRzZXJ2LW11bHRpcGxlLXRzcGVjLTA1LnR4dDwvQT48QlI+DQotIDxBIEhSRUY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1rb21wZWxsYS1tcGxzLWVudHJvcHktbGFi ZWwtMDEudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQta29tcGVsbGEtbXBscy1l bnRyb3B5LWxhYmVsLTAxLnR4dDwvQT48QlI+DQotIDxBIEhSRUY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1rb21wZWxsYS1tcGxzLXJzdnAtZWNtcC0wMC50eHQiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC1rb21wZWxsYS1tcGxzLXJzdnAtZWNtcC0wMC50eHQ8L0E+PEJS Pg0KPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGUpIEknbSBqdXN0IHdhdGNoaW5nIC0gZG8geW91 IGhhdmUgbW9yZSBwb3Bjb3JuPzxCUj4NCjxCUj4NCldoYXQgdGltZWZyYW1lIGRvIHlvdSB3YW50 IHRvIHNlZSB0aGlzIHdvcmsgbW92ZSBhbG9uZyBpbj88QlI+DQombmJzcDsmbmJzcDsgaSkgWWVz dGVyZGF5IHdvdWxkIGhhdmUgYmVlbiBnb29kLi4uPEJSPg0KWUVTLjxCUj4NCiZuYnNwOyBpaSkg Q2FuIHdlIHJlYWNoIGNvbnNlbnN1cyBvbiBhbiBpbXBsZW1lbnRhYmxlIHNvbHV0aW9uIGluIHRo ZSBuZXh0IHllYXI/PEJSPg0KSSBob3BlIHNvLjxCUj4NCiZuYnNwO2lpaSkgSXQnbGwgdGFrZSB5 ZWFycyAtIGFuZCB0aGF0J3Mgb2suPEJSPg0KVW5mb3J0dW5hdGVseSwgdGhhdCBpcyBpbmNyZWFz aW5nbHkgYmVjb21pbmcgdGhlIElFVEYgd2F5LiA6KDxCUj4NCiZuYnNwO2l2KSBJdCdzIHN1cHBv c2VkIHRvIGNvbXBsZXRlIHNvbWV0aW1lPzxCUj4NCjxCUj4NCjxCUj4NClRoZXJlIGhhcyBiZWVu IHZlcnkgbGl0dGxlIGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdC4mbmJzcDsgTW9yZSBp czxCUj4NCnRoZSBiZXN0IHdheSBvZiBoZWxwaW5nIHByb2dyZXNzPEJSPg0KdG8gb2NjdXIgYmV0 d2VlbiBtZWV0aW5ncy48QlI+DQo8QlI+DQpUaGFua3MsPEJSPg0KQWxpYTxCUj4NCjxCUj4NClAu Uy4mbmJzcDsgU29ycnkgZm9yIHRoZSBtaXNzZW5kLjxCUj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0KcnRnd2cgbWFpbGluZyBsaXN0PEJSPg0K cnRnd2dAaWV0Zi5vcmc8QlI+DQo8QSBIUkVGPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Z3dnIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Z3dnPC9BPjxCUj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPEJSPg0KcnRnd2cgbWFpbGluZyBsaXN0PEJSPg0KcnRnd2dAaWV0Zi5vcmc8QlI+DQo8QSBI UkVGPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnPC9BPjxCUj4NCjwvRk9OVD4NCjwv UD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01CB80BF.262D3F5E-- From lucyyong@huawei.com Wed Nov 10 05:41:19 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5E93A6975 for ; Wed, 10 Nov 2010 05:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cji8wBqIEUmk for ; Wed, 10 Nov 2010 05:41:19 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1A9EB3A6966 for ; Wed, 10 Nov 2010 05:41:19 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBO002RY8PBO6@szxga03-in.huawei.com> for rtgwg@ietf.org; Wed, 10 Nov 2010 21:41:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBO00ANZ8PBYO@szxga03-in.huawei.com> for rtgwg@ietf.org; Wed, 10 Nov 2010 21:41:35 +0800 (CST) Received: from y736742 (3.97.247.60.static.bjtelecom.net [60.247.97.3]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBO00KJV8PB8A@szxml01-in.huawei.com>; Wed, 10 Nov 2010 21:41:35 +0800 (CST) Date: Wed, 10 Nov 2010 07:41:51 -0600 From: Yong Lucy Subject: RE: retry: interest in composite links In-reply-to: To: 'Alia Atlas' , rtgwg@ietf.org Message-id: <015301cb80dd$080ae2d0$34878182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcuAl23Bwg0GutPPSYqUKSZnNwyhoQARJE0Q References: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 13:41:20 -0000 Alia, Thank you for posting these questions. My reply is inline. Lucy > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Alia Atlas > Sent: Tuesday, November 09, 2010 11:23 PM > To: rtgwg@ietf.org > Subject: retry: interest in composite links > > I would like to better understand the interest and enthusiasm for the > composite links work. > > Do you: > a) Agree/disagree that the problem exists and is interesting? [LY] agree. > b) Look to it to solve existing known issues in your networks (or > those of your customers)? > c) Plan to actively contribute by doing timely reviewing and > commenting on drafts? [LY] Yes. > d) Intend to submit related solutions architecture drafts to meet > the requirements? [LY] Co-author for framework draft. > e) I'm just watching - do you have more popcorn? > > What timeframe do you want to see this work move along in? > i) Yesterday would have been good... > ii) Can we reach consensus on an implementable solution in the next year? [LY] Yes, if the group seriously works on it. > iii) It'll take years - and that's ok. > iv) It's supposed to complete sometime? [LY] Lucy > > > There has been very little discussion on the mailing list. More is > the best way of helping progress > to occur between meetings. > > Thanks, > Alia > > P.S. Sorry for the missend. > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From curtis@occnc.com Wed Nov 10 19:30:31 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DBE28C13E for ; Wed, 10 Nov 2010 19:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oKY098TLKmv for ; Wed, 10 Nov 2010 19:30:30 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 6173628C13A for ; Wed, 10 Nov 2010 19:30:29 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id oAB3Uu1l022762; Wed, 10 Nov 2010 22:30:56 -0500 (EST) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: retry: interest in composite links In-reply-to: Your message of "Wed, 10 Nov 2010 00:23:14 EST." Date: Wed, 10 Nov 2010 22:30:56 -0500 Sender: curtis@occnc.com Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 03:30:31 -0000 Alia, Did you want to mention "interest in composite links" as described in draft-ietf-rtgwg-cl-requirement-02? Or was this interest in CL but not necessarily as defined in this draft? I think the former. In message Alia Atlas writes: > > I would like to better understand the interest and enthusiasm for the > composite links work. > > Do you: > a) Agree/disagree that the problem exists and is interesting? Yes. But there are two problems while you state "problem" singular. One is enforcing end-to-end delay bounds and the other is the capacity issue that is driving multipath. The WG problem is that we have mixed the two and not been clear and concise enough in stating either one. We've argued a few fine points to the point that it has lowered the S/N ratio on this list and that may not have helped. > b) Look to it to solve existing known issues in your networks (or > those of your customers)? A customer (singular) has indicated that this is important. > c) Plan to actively contribute by doing timely reviewing and > commenting on drafts? I'm an author and I do plan to continue to contribute. Work has got in the way of IETF activity for me in the last few months. Sorry I didn't make this meeting. > d) Intend to submit related solutions architecture drafts to meet > the requirements? I think that http://datatracker.ietf.org/doc/draft-villamizar-mpls-tp-multipath/ is relevant to one of the two problems in this work, the capacity problem. There have been no comments on that draft in MPLS or MPLS-TP. There is work in CCAMP to support delay as a metric. > e) I'm just watching - do you have more popcorn? A little of that lately. > What timeframe do you want to see this work move along in? > i) Yesterday would have been good... > ii) Can we reach consensus on an implementable solution in the next year? > iii) It'll take years - and that's ok. > iv) It's supposed to complete sometime? draft-villamizar-mpls-tp-multipath reflects considerations in our current work (on next gen product). Not sure what we need to do for the delay bounds but the CSPF mods to support a delay bounds for SLA purpose is not difficult to do. Another part of the WG problem is that a particular solution was at one point being pushed with no clear requirements. We have attempted at least to separate defining the requirements from specifying the solution. The next step is framework and we can try to determine what signaling bits need to do to support a solution, leaving placement of the protocol bits and other such detail to after the framework. > There has been very little discussion on the mailing list. More is > the best way of helping progress > to occur between meetings. > > Thanks, > Alia I agree that there is way too little discussion on the list. So much so that it is not certain that anyone cares about this work outside of the small number of authors. That to me is a bad sign. It hard to judge concensus over this thunderous yawn. Is it really greate and no complaint (I personnaly doubt it) or do the majority of people on this list think it is unimportant enough to ignore it? It is also hard to judge the quality of this document based on so little input from the list (none really since this last one came out). Thanks for asking. Curtis From Adrian.Farrel@huawei.com Wed Nov 10 23:59:30 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8D73A6965; Wed, 10 Nov 2010 23:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaxEL-SoHDUd; Wed, 10 Nov 2010 23:59:29 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 884BF3A67A4; Wed, 10 Nov 2010 23:59:29 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBP00I5HNJYXR@usaga03-in.huawei.com>; Thu, 11 Nov 2010 01:59:58 -0600 (CST) Received: from 950129200 (dhcp-731c.meeting.ietf.org [130.129.115.28]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBP004OPNJVZK@usaga03-in.huawei.com>; Thu, 11 Nov 2010 01:59:58 -0600 (CST) Date: Thu, 11 Nov 2010 07:59:57 +0000 From: Adrian Farrel Subject: China Mobile MPLS-TP Presentation in Routing Area WG To: mpls-tp@ietf.org Message-id: <121301cb8176$70a44950$51ecdbf0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcuBdmemRlYuWN17Q0qbPWDMLbeZaA== Cc: mpls@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 07:59:30 -0000 Hi, The chairs of the Routing Area Working Group have graciously made time for China Mobile to present the slides (posted at http://wiki.tools.ietf.org/misc/mpls-tp/) . These give a view of China Mobile's implementation and deployment considerations for MPLS-TP. The chairs tell me that the agenda slot will be right at the start of the meeting, and will be limited to 10 minutes to make sure that the rest of the agenda is not lost. Thanks, Adrian From jgs@juniper.net Thu Nov 11 00:15:46 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 941D53A69AC for ; Thu, 11 Nov 2010 00:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWDw1vzSCfBn for ; Thu, 11 Nov 2010 00:15:45 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 68F5F3A67A4 for ; Thu, 11 Nov 2010 00:15:34 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTNumQ597DLq+aDzZPoGjix2+aPF19VN7@postini.com; Thu, 11 Nov 2010 00:16:15 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 11 Nov 2010 00:14:19 -0800 From: John Scudder To: "rtgwg@ietf.org" Date: Thu, 11 Nov 2010 00:14:17 -0800 Subject: late changes to rtgwg agenda Thread-Topic: late changes to rtgwg agenda Thread-Index: AcuBeHA3x7hgLdKOTve0L/ynsYDqfQ== Message-ID: <2B77E772-95C8-41FD-8C51-944D6CBF6DAA@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alexey Zinin X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 08:15:46 -0000 Folks, We have several late additions to the rtgwg agenda. The updated agenda is = at http://www.ietf.org/proceedings/79/agenda/rtgwg.html. There will probab= ly be one more update to add remaining slides once we receive them. As Adrian noted earlier, the first item will be "CMCC's considerations for = MPLS-TP", followed by our regular agenda. --John= From akatlas@gmail.com Thu Nov 11 20:42:53 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF873A693E for ; Thu, 11 Nov 2010 20:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syYR4u67ctQT for ; Thu, 11 Nov 2010 20:42:46 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id EA8BC3A68CC for ; Thu, 11 Nov 2010 20:42:45 -0800 (PST) Received: by qyk2 with SMTP id 2so237850qyk.10 for ; Thu, 11 Nov 2010 20:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q4AhjzfWWb5+iOh0BXDEXLPBzEDxuXAhruTouoJBe84=; b=jM7Gm5FnUYmcaWZTyB2cMTP9wX0S9UkwF0e9sCGFg0AAw/UoZ7YMv/B4WFZ26nduJY WUeJBMaZWLgwnR0TU6rskwm728EfxquOE4ZT2YKdxif5f5WnGV0YubTTJ2JBtRx44B2e yQtn0paFsTkKLroZ1myLqkvEYUoo/2PPHUx7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pARdcU3Bhtb7Jj7x5whstaIbQt8QhD4SoTiQfJZ0hscqj6BNOKBTM8VjgG3rSXOwZu IOQmCkis/VpyjRMIxJJnVp2lZ/rTWEWKtNWK2A9rV5GRaTZvF0qHl+xnbLfkrGVAL0Os OQ5WK97dJf4ArIG8K/hrJe3iuvjm4Hnf588l8= MIME-Version: 1.0 Received: by 10.229.213.80 with SMTP id gv16mr1530647qcb.110.1289536997271; Thu, 11 Nov 2010 20:43:17 -0800 (PST) Received: by 10.229.231.75 with HTTP; Thu, 11 Nov 2010 20:43:17 -0800 (PST) In-Reply-To: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> Date: Thu, 11 Nov 2010 23:43:17 -0500 Message-ID: Subject: Re: retry: interest in composite links From: Alia Atlas To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 04:42:53 -0000 Curtis, I agree that we are looking at at least 2 problems whose requirements are mingled. The issue is to get them specified clearly enough to see the appropriate interactions. I've put out this poll to attempt to judge consensus and interest. The silence is noticeable. The drafts that you and Dave have mentioned are relevant - but had not been brought up on the mailing list before. If it is hard to track the activity and where it is happening, we will lose the interest of more people. I would be happy to see, after this IETF, a posting of pointers, the abstract, and perhaps an outstanding issue or point to start conversations. I agree that we're not ready for protocol solution bits - but I do think it is time to discuss various solution frameworks so that they can be compared and contrasted. Thanks :-) Alia On Wed, Nov 10, 2010 at 10:30 PM, Curtis Villamizar wrot= e: > > Alia, > > Did you want to mention "interest in composite links" as described in > draft-ietf-rtgwg-cl-requirement-02? =A0Or was this interest in CL but > not necessarily as defined in this draft? =A0I think the former. > > In message > Alia Atlas writes: >> >> I would like to better understand the interest and enthusiasm for the >> composite links work. >> >> Do you: >> =A0 =A0 a) Agree/disagree that the problem exists and is interesting? > > Yes. =A0But there are two problems while you state "problem" singular. > One is enforcing end-to-end delay bounds and the other is the capacity > issue that is driving multipath. =A0The WG problem is that we have mixed > the two and not been clear and concise enough in stating either one. > We've argued a few fine points to the point that it has lowered the > S/N ratio on this list and that may not have helped. > >> =A0 =A0 b) Look to it to solve existing known issues in your networks (o= r >> those of your customers)? > > A customer (singular) has indicated that this is important. > >> =A0 =A0 c) Plan to actively contribute by doing timely reviewing and >> commenting on drafts? > > I'm an author and I do plan to continue to contribute. =A0Work has got > in the way of IETF activity for me in the last few months. =A0Sorry I > didn't make this meeting. > >> =A0 =A0 d) Intend to submit related solutions architecture drafts to mee= t >> the requirements? > > I think that > http://datatracker.ietf.org/doc/draft-villamizar-mpls-tp-multipath/ is > relevant to one of the two problems in this work, the capacity > problem. =A0There have been no comments on that draft in MPLS or > MPLS-TP. > > There is work in CCAMP to support delay as a metric. > >> =A0 =A0 e) I'm just watching - do you have more popcorn? > > A little of that lately. > >> What timeframe do you want to see this work move along in? >> =A0 =A0i) Yesterday would have been good... >> =A0 ii) Can we reach consensus on an implementable solution in the next = year? >> =A0iii) It'll take years - and that's ok. >> =A0iv) It's supposed to complete sometime? > > draft-villamizar-mpls-tp-multipath reflects considerations in our > current work (on next gen product). =A0Not sure what we need to do for > the delay bounds but the CSPF mods to support a delay bounds for SLA > purpose is not difficult to do. > > Another part of the WG problem is that a particular solution was at > one point being pushed with no clear requirements. =A0We have attempted > at least to separate defining the requirements from specifying the > solution. =A0The next step is framework and we can try to determine what > signaling bits need to do to support a solution, leaving placement of > the protocol bits and other such detail to after the framework. > >> There has been very little discussion on the mailing list. =A0More is >> the best way of helping progress >> to occur between meetings. >> >> Thanks, >> Alia > > I agree that there is way too little discussion on the list. =A0So much > so that it is not certain that anyone cares about this work outside of > the small number of authors. =A0That to me is a bad sign. > > It hard to judge concensus over this thunderous yawn. =A0Is it really > greate and no complaint (I personnaly doubt it) or do the majority of > people on this list think it is unimportant enough to ignore it? > > It is also hard to judge the quality of this document based on so > little input from the list (none really since this last one came out). > > Thanks for asking. > > Curtis > From tochio@jp.fujitsu.com Thu Nov 11 17:38:45 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D10B28C10F; Thu, 11 Nov 2010 17:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9jvKSVYUxRx; Thu, 11 Nov 2010 17:38:44 -0800 (PST) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by core3.amsl.com (Postfix) with ESMTP id E3D2A28C10E; Thu, 11 Nov 2010 17:38:41 -0800 (PST) Received: from m4.gw.fujitsu.co.jp ([10.0.50.74]) by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id oAC1d9DN009962 (envelope-from tochio@jp.fujitsu.com); Fri, 12 Nov 2010 10:39:09 +0900 Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 2F31345DE4D; Fri, 12 Nov 2010 10:39:09 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 0792545DE70; Fri, 12 Nov 2010 10:39:09 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 9BF1F1DB8037; Fri, 12 Nov 2010 10:39:08 +0900 (JST) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 3E3AB1DB803A; Fri, 12 Nov 2010 10:39:08 +0900 (JST) Received: from vs.kawasaki.flab.fujitsu.co.jp (vs.kawasaki.flab.fujitsu.co.jp [10.25.192.38]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/100813-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id oAC1d8B6026556; Fri, 12 Nov 2010 10:39:08 +0900 (JST) X-AuditID: 0a19c026-00000004000001f7-c4-4cdc9abb4a2e Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vs.kawasaki.flab.fujitsu.co.jp (Symantec Mail Security) with ESMTP id D84EA29818; Fri, 12 Nov 2010 10:39:07 +0900 (JST) Received: from [127.0.0.1] (dhcp087-wireless-kawa.meetingroom.flab.fujitsu.co.jp [10.25.200.87]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/100813-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id oAC1d7qT026545; Fri, 12 Nov 2010 10:39:07 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1 Message-ID: <4CDC9AB1.9060401@jp.fujitsu.com> Date: Fri, 12 Nov 2010 10:38:57 +0900 From: Yuji Tochio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Adrian.Farrel@huawei.com Subject: Re: [mpls] China Mobile MPLS-TP Presentation in Routing Area WG References: <121301cb8176$70a44950$51ecdbf0$@huawei.com> In-Reply-To: <121301cb8176$70a44950$51ecdbf0$@huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Sat, 13 Nov 2010 16:48:32 -0800 Cc: mpls@ietf.org, rtgwg@ietf.org, mpls-tp@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 01:38:45 -0000 Hi Adrian, Thanks for letting us know the slides from CMCC and your attempt of giving the chance for this presentation. Although The MPLS meeting closed 5 minutes early yesterday (11:25a), it is disappointing that Han was not allowed to use this time to make his presentation in the WG. It is doubtful that the appropriate audience will be present on Friday afternoon. (Like me..) Regards, Yuji (2010/11/11 16:59), Adrian Farrel wrote: > Hi, > > The chairs of the Routing Area Working Group have graciously made time for > China Mobile to present the slides (posted at > http://wiki.tools.ietf.org/misc/mpls-tp/) . These give a view of China Mobile's > implementation and deployment considerations for MPLS-TP. > > The chairs tell me that the agenda slot will be right at the start of the > meeting, and will be limited to 10 minutes to make sure that the rest of the > agenda is not lost. > > Thanks, > Adrian > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From mshand@cisco.com Tue Nov 16 04:51:09 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095153A6C86 for ; Tue, 16 Nov 2010 04:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmshDDB53Ro8 for ; Tue, 16 Nov 2010 04:51:07 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 47A493A6DBC for ; Tue, 16 Nov 2010 04:51:07 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcFAHwN4kyQ/khNgWdsb2JhbACUX44AFQEBFiIioyCbMIVLBIpYgww X-IronPort-AV: E=Sophos;i="4.59,206,1288569600"; d="scan'208";a="13420175" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 16 Nov 2010 12:51:50 +0000 Received: from [10.61.90.174] (ams3-vpn-dhcp6831.cisco.com [10.61.90.174]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oAGCpofn013247; Tue, 16 Nov 2010 12:51:50 GMT Message-ID: <4CE27E65.5000709@cisco.com> Date: Tue, 16 Nov 2010 12:51:49 +0000 From: mike shand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: albert.tian@ericsson.com Subject: Re: FW: Review request for draft-lu-fast-notification-framework-00.txt References: <4CD90C0B.6020006@cisco.com> In-Reply-To: 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.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 12:51:09 -0000 Albert, I listened to the audio of your presentation in Beijing, and that has prompted some questions. I understand that you propose that the FN service is used as in the 802.1aq proposal as an "accelerator" to the normal flooding process. i.e. the result of the FN process is to temporarily replace older link state information until such time as it is replaced (or otherwise) by the normal operation of the flooding process. The reliability is provided by the normal flooding process. As in the .aq proposal, this seems to meet the requirements of maintaining correctness in the steady state. However, one thing which concerns me is the possibility of some routers receiving the fast notification and some not (which is possible, since it is not a reliable service). The effect of this would be that random routers in the network would receive the change information much earlier than others, and this could lead to the generation of relatively long duration micro-loops. 802.1aq does not suffer from this problem directly, since it employs a (rather complex, as you hinted:-) loop prevention mechanism, whereby synchronization of neighbours databases must be achieved (using digest information) before changes can be made to the FIB. (there are exceptions, in that a certain amount of "wiggle room" is permitted while still retaining the guarantee of no loops.). It must be noted that this freedom from micro-loops is achieved at the expense of dropping packets which might otherwise loop, so throughput is not maintained. But the point I am making, is that in a normal IGP, the possible wide diversity in update arrival times seems to introduce the possibility of exacerbating micro-looping caused by desynchronised databases. I haven't thought too deeply about this, but was wondering if you had done any analysis concerning this property. One further question. From reading the OSPF FN draft, it seems that the arrival of FN information does NOT cause this information to be flooded to neighbors. (in IS-IS terms, SRM is not set). Is that correct? Oh yes, and another. It is suggested that the FN information is flooded down a spanning tree, but this spanning tree was presumably computed prior to the failure, and therefore may require the traversal of the link which has just failed. I don't understand how you guarantee delivery to all routers in this case. In particular the phrase " Each router on the tree can send packets to all other routers on that tree. Even when the topology changes such that the tree breaks, the link-down notification is delivered to all routers." needs some further explanation for me to be able understand it. Mike From sriganeshkini@gmail.com Tue Nov 16 09:07:11 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E5F3A6CE7 for ; Tue, 16 Nov 2010 09:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW+9mMJtmtUL for ; Tue, 16 Nov 2010 09:07:11 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 08C693A68F2 for ; Tue, 16 Nov 2010 09:07:10 -0800 (PST) Received: by pzk10 with SMTP id 10so241908pzk.31 for ; Tue, 16 Nov 2010 09:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=NLNnlsggE1aBOwaJZJFjHlNn9pyuOpdlRode/6jLSDg=; b=b5UlDRz6tue+Wlm8BspONuCyli6mcn7IER9Iyu4J+CNEyC8fCwbyFpi7NirhvLcONj neLmTtkHfLCAXXQEPoFyTnrgZwAt+4J5olbVBK+TAMa1Ett2Srt05mRiU+YQxRSc7dlG keLBMlh0jVB0ZYacw4Es0NIto0+g+kHbwH9bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=sny4IwlwEMwhB7tE4zUZ6AWb4nK8TGEWwm+xkQ1CC8t/uqKfvymXAHaIYjebFGXSkO zTjXb/ztO3A5E1/ODjpLlO5nEZmuAGNDKtESGYMBtOQ8olPw1RNDHN4Qad0ozKqRfLz6 9HgIWRCb2yygx1lg5AJQDgCynxVn04T9Tc0eU= Received: by 10.223.108.147 with SMTP id f19mr6129906fap.68.1289927273683; Tue, 16 Nov 2010 09:07:53 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.223.1.205 with HTTP; Tue, 16 Nov 2010 09:07:23 -0800 (PST) In-Reply-To: <4CE27E65.5000709@cisco.com> References: <4CD90C0B.6020006@cisco.com> <4CE27E65.5000709@cisco.com> From: Sriganesh Kini Date: Tue, 16 Nov 2010 09:07:23 -0800 X-Google-Sender-Auth: VBUI5H_q9Sj6sH3UrzZLZvXHmbg Message-ID: Subject: Re: Review request for draft-lu-fast-notification-framework-00.txt To: mike shand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 17:07:12 -0000 Mike, Spanning tree cannot guarantee that the notification reaches all routers under all failure notifications. I had stated as such in the OSPF WG presentation. There are other techniques to compute redundant trees for reliability. Pls refer to the slides. I did notice that the wording in the draft is inaccurate. We will update it in the next version. Thanks for pointing it out. Also correct about FN not being 'flooded further'. When used without any additional mechanism it can cause loops. It is not needed if the multicast flooding topology is computed accurately. Thanks On Nov 16, 2010, at 4:51 AM, mike shand wrote: > Albert, > > I listened to the audio of your presentation in Beijing, and that has = prompted some questions. > > I understand that you propose that the FN service is used as in the 80= 2.1aq proposal as an "accelerator" to the normal flooding process. i.e. the= result of the FN process is to temporarily replace older link state inform= ation until such time as it is replaced (or otherwise) by the normal operat= ion of the flooding process. The reliability is provided by the normal floo= ding process. > > As in the .aq proposal, this seems to meet the requirements of maintai= ning correctness in the steady state. However, one thing which concerns me = is the possibility of some routers receiving the fast notification and some= not (which is possible, since it is not a reliable service). The effect of= this would be that random routers in the network would receive the change = information much earlier than others, and this could lead to the generation= of relatively long duration micro-loops. > > 802.1aq does not suffer from this problem directly, since it employs a= (rather complex, as you hinted:-) loop prevention mechanism, whereby synch= ronization of neighbours databases must be achieved (using digest informati= on) before changes can be made to the FIB. (there are exceptions, in that a= certain amount of "wiggle room" is permitted while still retaining the gua= rantee of no loops.). It must be noted that this freedom from micro-loops i= s achieved at the expense of dropping packets which might otherwise loop, s= o throughput is not maintained. > > But the point I am making, is that in a normal IGP, the possible wide = diversity in update arrival times seems to introduce the possibility of exa= cerbating micro-looping caused by desynchronised databases. > > I haven't thought too deeply about this, but was wondering if you had = done any analysis concerning this property. > > One further question. From reading the OSPF FN draft, it seems that th= e arrival of FN information does NOT cause this information to be flooded t= o neighbors. (in IS-IS terms, SRM is not set). Is that correct? > > Oh yes, and another. It is suggested that the FN information is floode= d down a spanning tree, but this spanning tree was presumably computed prio= r to the failure, and therefore may require the traversal of the link which= has just failed. I don't understand how you guarantee delivery to all rout= ers in this case. > > In particular the phrase > > " Each router on the tree can send packets to > all other routers on that tree. Even when the topology changes such > that the tree breaks, the link-down notification is delivered to all > routers." > > > needs some further explanation for me to be able understand it. > > > > > Mike > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From ning.so@verizonbusiness.com Tue Nov 16 12:14:31 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE343A6E11 for ; Tue, 16 Nov 2010 12:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4pNiF9tsSV9 for ; Tue, 16 Nov 2010 12:14:31 -0800 (PST) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id CA3FE3A6E13 for ; Tue, 16 Nov 2010 12:14:30 -0800 (PST) Received: from pdcismtp02.vzbi.com ([unknown] [166.40.77.70]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LBZ00CTSUXC8ZA0@firewall.verizonbusiness.com> for rtgwg@ietf.org; Tue, 16 Nov 2010 20:15:13 +0000 (GMT) Received: from pdcismtp02.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LBZ001D1UXC3M00@pdcismtp02.vzbi.com> for rtgwg@ietf.org; Tue, 16 Nov 2010 20:15:12 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([unknown] [153.39.68.166]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LBZ0016AUXC3K00@pdcismtp02.vzbi.com> for rtgwg@ietf.org; Tue, 16 Nov 2010 20:15:12 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.147]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Nov 2010 20:15:12 +0000 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: Question on component link announcement aggregation Date: Tue, 16 Nov 2010 20:15:09 +0000 Message-id: <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Question on component link announcement aggregation Thread-index: AcuCJCeGYebMmlxfSeeTcaH8CbfbmgDpgdyA References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> From: "So, Ning" To: Yong Lucy X-OriginalArrivalTime: 16 Nov 2010 20:15:12.0587 (UTC) FILETIME=[F97E19B0:01CB85CA] Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 20:14:31 -0000 =20 Best regrads, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 Lucy, Tony gave a convincing argument in the meeting on not aggregating the component links in IS-IS. You mentioned that it might not be the case under some other circumstances. Could you please shed some light on that so we can make the decision on the Requirement draft and move it forward? Thanks. Ning From lucyyong@huawei.com Tue Nov 16 12:37:03 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3541A3A6E45 for ; Tue, 16 Nov 2010 12:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB2vweICV5FY for ; Tue, 16 Nov 2010 12:37:02 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 376883A6E43 for ; Tue, 16 Nov 2010 12:37:02 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBZ0047SVYOBT@szxga03-in.huawei.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 04:37:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBZ000Y5VYNR5@szxga03-in.huawei.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 04:37:35 +0800 (CST) Received: from y736742 ([10.124.12.68]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBZ004QMVYL19@szxml06-in.huawei.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 04:37:35 +0800 (CST) Date: Tue, 16 Nov 2010 14:37:55 -0600 From: Yong Lucy Subject: RE: Question on component link announcement aggregation In-reply-to: <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> To: "'So, Ning'" Message-id: <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuCJCeGYebMmlxfSeeTcaH8CbfbmgDpgdyAAAB3WoA= References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 20:37:03 -0000 Link bundle [RFC4201] is used to bundle homogenous component links and advertise them as a single logical link. The motivation of the link bundle is to reduce LSAs, simplify route computation, and make routing protocol scalable. Each component link may have different loads. There is no need to advertise each component link available BW as long as the largest allowed LSP BW is advertised in the link bundle. Without component link announcement aggregation, route announcement and computation may raise scalability concern. Lucy > -----Original Message----- > From: So, Ning [mailto:ning.so@verizonbusiness.com] > Sent: Tuesday, November 16, 2010 2:15 PM > To: Yong Lucy > Cc: rtgwg@ietf.org > Subject: Question on component link announcement aggregation > > > > > Best regrads, > > Ning So > Network Evolution Planning > Verizon, Inc. > (office) 972-729-7905 > (Cell) 972-955-0914 > Lucy, > > Tony gave a convincing argument in the meeting on not aggregating the > component links in IS-IS. You mentioned that it might not be the case > under some other circumstances. Could you please shed some light on > that so we can make the decision on the Requirement draft and move it > forward? Thanks. > > Ning From lucyyong@huawei.com Tue Nov 16 14:55:45 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3452F3A6850 for ; Tue, 16 Nov 2010 14:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXjXGoRBfKBr for ; Tue, 16 Nov 2010 14:55:44 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5BB9D3A6809 for ; Tue, 16 Nov 2010 14:55:44 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC000EJ32DUNW@szxga04-in.huawei.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 06:56:18 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC0001YR2DU45@szxga04-in.huawei.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 06:56:18 +0800 (CST) Received: from y736742 ([10.124.12.68]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC000G8G2DRWE@szxml04-in.huawei.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 06:56:18 +0800 (CST) Date: Tue, 16 Nov 2010 16:56:38 -0600 From: Yong Lucy Subject: RE: Question on component link announcement aggregation In-reply-to: To: 'Yong Lucy' , "'So, Ning'" Message-id: <01f901cb85e1$880f48f0$6701a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuCJCeGYebMmlxfSeeTcaH8CbfbmgDpgdyAAAB3WoAABM6ccA== References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 22:55:45 -0000 Ning, Given an example to show the concern in routing: if there are routers A, B, C, and D, and 20 component links (route adjacencies) between A-B, B-C, and C-D, respectively. Without announcement aggregation, each router has to maintain a large number of link state table, each router will receive SLAs from each component link since LSA is flooded; further more, this will cause much more process in route computing. From A to D, there are 20*20*20 possible paths. Regards, Lucy > -----Original Message----- > From: Yong Lucy [mailto:lucyyong@huawei.com] > Sent: Tuesday, November 16, 2010 2:38 PM > To: 'So, Ning' > Cc: 'rtgwg@ietf.org' > Subject: RE: Question on component link announcement aggregation > > Link bundle [RFC4201] is used to bundle homogenous component links and > advertise them as a single logical link. The motivation of the link bundle > is to reduce LSAs, simplify route computation, and make routing protocol > scalable. Each component link may have different loads. There is no need > to advertise each component link available BW as long as the largest > allowed LSP BW is advertised in the link bundle. > > Without component link announcement aggregation, route announcement and > computation may raise scalability concern. > > Lucy > > > > > -----Original Message----- > > From: So, Ning [mailto:ning.so@verizonbusiness.com] > > Sent: Tuesday, November 16, 2010 2:15 PM > > To: Yong Lucy > > Cc: rtgwg@ietf.org > > Subject: Question on component link announcement aggregation > > > > > > > > > > Best regrads, > > > > Ning So > > Network Evolution Planning > > Verizon, Inc. > > (office) 972-729-7905 > > (Cell) 972-955-0914 > > Lucy, > > > > Tony gave a convincing argument in the meeting on not aggregating the > > component links in IS-IS. You mentioned that it might not be the case > > under some other circumstances. Could you please shed some light on > > that so we can make the decision on the Requirement draft and move it > > forward? Thanks. > > > > Ning From tony.li@tony.li Tue Nov 16 16:47:47 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2063A68BA for ; Tue, 16 Nov 2010 16:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFps6R7HF2kC for ; Tue, 16 Nov 2010 16:47:46 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id A87F73A68AC for ; Tue, 16 Nov 2010 16:47:45 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta10.westchester.pa.mail.comcast.net with comcast id XvKB1f00k1uE5Es5A0oXoQ; Wed, 17 Nov 2010 00:48:31 +0000 Received: from dhcp-tmt-wirelessdata-64-104-53-116.cisco.com ([64.104.53.116]) by omta16.westchester.pa.mail.comcast.net with comcast id Y0oF1f0082WSBRs3c0oKsx; Wed, 17 Nov 2010 00:48:28 +0000 Subject: Re: Question on component link announcement aggregation Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> Date: Wed, 17 Nov 2010 09:42:05 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> To: Yong Lucy X-Mailer: Apple Mail (2.1081) Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 00:47:47 -0000 Hi Lucy, > Link bundle [RFC4201] is used to bundle homogenous component links and > advertise them as a single logical link. The motivation of the link = bundle > is to reduce LSAs, simplify route computation, and make routing = protocol > scalable. Each component link may have different loads. There is no = need to > advertise each component link available BW as long as the largest = allowed > LSP BW is advertised in the link bundle. >=20 > Without component link announcement aggregation, route announcement = and > computation may raise scalability concern. The situation is not analogous because we are intentionally trying to = support bundling of heterogeneous, not homogenous links. Because = component links have different properties (BW, delay, delay variation) = and we will explicitly need to compute paths with multiple requirements = among this vector, we will need detailed information. To again present an extreme example, suppose that we have a composite = link that has a T1 in parallel with a high bandwidth satellite link. = The T1 has a BW of 1.5Mb/s and a delay of 20ms. The satellite link has = a BW of 100Mb/s and a delay of 2s. If we aggregate this, we can only = present one number for BW and one number for delay. No matter which way = we do this, we will end up misrepresenting the situation and end up = making incorrect path computations. For example, if we abstract the = link as (100Mb/s, 20ms) and we need a 10Mb/s path with 20ms delay, we = would incorrectly compute the path. This forces us into crankback. > Given an example to show the concern in routing: > if there are routers A, B, C, and D, and 20 component links (route > adjacencies) between A-B, B-C, and C-D, respectively. Without = announcement > aggregation, each router has to maintain a large number of link state = table, > each router will receive SLAs from each component link since LSA is = flooded; > further more, this will cause much more process in route computing. = =46rom A > to D, there are 20*20*20 possible paths. We can either explore those paths with the router's CPU using local = memory, or we can do so with crankback at signaling time. There are = 8,000 possible paths in those three hops. Path exploration with the CPU = will take 10s of microseconds per path. With crankback and signaling, = it will take 10s of milliseconds per path. =20 Which do you prefer? IMHO, CPU and memory are cheap and well worth it to make good use of = much more expensive physical links. This still scales _reasonably_ = well, because the service provider controls the complexity of the = network and the amount of CPU and memory available. I would _NOT_ = recommend this approach if we were talking about inter-domain routing. Tony From ning.so@verizonbusiness.com Wed Nov 17 06:23:29 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846A83A691A for ; Wed, 17 Nov 2010 06:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY4Avp8sKsdg for ; Wed, 17 Nov 2010 06:23:28 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 0233D3A6903 for ; Wed, 17 Nov 2010 06:23:27 -0800 (PST) Received: from omzismtp03.vzbi.com ([unknown] [165.122.46.170]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LC1008BQ9BYGR30@firewall.verizonbusiness.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 14:23:58 +0000 (GMT) Received: from omzismtp03.vzbi.com ([unknown] [127.0.0.1]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LC10033U9BYOH00@omzismtp03.vzbi.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 14:23:58 +0000 (GMT) Received: from ASHSRV139.mcilink.com ([unknown] [153.39.68.165]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LC1003AI9BYO500@omzismtp03.vzbi.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 14:23:58 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.147]) by ASHSRV139.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Nov 2010 14:23:57 +0000 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: Question on component link announcement aggregation Date: Wed, 17 Nov 2010 14:23:55 +0000 Message-id: <14584D6EE26B314187A4F68BA206060005CC0D11@ASHEVS008.mcilink.com> In-reply-to: <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Question on component link announcement aggregation Thread-index: AcuF8SiY9hhDdov2QW+1FdS5gi6p2QAcEP6w References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> From: "So, Ning" To: Tony Li , Yong Lucy X-OriginalArrivalTime: 17 Nov 2010 14:23:57.0971 (UTC) FILETIME=[1274A630:01CB8663] Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 14:23:29 -0000 Tony and Lucy, I see applications in both of your points. =20 On one hand, what Lucy mentioned is a very practical limitation in the current network. For example, the adjacency limitation on our current MPLS backbone that can use CL capability immediately has adjacency limitation far less than 100 per router, often far less than 50 (I can tell you the specific CISCO numbers in private). It is an existing limitation that has already negatively impacted our network design and traffic engineering capability and efficiency. Advertising large quantity of component links without aggregation will not scale in this case. Please also keep in mind that CPU and memory improvement often requires major hardware upgrade, which all major carrier would prefer not to do if possible. In addition, the capacity growth on the backbone may very well out pace the hardware improvement. On the other hand, what you have stated is also a very valid case in many applications. What I propose is to change the current language in the Requirement and make aggregated announcement optional, so that the carriers can use either based on the actual application in the filed. Would that be acceptable? =20 =20 Best regrads, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 -----Original Message----- From: Tony Li [mailto:tony.li@tony.li]=20 Sent: Tuesday, November 16, 2010 6:42 PM To: Yong Lucy Cc: So, Ning; rtgwg@ietf.org Subject: Re: Question on component link announcement aggregation Hi Lucy, > Link bundle [RFC4201] is used to bundle homogenous component links and > advertise them as a single logical link. The motivation of the link bundle > is to reduce LSAs, simplify route computation, and make routing protocol > scalable. Each component link may have different loads. There is no need to > advertise each component link available BW as long as the largest allowed > LSP BW is advertised in the link bundle. >=20 > Without component link announcement aggregation, route announcement and > computation may raise scalability concern. The situation is not analogous because we are intentionally trying to support bundling of heterogeneous, not homogenous links. Because component links have different properties (BW, delay, delay variation) and we will explicitly need to compute paths with multiple requirements among this vector, we will need detailed information. To again present an extreme example, suppose that we have a composite link that has a T1 in parallel with a high bandwidth satellite link. The T1 has a BW of 1.5Mb/s and a delay of 20ms. The satellite link has a BW of 100Mb/s and a delay of 2s. If we aggregate this, we can only present one number for BW and one number for delay. No matter which way we do this, we will end up misrepresenting the situation and end up making incorrect path computations. For example, if we abstract the link as (100Mb/s, 20ms) and we need a 10Mb/s path with 20ms delay, we would incorrectly compute the path. This forces us into crankback. > Given an example to show the concern in routing: > if there are routers A, B, C, and D, and 20 component links (route > adjacencies) between A-B, B-C, and C-D, respectively. Without announcement > aggregation, each router has to maintain a large number of link state table, > each router will receive SLAs from each component link since LSA is flooded; > further more, this will cause much more process in route computing. >From A > to D, there are 20*20*20 possible paths. We can either explore those paths with the router's CPU using local memory, or we can do so with crankback at signaling time. There are 8,000 possible paths in those three hops. Path exploration with the CPU will take 10s of microseconds per path. With crankback and signaling, it will take 10s of milliseconds per path. =20 Which do you prefer? IMHO, CPU and memory are cheap and well worth it to make good use of much more expensive physical links. This still scales _reasonably_ well, because the service provider controls the complexity of the network and the amount of CPU and memory available. I would _NOT_ recommend this approach if we were talking about inter-domain routing. Tony From jdrake@juniper.net Wed Nov 17 06:35:21 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0563A690A for ; Wed, 17 Nov 2010 06:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8TFSISqf3BW for ; Wed, 17 Nov 2010 06:35:19 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 26AD43A68F6 for ; Wed, 17 Nov 2010 06:35:19 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTOPoQfUBXukGB2s9vfJLwF+T7Xa4/MRx@postini.com; Wed, 17 Nov 2010 06:36:05 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 17 Nov 2010 06:34:10 -0800 From: John E Drake To: "So, Ning" , Tony Li , Yong Lucy Date: Wed, 17 Nov 2010 06:35:15 -0800 Subject: RE: Question on component link announcement aggregation Thread-Topic: Question on component link announcement aggregation Thread-Index: AcuF8SiY9hhDdov2QW+1FdS5gi6p2QAcEP6wAAB/ZNA= Message-ID: <5E893DB832F57341992548CDBB33316398C4A5D114@EMBX01-HQ.jnpr.net> References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> <14584D6EE26B314187A4F68BA206060005CC0D11@ASHEVS008.mcilink.com> In-Reply-To: <14584D6EE26B314187A4F68BA206060005CC0D11@ASHEVS008.mcilink.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 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 14:35:21 -0000 Ning, What I think I am hearing is that aggregation should only be performed when= the aggregated links are nearly homogeneous, which seems pretty sensible f= or the reasons Tony cited. Maybe you should indicate this in the requireme= nts along with the reasons why? Thanks, John=20 Sent from my iPhone > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of So, Ning > Sent: Wednesday, November 17, 2010 6:24 AM > To: Tony Li; Yong Lucy > Cc: rtgwg@ietf.org > Subject: RE: Question on component link announcement aggregation >=20 > Tony and Lucy, >=20 > I see applications in both of your points. >=20 > On one hand, what Lucy mentioned is a very practical limitation in the > current network. For example, the adjacency limitation on our current > MPLS backbone that can use CL capability immediately has adjacency > limitation far less than 100 per router, often far less than 50 (I can > tell you the specific CISCO numbers in private). It is an existing > limitation that has already negatively impacted our network design and > traffic engineering capability and efficiency. Advertising large > quantity of component links without aggregation will not scale in this > case. Please also keep in mind that CPU and memory improvement often > requires major hardware upgrade, which all major carrier would prefer > not to do if possible. In addition, the capacity growth on the > backbone > may very well out pace the hardware improvement. >=20 > On the other hand, what you have stated is also a very valid case in > many applications. >=20 > What I propose is to change the current language in the Requirement and > make aggregated announcement optional, so that the carriers can use > either based on the actual application in the filed. Would that be > acceptable? >=20 >=20 > Best regrads, >=20 > Ning So > Network Evolution Planning > Verizon, Inc. > (office) 972-729-7905 > (Cell) 972-955-0914 >=20 >=20 > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li] > Sent: Tuesday, November 16, 2010 6:42 PM > To: Yong Lucy > Cc: So, Ning; rtgwg@ietf.org > Subject: Re: Question on component link announcement aggregation >=20 >=20 > Hi Lucy, >=20 > > Link bundle [RFC4201] is used to bundle homogenous component links > and > > advertise them as a single logical link. The motivation of the link > bundle > > is to reduce LSAs, simplify route computation, and make routing > protocol > > scalable. Each component link may have different loads. There is no > need to > > advertise each component link available BW as long as the largest > allowed > > LSP BW is advertised in the link bundle. > > > > Without component link announcement aggregation, route announcement > and > > computation may raise scalability concern. >=20 >=20 > The situation is not analogous because we are intentionally trying to > support bundling of heterogeneous, not homogenous links. Because > component links have different properties (BW, delay, delay variation) > and we will explicitly need to compute paths with multiple requirements > among this vector, we will need detailed information. >=20 > To again present an extreme example, suppose that we have a composite > link that has a T1 in parallel with a high bandwidth satellite link. > The T1 has a BW of 1.5Mb/s and a delay of 20ms. The satellite link has > a BW of 100Mb/s and a delay of 2s. If we aggregate this, we can only > present one number for BW and one number for delay. No matter which > way > we do this, we will end up misrepresenting the situation and end up > making incorrect path computations. For example, if we abstract the > link as (100Mb/s, 20ms) and we need a 10Mb/s path with 20ms delay, we > would incorrectly compute the path. This forces us into crankback. >=20 >=20 > > Given an example to show the concern in routing: > > if there are routers A, B, C, and D, and 20 component links (route > > adjacencies) between A-B, B-C, and C-D, respectively. Without > announcement > > aggregation, each router has to maintain a large number of link state > table, > > each router will receive SLAs from each component link since LSA is > flooded; > > further more, this will cause much more process in route computing. > From A > > to D, there are 20*20*20 possible paths. >=20 >=20 > We can either explore those paths with the router's CPU using local > memory, or we can do so with crankback at signaling time. There are > 8,000 possible paths in those three hops. Path exploration with the > CPU > will take 10s of microseconds per path. With crankback and signaling, > it will take 10s of milliseconds per path. >=20 > Which do you prefer? >=20 > IMHO, CPU and memory are cheap and well worth it to make good use of > much more expensive physical links. This still scales _reasonably_ > well, because the service provider controls the complexity of the > network and the amount of CPU and memory available. I would _NOT_ > recommend this approach if we were talking about inter-domain routing. >=20 > Tony >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From ning.so@verizonbusiness.com Wed Nov 17 06:41:09 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2032F3A691A for ; Wed, 17 Nov 2010 06:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VMKESEaMdyR for ; Wed, 17 Nov 2010 06:41:07 -0800 (PST) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id 7A9A33A6903 for ; Wed, 17 Nov 2010 06:41:07 -0800 (PST) Received: from pdcismtp03.vzbi.com ([unknown] [166.40.77.73]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LC1007B1A5S0150@firewall.verizonbusiness.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 14:41:52 +0000 (GMT) Received: from pdcismtp03.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LC100AD2A5SYS00@pdcismtp03.vzbi.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 14:41:52 +0000 (GMT) Received: from ASHSRV139.mcilink.com ([unknown] [153.39.68.165]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LC100AE1A5SOP00@pdcismtp03.vzbi.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 14:41:52 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.147]) by ASHSRV139.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Nov 2010 14:41:52 +0000 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: Question on component link announcement aggregation Date: Wed, 17 Nov 2010 14:41:49 +0000 Message-id: <14584D6EE26B314187A4F68BA206060005CC0D4E@ASHEVS008.mcilink.com> In-reply-to: <5E893DB832F57341992548CDBB33316398C4A5D114@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Question on component link announcement aggregation Thread-index: AcuF8SiY9hhDdov2QW+1FdS5gi6p2QAcEP6wAAB/ZNAAAGDygA== References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> <14584D6EE26B314187A4F68BA206060005CC0D11@ASHEVS008.mcilink.com> <5E893DB832F57341992548CDBB33316398C4A5D114@EMBX01-HQ.jnpr.net> From: "So, Ning" To: John E Drake , Tony Li , Yong Lucy X-OriginalArrivalTime: 17 Nov 2010 14:41:52.0123 (UTC) FILETIME=[92B33CB0:01CB8665] Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 14:41:09 -0000 John and all, I think the aggregation should be performed in at least two major cases: 1. When the aggregated links are nearly homogeneous. Do we need to explain what we mean "nearly" and give it a definitive range? =20 2. When the quantity of component links are very large, and the adjacency (individual component link is adjacency if not aggregated) is a concern. If all agree to this, I can certainly update the doc accordingly. =20 =20 Best regrads, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Wednesday, November 17, 2010 8:35 AM To: So, Ning; Tony Li; Yong Lucy Cc: rtgwg@ietf.org Subject: RE: Question on component link announcement aggregation Ning, What I think I am hearing is that aggregation should only be performed when the aggregated links are nearly homogeneous, which seems pretty sensible for the reasons Tony cited. Maybe you should indicate this in the requirements along with the reasons why? Thanks, John=20 Sent from my iPhone > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of So, Ning > Sent: Wednesday, November 17, 2010 6:24 AM > To: Tony Li; Yong Lucy > Cc: rtgwg@ietf.org > Subject: RE: Question on component link announcement aggregation >=20 > Tony and Lucy, >=20 > I see applications in both of your points. >=20 > On one hand, what Lucy mentioned is a very practical limitation in the > current network. For example, the adjacency limitation on our current > MPLS backbone that can use CL capability immediately has adjacency > limitation far less than 100 per router, often far less than 50 (I can > tell you the specific CISCO numbers in private). It is an existing > limitation that has already negatively impacted our network design and > traffic engineering capability and efficiency. Advertising large > quantity of component links without aggregation will not scale in this > case. Please also keep in mind that CPU and memory improvement often > requires major hardware upgrade, which all major carrier would prefer > not to do if possible. In addition, the capacity growth on the > backbone > may very well out pace the hardware improvement. >=20 > On the other hand, what you have stated is also a very valid case in > many applications. >=20 > What I propose is to change the current language in the Requirement and > make aggregated announcement optional, so that the carriers can use > either based on the actual application in the filed. Would that be > acceptable? >=20 >=20 > Best regrads, >=20 > Ning So > Network Evolution Planning > Verizon, Inc. > (office) 972-729-7905 > (Cell) 972-955-0914 >=20 >=20 > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li] > Sent: Tuesday, November 16, 2010 6:42 PM > To: Yong Lucy > Cc: So, Ning; rtgwg@ietf.org > Subject: Re: Question on component link announcement aggregation >=20 >=20 > Hi Lucy, >=20 > > Link bundle [RFC4201] is used to bundle homogenous component links > and > > advertise them as a single logical link. The motivation of the link > bundle > > is to reduce LSAs, simplify route computation, and make routing > protocol > > scalable. Each component link may have different loads. There is no > need to > > advertise each component link available BW as long as the largest > allowed > > LSP BW is advertised in the link bundle. > > > > Without component link announcement aggregation, route announcement > and > > computation may raise scalability concern. >=20 >=20 > The situation is not analogous because we are intentionally trying to > support bundling of heterogeneous, not homogenous links. Because > component links have different properties (BW, delay, delay variation) > and we will explicitly need to compute paths with multiple requirements > among this vector, we will need detailed information. >=20 > To again present an extreme example, suppose that we have a composite > link that has a T1 in parallel with a high bandwidth satellite link. > The T1 has a BW of 1.5Mb/s and a delay of 20ms. The satellite link has > a BW of 100Mb/s and a delay of 2s. If we aggregate this, we can only > present one number for BW and one number for delay. No matter which > way > we do this, we will end up misrepresenting the situation and end up > making incorrect path computations. For example, if we abstract the > link as (100Mb/s, 20ms) and we need a 10Mb/s path with 20ms delay, we > would incorrectly compute the path. This forces us into crankback. >=20 >=20 > > Given an example to show the concern in routing: > > if there are routers A, B, C, and D, and 20 component links (route > > adjacencies) between A-B, B-C, and C-D, respectively. Without > announcement > > aggregation, each router has to maintain a large number of link state > table, > > each router will receive SLAs from each component link since LSA is > flooded; > > further more, this will cause much more process in route computing. > From A > > to D, there are 20*20*20 possible paths. >=20 >=20 > We can either explore those paths with the router's CPU using local > memory, or we can do so with crankback at signaling time. There are > 8,000 possible paths in those three hops. Path exploration with the > CPU > will take 10s of microseconds per path. With crankback and signaling, > it will take 10s of milliseconds per path. >=20 > Which do you prefer? >=20 > IMHO, CPU and memory are cheap and well worth it to make good use of > much more expensive physical links. This still scales _reasonably_ > well, because the service provider controls the complexity of the > network and the amount of CPU and memory available. I would _NOT_ > recommend this approach if we were talking about inter-domain routing. >=20 > Tony >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From lucyyong@huawei.com Wed Nov 17 08:08:15 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FDF3A6914 for ; Wed, 17 Nov 2010 08:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2goL7SFobhV for ; Wed, 17 Nov 2010 08:08:15 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id EC9533A6904 for ; Wed, 17 Nov 2010 08:08:14 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC100CN6E6QJI@szxga04-in.huawei.com> for rtgwg@ietf.org; Thu, 18 Nov 2010 00:08:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC1005D0E6QQL@szxga04-in.huawei.com> for rtgwg@ietf.org; Thu, 18 Nov 2010 00:08:50 +0800 (CST) Received: from y736742 ([10.124.12.68]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC100HONE6N5D@szxml04-in.huawei.com> for rtgwg@ietf.org; Thu, 18 Nov 2010 00:08:50 +0800 (CST) Date: Wed, 17 Nov 2010 10:08:47 -0600 From: Yong Lucy Subject: RE: Question on component link announcement aggregation In-reply-to: <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> To: 'Tony Li' Message-id: <00a301cb8671$b8d1e160$440c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuF8TfNGsOTnfL7QL+zYkuVSO4I0QAeskeA References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 16:08:16 -0000 Hi Tony, > > The situation is not analogous because we are intentionally trying to > support bundling of heterogeneous, not homogenous links. Because > component links have different properties (BW, delay, delay variation) and > we will explicitly need to compute paths with multiple requirements among > this vector, we will need detailed information. [LY] When bundling heterogeneous links, available BW in each component link may be different. > > To again present an extreme example, suppose that we have a composite link > that has a T1 in parallel with a high bandwidth satellite link. The T1 > has a BW of 1.5Mb/s and a delay of 20ms. The satellite link has a BW of > 100Mb/s and a delay of 2s. If we aggregate this, we can only present one > number for BW and one number for delay. No matter which way we do this, > we will end up misrepresenting the situation and end up making incorrect > path computations. For example, if we abstract the link as (100Mb/s, 20ms) > and we need a 10Mb/s path with 20ms delay, we would incorrectly compute > the path. This forces us into crankback. [LY] This is an engineering issue. When it makes sense to use composite link and when is not, operator can decide. As the example you give, IMHO, it does not make sense to configure a composite link under this situation. Here we just develop technical solution to support composite link. Maybe good to give some useful cases in using composite link in the network. > > > > Given an example to show the concern in routing: > > if there are routers A, B, C, and D, and 20 component links (route > > adjacencies) between A-B, B-C, and C-D, respectively. Without > announcement > > aggregation, each router has to maintain a large number of link state > table, > > each router will receive SLAs from each component link since LSA is > flooded; > > further more, this will cause much more process in route computing. From > A > > to D, there are 20*20*20 possible paths. > > > We can either explore those paths with the router's CPU using local memory, > or we can do so with crankback at signaling time. There are 8,000 > possible paths in those three hops. Path exploration with the CPU will > take 10s of microseconds per path. With crankback and signaling, it will > take 10s of milliseconds per path. [LY] We can investigate crankback condition and minimize the condition. Do you think if we can introduce a "temporary" suspending state for composite link? i.e. when component link fails, composite link can send a temporary suspending state in IGP, in which routers in PSN do not consider composite link in route computing for a short time. Regards, Lucy > > Which do you prefer? > > IMHO, CPU and memory are cheap and well worth it to make good use of much > more expensive physical links. This still scales _reasonably_ well, > because the service provider controls the complexity of the network and > the amount of CPU and memory available. I would _NOT_ recommend this > approach if we were talking about inter-domain routing. > > Tony From jdrake@juniper.net Wed Nov 17 08:16:08 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7763A690E for ; Wed, 17 Nov 2010 08:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfLKB76fn5Ej for ; Wed, 17 Nov 2010 08:16:07 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id D9B563A6904 for ; Wed, 17 Nov 2010 08:16:06 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTOP/8byyIJTTvwfiwRr/iyYGKBdyWgsc@postini.com; Wed, 17 Nov 2010 08:16:53 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 17 Nov 2010 08:15:52 -0800 From: John E Drake To: "So, Ning" , Tony Li , Yong Lucy Date: Wed, 17 Nov 2010 08:16:57 -0800 Subject: RE: Question on component link announcement aggregation Thread-Topic: Question on component link announcement aggregation Thread-Index: AcuF8SiY9hhDdov2QW+1FdS5gi6p2QAcEP6wAAB/ZNAAAGDygAADeZ1A Message-ID: <5E893DB832F57341992548CDBB33316398C4A5D235@EMBX01-HQ.jnpr.net> References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> <14584D6EE26B314187A4F68BA206060005CC0D11@ASHEVS008.mcilink.com> <5E893DB832F57341992548CDBB33316398C4A5D114@EMBX01-HQ.jnpr.net> <14584D6EE26B314187A4F68BA206060005CC0D4E@ASHEVS008.mcilink.com> In-Reply-To: <14584D6EE26B314187A4F68BA206060005CC0D4E@ASHEVS008.mcilink.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 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 16:16:08 -0000 Fine with me. Sent from my iPhone > -----Original Message----- > From: So, Ning [mailto:ning.so@verizonbusiness.com] > Sent: Wednesday, November 17, 2010 6:42 AM > To: John E Drake; Tony Li; Yong Lucy > Cc: rtgwg@ietf.org > Subject: RE: Question on component link announcement aggregation >=20 > John and all, >=20 > I think the aggregation should be performed in at least two major > cases: >=20 > 1. When the aggregated links are nearly homogeneous. Do we need to > explain what we mean "nearly" and give it a definitive range? >=20 > 2. When the quantity of component links are very large, and the > adjacency (individual component link is adjacency if not aggregated) is > a concern. >=20 > If all agree to this, I can certainly update the doc accordingly. >=20 >=20 > Best regrads, >=20 > Ning So > Network Evolution Planning > Verizon, Inc. > (office) 972-729-7905 > (Cell) 972-955-0914 >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Wednesday, November 17, 2010 8:35 AM > To: So, Ning; Tony Li; Yong Lucy > Cc: rtgwg@ietf.org > Subject: RE: Question on component link announcement aggregation >=20 > Ning, >=20 > What I think I am hearing is that aggregation should only be performed > when the aggregated links are nearly homogeneous, which seems pretty > sensible for the reasons Tony cited. Maybe you should indicate this in > the requirements along with the reasons why? >=20 > Thanks, >=20 > John >=20 > Sent from my iPhone >=20 > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > Behalf > > Of So, Ning > > Sent: Wednesday, November 17, 2010 6:24 AM > > To: Tony Li; Yong Lucy > > Cc: rtgwg@ietf.org > > Subject: RE: Question on component link announcement aggregation > > > > Tony and Lucy, > > > > I see applications in both of your points. > > > > On one hand, what Lucy mentioned is a very practical limitation in > the > > current network. For example, the adjacency limitation on our > current > > MPLS backbone that can use CL capability immediately has adjacency > > limitation far less than 100 per router, often far less than 50 (I > can > > tell you the specific CISCO numbers in private). It is an existing > > limitation that has already negatively impacted our network design > and > > traffic engineering capability and efficiency. Advertising large > > quantity of component links without aggregation will not scale in > this > > case. Please also keep in mind that CPU and memory improvement often > > requires major hardware upgrade, which all major carrier would prefer > > not to do if possible. In addition, the capacity growth on the > > backbone > > may very well out pace the hardware improvement. > > > > On the other hand, what you have stated is also a very valid case in > > many applications. > > > > What I propose is to change the current language in the Requirement > and > > make aggregated announcement optional, so that the carriers can use > > either based on the actual application in the filed. Would that be > > acceptable? > > > > > > Best regrads, > > > > Ning So > > Network Evolution Planning > > Verizon, Inc. > > (office) 972-729-7905 > > (Cell) 972-955-0914 > > > > > > -----Original Message----- > > From: Tony Li [mailto:tony.li@tony.li] > > Sent: Tuesday, November 16, 2010 6:42 PM > > To: Yong Lucy > > Cc: So, Ning; rtgwg@ietf.org > > Subject: Re: Question on component link announcement aggregation > > > > > > Hi Lucy, > > > > > Link bundle [RFC4201] is used to bundle homogenous component links > > and > > > advertise them as a single logical link. The motivation of the link > > bundle > > > is to reduce LSAs, simplify route computation, and make routing > > protocol > > > scalable. Each component link may have different loads. There is no > > need to > > > advertise each component link available BW as long as the largest > > allowed > > > LSP BW is advertised in the link bundle. > > > > > > Without component link announcement aggregation, route announcement > > and > > > computation may raise scalability concern. > > > > > > The situation is not analogous because we are intentionally trying to > > support bundling of heterogeneous, not homogenous links. Because > > component links have different properties (BW, delay, delay > variation) > > and we will explicitly need to compute paths with multiple > requirements > > among this vector, we will need detailed information. > > > > To again present an extreme example, suppose that we have a composite > > link that has a T1 in parallel with a high bandwidth satellite link. > > The T1 has a BW of 1.5Mb/s and a delay of 20ms. The satellite link > has > > a BW of 100Mb/s and a delay of 2s. If we aggregate this, we can only > > present one number for BW and one number for delay. No matter which > > way > > we do this, we will end up misrepresenting the situation and end up > > making incorrect path computations. For example, if we abstract the > > link as (100Mb/s, 20ms) and we need a 10Mb/s path with 20ms delay, we > > would incorrectly compute the path. This forces us into crankback. > > > > > > > Given an example to show the concern in routing: > > > if there are routers A, B, C, and D, and 20 component links (route > > > adjacencies) between A-B, B-C, and C-D, respectively. Without > > announcement > > > aggregation, each router has to maintain a large number of link > state > > table, > > > each router will receive SLAs from each component link since LSA is > > flooded; > > > further more, this will cause much more process in route computing. > > From A > > > to D, there are 20*20*20 possible paths. > > > > > > We can either explore those paths with the router's CPU using local > > memory, or we can do so with crankback at signaling time. There are > > 8,000 possible paths in those three hops. Path exploration with the > > CPU > > will take 10s of microseconds per path. With crankback and > signaling, > > it will take 10s of milliseconds per path. > > > > Which do you prefer? > > > > IMHO, CPU and memory are cheap and well worth it to make good use of > > much more expensive physical links. This still scales _reasonably_ > > well, because the service provider controls the complexity of the > > network and the amount of CPU and memory available. I would _NOT_ > > recommend this approach if we were talking about inter-domain > routing. > > > > Tony > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg From lucyyong@huawei.com Wed Nov 17 08:34:11 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3EF3A692E for ; Wed, 17 Nov 2010 08:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm20RQxh62Tw for ; Wed, 17 Nov 2010 08:34:11 -0800 (PST) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9E6F73A692A for ; Wed, 17 Nov 2010 08:34:10 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC100DUZFDYZO@szxga05-in.huawei.com> for rtgwg@ietf.org; Thu, 18 Nov 2010 00:34:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC1004W5FDXKK@szxga05-in.huawei.com> for rtgwg@ietf.org; Thu, 18 Nov 2010 00:34:45 +0800 (CST) Received: from y736742 ([10.124.12.68]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC10073JFDUDD@szxml06-in.huawei.com> for rtgwg@ietf.org; Thu, 18 Nov 2010 00:34:45 +0800 (CST) Date: Wed, 17 Nov 2010 10:34:41 -0600 From: Yong Lucy Subject: RE: Question on component link announcement aggregation In-reply-to: <14584D6EE26B314187A4F68BA206060005CC0D4E@ASHEVS008.mcilink.com> To: "'So, Ning'" , 'John E Drake' , 'Tony Li' Message-id: <00a701cb8675$576e8eb0$440c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuF8SiY9hhDdov2QW+1FdS5gi6p2QAcEP6wAAB/ZNAAAGDygAAD/Nlg References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> <14584D6EE26B314187A4F68BA206060005CC0D11@ASHEVS008.mcilink.com> <5E893DB832F57341992548CDBB33316398C4A5D114@EMBX01-HQ.jnpr.net> <14584D6EE26B314187A4F68BA206060005CC0D4E@ASHEVS008.mcilink.com> Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 16:34:12 -0000 If we allow the component links with different capacities but the similar delay and delay various to be bundled together, will this simplify the problem? Lucy > -----Original Message----- > From: So, Ning [mailto:ning.so@verizonbusiness.com] > Sent: Wednesday, November 17, 2010 8:42 AM > To: John E Drake; Tony Li; Yong Lucy > Cc: rtgwg@ietf.org > Subject: RE: Question on component link announcement aggregation > > John and all, > > I think the aggregation should be performed in at least two major cases: > > 1. When the aggregated links are nearly homogeneous. Do we need to > explain what we mean "nearly" and give it a definitive range? > > 2. When the quantity of component links are very large, and the > adjacency (individual component link is adjacency if not aggregated) is > a concern. > > If all agree to this, I can certainly update the doc accordingly. > > > Best regrads, > > Ning So > Network Evolution Planning > Verizon, Inc. > (office) 972-729-7905 > (Cell) 972-955-0914 > > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Wednesday, November 17, 2010 8:35 AM > To: So, Ning; Tony Li; Yong Lucy > Cc: rtgwg@ietf.org > Subject: RE: Question on component link announcement aggregation > > Ning, > > What I think I am hearing is that aggregation should only be performed > when the aggregated links are nearly homogeneous, which seems pretty > sensible for the reasons Tony cited. Maybe you should indicate this in > the requirements along with the reasons why? > > Thanks, > > John > > Sent from my iPhone > > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > > Of So, Ning > > Sent: Wednesday, November 17, 2010 6:24 AM > > To: Tony Li; Yong Lucy > > Cc: rtgwg@ietf.org > > Subject: RE: Question on component link announcement aggregation > > > > Tony and Lucy, > > > > I see applications in both of your points. > > > > On one hand, what Lucy mentioned is a very practical limitation in the > > current network. For example, the adjacency limitation on our current > > MPLS backbone that can use CL capability immediately has adjacency > > limitation far less than 100 per router, often far less than 50 (I can > > tell you the specific CISCO numbers in private). It is an existing > > limitation that has already negatively impacted our network design and > > traffic engineering capability and efficiency. Advertising large > > quantity of component links without aggregation will not scale in this > > case. Please also keep in mind that CPU and memory improvement often > > requires major hardware upgrade, which all major carrier would prefer > > not to do if possible. In addition, the capacity growth on the > > backbone > > may very well out pace the hardware improvement. > > > > On the other hand, what you have stated is also a very valid case in > > many applications. > > > > What I propose is to change the current language in the Requirement > and > > make aggregated announcement optional, so that the carriers can use > > either based on the actual application in the filed. Would that be > > acceptable? > > > > > > Best regrads, > > > > Ning So > > Network Evolution Planning > > Verizon, Inc. > > (office) 972-729-7905 > > (Cell) 972-955-0914 > > > > > > -----Original Message----- > > From: Tony Li [mailto:tony.li@tony.li] > > Sent: Tuesday, November 16, 2010 6:42 PM > > To: Yong Lucy > > Cc: So, Ning; rtgwg@ietf.org > > Subject: Re: Question on component link announcement aggregation > > > > > > Hi Lucy, > > > > > Link bundle [RFC4201] is used to bundle homogenous component links > > and > > > advertise them as a single logical link. The motivation of the link > > bundle > > > is to reduce LSAs, simplify route computation, and make routing > > protocol > > > scalable. Each component link may have different loads. There is no > > need to > > > advertise each component link available BW as long as the largest > > allowed > > > LSP BW is advertised in the link bundle. > > > > > > Without component link announcement aggregation, route announcement > > and > > > computation may raise scalability concern. > > > > > > The situation is not analogous because we are intentionally trying to > > support bundling of heterogeneous, not homogenous links. Because > > component links have different properties (BW, delay, delay variation) > > and we will explicitly need to compute paths with multiple > requirements > > among this vector, we will need detailed information. > > > > To again present an extreme example, suppose that we have a composite > > link that has a T1 in parallel with a high bandwidth satellite link. > > The T1 has a BW of 1.5Mb/s and a delay of 20ms. The satellite link > has > > a BW of 100Mb/s and a delay of 2s. If we aggregate this, we can only > > present one number for BW and one number for delay. No matter which > > way > > we do this, we will end up misrepresenting the situation and end up > > making incorrect path computations. For example, if we abstract the > > link as (100Mb/s, 20ms) and we need a 10Mb/s path with 20ms delay, we > > would incorrectly compute the path. This forces us into crankback. > > > > > > > Given an example to show the concern in routing: > > > if there are routers A, B, C, and D, and 20 component links (route > > > adjacencies) between A-B, B-C, and C-D, respectively. Without > > announcement > > > aggregation, each router has to maintain a large number of link > state > > table, > > > each router will receive SLAs from each component link since LSA is > > flooded; > > > further more, this will cause much more process in route computing. > > From A > > > to D, there are 20*20*20 possible paths. > > > > > > We can either explore those paths with the router's CPU using local > > memory, or we can do so with crankback at signaling time. There are > > 8,000 possible paths in those three hops. Path exploration with the > > CPU > > will take 10s of microseconds per path. With crankback and signaling, > > it will take 10s of milliseconds per path. > > > > Which do you prefer? > > > > IMHO, CPU and memory are cheap and well worth it to make good use of > > much more expensive physical links. This still scales _reasonably_ > > well, because the service provider controls the complexity of the > > network and the amount of CPU and memory available. I would _NOT_ > > recommend this approach if we were talking about inter-domain routing. > > > > Tony > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg From ning.so@verizonbusiness.com Wed Nov 17 08:49:59 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B72A3A693A for ; Wed, 17 Nov 2010 08:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG-lRnAe60UZ for ; Wed, 17 Nov 2010 08:49:57 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id AABD03A6939 for ; Wed, 17 Nov 2010 08:49:57 -0800 (PST) Received: from omzismtp03.vzbi.com ([unknown] [165.122.46.170]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LC100DE8G4ILW80@firewall.verizonbusiness.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 16:50:43 +0000 (GMT) Received: from omzismtp03.vzbi.com ([unknown] [127.0.0.1]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LC1006BCG4ICG00@omzismtp03.vzbi.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 16:50:42 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LC10067DG4IC300@omzismtp03.vzbi.com> for rtgwg@ietf.org; Wed, 17 Nov 2010 16:50:42 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.147]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Nov 2010 16:50:42 +0000 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: Question on component link announcement aggregation Date: Wed, 17 Nov 2010 16:50:40 +0000 Message-id: <14584D6EE26B314187A4F68BA206060005CC0F40@ASHEVS008.mcilink.com> In-reply-to: <00a701cb8675$576e8eb0$440c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Question on component link announcement aggregation Thread-index: AcuF8SiY9hhDdov2QW+1FdS5gi6p2QAcEP6wAAB/ZNAAAGDygAAD/NlgAACZ8mA= References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> <14584D6EE26B314187A4F68BA206060005CC0D11@ASHEVS008.mcilink.com> <5E893DB832F57341992548CDBB33316398C4A5D114@EMBX01-HQ.jnpr.net> <14584D6EE26B314187A4F68BA206060005CC0D4E@ASHEVS008.mcilink.com> <00a701cb8675$576e8eb0$440c7c0a@china.huawei.com> From: "So, Ning" To: Yong Lucy , John E Drake , Tony Li X-OriginalArrivalTime: 17 Nov 2010 16:50:42.0309 (UTC) FILETIME=[92400350:01CB8677] Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 16:49:59 -0000 Lucy, The question is to aggregate or not. If both cases are allowed, then how to aggregate is up to individual solution, in my humble opinion. =20 Best regrads, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 -----Original Message----- From: Yong Lucy [mailto:lucyyong@huawei.com]=20 Sent: Wednesday, November 17, 2010 10:35 AM To: So, Ning; 'John E Drake'; 'Tony Li' Cc: rtgwg@ietf.org Subject: RE: Question on component link announcement aggregation If we allow the component links with different capacities but the similar delay and delay various to be bundled together, will this simplify the problem?=20 Lucy=20 > -----Original Message----- > From: So, Ning [mailto:ning.so@verizonbusiness.com] > Sent: Wednesday, November 17, 2010 8:42 AM > To: John E Drake; Tony Li; Yong Lucy > Cc: rtgwg@ietf.org > Subject: RE: Question on component link announcement aggregation >=20 > John and all, >=20 > I think the aggregation should be performed in at least two major cases: >=20 > 1. When the aggregated links are nearly homogeneous. Do we need to > explain what we mean "nearly" and give it a definitive range? >=20 > 2. When the quantity of component links are very large, and the > adjacency (individual component link is adjacency if not aggregated) is > a concern. >=20 > If all agree to this, I can certainly update the doc accordingly. >=20 >=20 > Best regrads, >=20 > Ning So > Network Evolution Planning > Verizon, Inc. > (office) 972-729-7905 > (Cell) 972-955-0914 >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Wednesday, November 17, 2010 8:35 AM > To: So, Ning; Tony Li; Yong Lucy > Cc: rtgwg@ietf.org > Subject: RE: Question on component link announcement aggregation >=20 > Ning, >=20 > What I think I am hearing is that aggregation should only be performed > when the aggregated links are nearly homogeneous, which seems pretty > sensible for the reasons Tony cited. Maybe you should indicate this in > the requirements along with the reasons why? >=20 > Thanks, >=20 > John >=20 > Sent from my iPhone >=20 > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > > Of So, Ning > > Sent: Wednesday, November 17, 2010 6:24 AM > > To: Tony Li; Yong Lucy > > Cc: rtgwg@ietf.org > > Subject: RE: Question on component link announcement aggregation > > > > Tony and Lucy, > > > > I see applications in both of your points. > > > > On one hand, what Lucy mentioned is a very practical limitation in the > > current network. For example, the adjacency limitation on our current > > MPLS backbone that can use CL capability immediately has adjacency > > limitation far less than 100 per router, often far less than 50 (I can > > tell you the specific CISCO numbers in private). It is an existing > > limitation that has already negatively impacted our network design and > > traffic engineering capability and efficiency. Advertising large > > quantity of component links without aggregation will not scale in this > > case. Please also keep in mind that CPU and memory improvement often > > requires major hardware upgrade, which all major carrier would prefer > > not to do if possible. In addition, the capacity growth on the > > backbone > > may very well out pace the hardware improvement. > > > > On the other hand, what you have stated is also a very valid case in > > many applications. > > > > What I propose is to change the current language in the Requirement > and > > make aggregated announcement optional, so that the carriers can use > > either based on the actual application in the filed. Would that be > > acceptable? > > > > > > Best regrads, > > > > Ning So > > Network Evolution Planning > > Verizon, Inc. > > (office) 972-729-7905 > > (Cell) 972-955-0914 > > > > > > -----Original Message----- > > From: Tony Li [mailto:tony.li@tony.li] > > Sent: Tuesday, November 16, 2010 6:42 PM > > To: Yong Lucy > > Cc: So, Ning; rtgwg@ietf.org > > Subject: Re: Question on component link announcement aggregation > > > > > > Hi Lucy, > > > > > Link bundle [RFC4201] is used to bundle homogenous component links > > and > > > advertise them as a single logical link. The motivation of the link > > bundle > > > is to reduce LSAs, simplify route computation, and make routing > > protocol > > > scalable. Each component link may have different loads. There is no > > need to > > > advertise each component link available BW as long as the largest > > allowed > > > LSP BW is advertised in the link bundle. > > > > > > Without component link announcement aggregation, route announcement > > and > > > computation may raise scalability concern. > > > > > > The situation is not analogous because we are intentionally trying to > > support bundling of heterogeneous, not homogenous links. Because > > component links have different properties (BW, delay, delay variation) > > and we will explicitly need to compute paths with multiple > requirements > > among this vector, we will need detailed information. > > > > To again present an extreme example, suppose that we have a composite > > link that has a T1 in parallel with a high bandwidth satellite link. > > The T1 has a BW of 1.5Mb/s and a delay of 20ms. The satellite link > has > > a BW of 100Mb/s and a delay of 2s. If we aggregate this, we can only > > present one number for BW and one number for delay. No matter which > > way > > we do this, we will end up misrepresenting the situation and end up > > making incorrect path computations. For example, if we abstract the > > link as (100Mb/s, 20ms) and we need a 10Mb/s path with 20ms delay, we > > would incorrectly compute the path. This forces us into crankback. > > > > > > > Given an example to show the concern in routing: > > > if there are routers A, B, C, and D, and 20 component links (route > > > adjacencies) between A-B, B-C, and C-D, respectively. Without > > announcement > > > aggregation, each router has to maintain a large number of link > state > > table, > > > each router will receive SLAs from each component link since LSA is > > flooded; > > > further more, this will cause much more process in route computing. > > From A > > > to D, there are 20*20*20 possible paths. > > > > > > We can either explore those paths with the router's CPU using local > > memory, or we can do so with crankback at signaling time. There are > > 8,000 possible paths in those three hops. Path exploration with the > > CPU > > will take 10s of microseconds per path. With crankback and signaling, > > it will take 10s of milliseconds per path. > > > > Which do you prefer? > > > > IMHO, CPU and memory are cheap and well worth it to make good use of > > much more expensive physical links. This still scales _reasonably_ > > well, because the service provider controls the complexity of the > > network and the amount of CPU and memory available. I would _NOT_ > > recommend this approach if we were talking about inter-domain routing. > > > > Tony > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg From tony.li@tony.li Wed Nov 17 14:13:32 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1183A69A6 for ; Wed, 17 Nov 2010 14:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBIAelkwhvuf for ; Wed, 17 Nov 2010 14:13:31 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 400BC3A69A5 for ; Wed, 17 Nov 2010 14:13:31 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id YCze1f0031wpRvQ54NEJoJ; Wed, 17 Nov 2010 22:14:18 +0000 Received: from [10.21.75.118] ([128.107.239.233]) by omta18.westchester.pa.mail.comcast.net with comcast id YNE01f00N52qHCY3eNE4Hp; Wed, 17 Nov 2010 22:14:16 +0000 Subject: Re: Question on component link announcement aggregation Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <14584D6EE26B314187A4F68BA206060005CC0D4E@ASHEVS008.mcilink.com> Date: Thu, 18 Nov 2010 07:13:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <98346E24-4058-4301-8409-ABF9B6720E54@tony.li> References: <201011110330.oAB3Uu1l022762@harbor.orleans.occnc.com> <14584D6EE26B314187A4F68BA206060005C3D99E@ASHEVS008.mcilink.com> <01ca01cb85ce$276cf3c0$6701a8c0@china.huawei.com> <74834B1C-81CC-4027-9CB4-76316EF108F0@tony.li> <14584D6EE26B314187A4F68BA206060005CC0D11@ASHEVS008.mcilink.com> <5E893DB832F57341992548CDBB33316398C4A5D114@EMBX01-HQ.jnpr.net> <14584D6EE26B314187A4F68BA206060005CC0D4E@ASHEVS008.mcilink.com> To: "So, Ning" X-Mailer: Apple Mail (2.1081) Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 22:13:32 -0000 Ning, That's fine by me. The requirements can be whatever you want them to = be. My preferences are that we are crystal clear and as precise as = possible about them. Requirements constrain the solution. We should be = careful to avoid writing requirements that have unintended implications. Tony On Nov 17, 2010, at 11:41 PM, So, Ning wrote: > John and all, >=20 > I think the aggregation should be performed in at least two major = cases: >=20 > 1. When the aggregated links are nearly homogeneous. Do we need to > explain what we mean "nearly" and give it a definitive range? =20 >=20 > 2. When the quantity of component links are very large, and the > adjacency (individual component link is adjacency if not aggregated) = is > a concern. >=20 > If all agree to this, I can certainly update the doc accordingly. =20 >=20 >=20 > Best regrads, >=20 > Ning So > Network Evolution Planning > Verizon, Inc. > (office) 972-729-7905 > (Cell) 972-955-0914 >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net]=20 > Sent: Wednesday, November 17, 2010 8:35 AM > To: So, Ning; Tony Li; Yong Lucy > Cc: rtgwg@ietf.org > Subject: RE: Question on component link announcement aggregation >=20 > Ning, >=20 > What I think I am hearing is that aggregation should only be performed > when the aggregated links are nearly homogeneous, which seems pretty > sensible for the reasons Tony cited. Maybe you should indicate this = in > the requirements along with the reasons why? >=20 > Thanks, >=20 > John=20 >=20 > Sent from my iPhone >=20 >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On = Behalf >> Of So, Ning >> Sent: Wednesday, November 17, 2010 6:24 AM >> To: Tony Li; Yong Lucy >> Cc: rtgwg@ietf.org >> Subject: RE: Question on component link announcement aggregation >>=20 >> Tony and Lucy, >>=20 >> I see applications in both of your points. >>=20 >> On one hand, what Lucy mentioned is a very practical limitation in = the >> current network. For example, the adjacency limitation on our = current >> MPLS backbone that can use CL capability immediately has adjacency >> limitation far less than 100 per router, often far less than 50 (I = can >> tell you the specific CISCO numbers in private). It is an existing >> limitation that has already negatively impacted our network design = and >> traffic engineering capability and efficiency. Advertising large >> quantity of component links without aggregation will not scale in = this >> case. Please also keep in mind that CPU and memory improvement often >> requires major hardware upgrade, which all major carrier would prefer >> not to do if possible. In addition, the capacity growth on the >> backbone >> may very well out pace the hardware improvement. >>=20 >> On the other hand, what you have stated is also a very valid case in >> many applications. >>=20 >> What I propose is to change the current language in the Requirement > and >> make aggregated announcement optional, so that the carriers can use >> either based on the actual application in the filed. Would that be >> acceptable? >>=20 >>=20 >> Best regrads, >>=20 >> Ning So >> Network Evolution Planning >> Verizon, Inc. >> (office) 972-729-7905 >> (Cell) 972-955-0914 >>=20 >>=20 >> -----Original Message----- >> From: Tony Li [mailto:tony.li@tony.li] >> Sent: Tuesday, November 16, 2010 6:42 PM >> To: Yong Lucy >> Cc: So, Ning; rtgwg@ietf.org >> Subject: Re: Question on component link announcement aggregation >>=20 >>=20 >> Hi Lucy, >>=20 >>> Link bundle [RFC4201] is used to bundle homogenous component links >> and >>> advertise them as a single logical link. The motivation of the link >> bundle >>> is to reduce LSAs, simplify route computation, and make routing >> protocol >>> scalable. Each component link may have different loads. There is no >> need to >>> advertise each component link available BW as long as the largest >> allowed >>> LSP BW is advertised in the link bundle. >>>=20 >>> Without component link announcement aggregation, route announcement >> and >>> computation may raise scalability concern. >>=20 >>=20 >> The situation is not analogous because we are intentionally trying to >> support bundling of heterogeneous, not homogenous links. Because >> component links have different properties (BW, delay, delay = variation) >> and we will explicitly need to compute paths with multiple > requirements >> among this vector, we will need detailed information. >>=20 >> To again present an extreme example, suppose that we have a composite >> link that has a T1 in parallel with a high bandwidth satellite link. >> The T1 has a BW of 1.5Mb/s and a delay of 20ms. The satellite link > has >> a BW of 100Mb/s and a delay of 2s. If we aggregate this, we can only >> present one number for BW and one number for delay. No matter which >> way >> we do this, we will end up misrepresenting the situation and end up >> making incorrect path computations. For example, if we abstract the >> link as (100Mb/s, 20ms) and we need a 10Mb/s path with 20ms delay, we >> would incorrectly compute the path. This forces us into crankback. >>=20 >>=20 >>> Given an example to show the concern in routing: >>> if there are routers A, B, C, and D, and 20 component links (route >>> adjacencies) between A-B, B-C, and C-D, respectively. Without >> announcement >>> aggregation, each router has to maintain a large number of link > state >> table, >>> each router will receive SLAs from each component link since LSA is >> flooded; >>> further more, this will cause much more process in route computing. >> =46rom A >>> to D, there are 20*20*20 possible paths. >>=20 >>=20 >> We can either explore those paths with the router's CPU using local >> memory, or we can do so with crankback at signaling time. There are >> 8,000 possible paths in those three hops. Path exploration with the >> CPU >> will take 10s of microseconds per path. With crankback and = signaling, >> it will take 10s of milliseconds per path. >>=20 >> Which do you prefer? >>=20 >> IMHO, CPU and memory are cheap and well worth it to make good use of >> much more expensive physical links. This still scales _reasonably_ >> well, because the service provider controls the complexity of the >> network and the amount of CPU and memory available. I would _NOT_ >> recommend this approach if we were talking about inter-domain = routing. >>=20 >> Tony >>=20 >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg From alberttian@gmail.com Wed Nov 17 21:18:16 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4294B3A6784 for ; Wed, 17 Nov 2010 21:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKm5c5M4Z-uG for ; Wed, 17 Nov 2010 21:18:15 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C16DC3A677E for ; Wed, 17 Nov 2010 21:18:14 -0800 (PST) Received: by iwn40 with SMTP id 40so3155601iwn.31 for ; Wed, 17 Nov 2010 21:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=gwxHWoyJQ9CjI3o/kWXUINMQ96tCdq4m6tlWXdHEj/0=; b=DntkwIq14jmbGw7Jt+wIIg8YaWwL3XoELpv9usfFDedoH1R+ehrQ6+eCfDQejRCIOO AjUeZU3asLhgTtbIxqKxcguETPpJKDKdO/Ip2f55QZUWoss+b5ebHcpSUbAy0B3wDQiE V2Kv7SIMlzvBnAdiQ455N78CmdmWCi2fsNtBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=lqw8bVQlubqXL68Cl7kNG640Bnv9rERb02VjO6N37/KH3lArmvolCFn2Emt7hh7JXW c0Cc2KpGU+Nt2lbHB3POzBTTnoqCIym+XZ2clH7ve1hNMFDSftzd0tOEswXZ9w0yqc+L 77Kw3+gbVScK6LM0nYcHPH4X0fx1tTOGuu7Ec= MIME-Version: 1.0 Received: by 10.231.12.73 with SMTP id w9mr165750ibw.95.1290057539889; Wed, 17 Nov 2010 21:18:59 -0800 (PST) Sender: alberttian@gmail.com Received: by 10.231.36.139 with HTTP; Wed, 17 Nov 2010 21:18:59 -0800 (PST) In-Reply-To: <4CE27E65.5000709@cisco.com> References: <4CD90C0B.6020006@cisco.com> <4CE27E65.5000709@cisco.com> Date: Wed, 17 Nov 2010 21:18:59 -0800 X-Google-Sender-Auth: GdNzcTk_zrRTweqLCMgWA8zhjtQ Message-ID: Subject: Re: FW: Review request for draft-lu-fast-notification-framework-00.txt From: Albert Tian To: mike shand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: albert.tian@ericsson.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 05:18:16 -0000 Hi Mike, Thanks very much for listening in and sorry for the late reply - stuck in some all day meetings with little net access. Some answers inlined. On Tue, Nov 16, 2010 at 4:51 AM, mike shand wrote: > =A0Albert, > > =A0 =A0I listened to the audio of your presentation in Beijing, and that = has > prompted some questions. > > =A0 =A0I understand that you propose that the FN service is used as in th= e > 802.1aq proposal as an "accelerator" to the normal flooding process. i.e. > the result of the FN process is to temporarily replace older link state > information until such time as it is replaced (or otherwise) by the norma= l > operation of the flooding process. The reliability is provided by the nor= mal > flooding process [tian] yes FN can be either a normal LSP/LSA, or could be in a new format that allows some simplifications. In the former case the FN doesn't have to temporary. > > =A0 =A0As in the .aq proposal, this seems to meet the requirements of > maintaining correctness in the steady state. However, one thing which > concerns me is the possibility of some routers receiving the fast > notification and some not (which is possible, since it is not a reliable > service). The effect of this would be that random routers in the network > would receive the change information much earlier than others, and this > could lead to the generation of relatively long duration micro-loops. [tian] yes some nodes may receive fast notification while others not. However, if we let the FN to in turn trigger slow flooding, I believe we are not any worse than before. Think about these random routers are seeds for the slow flooding. Before we have few seeds immediately adjacent to the failure, now we can have many more. The problem can also be addressed if we use other mechanisms to improve FN reliability. > > =A0 =A0802.1aq does not suffer from this problem directly, since it emplo= ys a > (rather complex, as you hinted:-) loop prevention mechanism, whereby > synchronization of neighbours databases must be achieved (using digest > information) before changes can be made to the FIB. (there are exceptions= , > in that a certain amount of "wiggle room" is permitted while still retain= ing > the guarantee of no loops.). It must be noted that this freedom from > micro-loops is achieved at the expense of dropping packets which might > otherwise loop, so throughput is not maintained. > > =A0 =A0But the point I am making, is that in a normal IGP, the possible w= ide > diversity in update arrival times seems to introduce the possibility of > exacerbating micro-looping caused by desynchronised databases. > [tian] as I mentioned above, if FN further triggers slow flooding, we do not increase the diversity in arrival time. > =A0 =A0I haven't thought too deeply about this, but was wondering if you = had > done any analysis concerning this property. > > =A0 =A0One further question. From reading the OSPF FN draft, it seems tha= t the > arrival of FN information does NOT cause this information to be flooded t= o > neighbors. (in IS-IS terms, SRM is not set). Is that correct? [tian] we are considering both options. Now thinking about the diversity issue your pointed out, I'm leaning towards setting the SRM bits, especially if the underlying implementation is less reliable. With the proper use of SRM, we will not cause any loops (As Sri pointed out, if we don't have additional mechanisms such as SRM, loop may happen if we "flood further" the FN). > > =A0 =A0Oh yes, and another. It is suggested that the FN information is fl= ooded > down a spanning tree, but this spanning tree was presumably computed prio= r > to the failure, and therefore may require the traversal of the link which > has just failed. I don't understand how you guarantee delivery to all > routers in this case. > > In particular the phrase > > " =A0Each router on the tree can send packets to > =A0 all other routers on that tree. Even when the topology changes such > =A0 that the tree breaks, the link-down notification is delivered to all > =A0 routers." [tian] There can be many mechanisms to over come link failures, for example using multiple (disjoint) trees. Its a trade off between cost and reliability. Hope this helps! Thanks, Albert > > > needs some further explanation for me to be able understand it. > > > > > =A0 =A0Mike > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From tli@cisco.com Thu Nov 18 23:04:24 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1563A683D for ; Thu, 18 Nov 2010 23:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agstaX3pSDPa for ; Thu, 18 Nov 2010 23:04:23 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1A72A3A67D6 for ; Thu, 18 Nov 2010 23:04:23 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAC+w5UytJV2Y/2dsb2JhbACUV44CcaE4my2FSwSEWIYC X-IronPort-AV: E=Sophos;i="4.59,221,1288569600"; d="scan'208";a="183702139" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2010 07:05:11 +0000 Received: from dhcp-tmt-wirelessdata-64-104-53-129.cisco.com (dhcp-tmt-wirelessdata-64-104-53-129.cisco.com [64.104.53.129]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id oAJ75A0P014390 for ; Fri, 19 Nov 2010 07:05:11 GMT From: Tony Li Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: A clarification on component link advertisement Date: Fri, 19 Nov 2010 16:05:10 +0900 Message-Id: To: rtgwg@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 07:04:24 -0000 Hi all, In subsequent conversations, it has become apparent that there is some = confusion between advertising information about component links in the = IGP and actually creating IGP adjacencies across those component links. To be crystal clear, what I was suggesting was purely the former: we = would inject specific information about the component links into the = IGP. This would contain things like delay and bandwidth only. There = would be only 1 IGP adjacency on the composite link, it would not matter = which link it ran over (but see below), and we would use some other = mechanism (e.g., BFD) to ensure liveness on each component link. This = insures that the IGP hello mechanisms and flooding mechanisms scale with = the number of the composite links, even if the IGP's link state database = scales with the number of component links. Nit/Question: It would be very nice to be able to allow the IGPs on = neighboring boxes to form an asymmetric adjacency over the composite = link, wherein one of them may transmit protocol packets on one component = and its L3 neighbor could transmit protocol packets on a different = component of the same composite link. If we have achieved an = appropriate level of abstraction, this _should_ just work. However, there's a hitch: do we allow a composite link to have = components which have different models? Can we put a point-to-point = link into the same composite link as a broadcast network? If we do, = then IS-IS at least, runs differently on the two models and would = probably not work in an asymmetric manner in this situation. I suspect = we need a clarification of requirements here. Regards, Tony From lucyyong@huawei.com Fri Nov 19 08:35:18 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598193A6872 for ; Fri, 19 Nov 2010 08:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNAlnvO-dX4r for ; Fri, 19 Nov 2010 08:35:17 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2CE213A6882 for ; Fri, 19 Nov 2010 08:35:17 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC500EY34RW8P@szxga04-in.huawei.com> for rtgwg@ietf.org; Sat, 20 Nov 2010 00:35:56 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC500E604RWOI@szxga04-in.huawei.com> for rtgwg@ietf.org; Sat, 20 Nov 2010 00:35:56 +0800 (CST) Received: from y736742 ([10.124.12.68]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC500M3N4RUIW@szxml06-in.huawei.com> for rtgwg@ietf.org; Sat, 20 Nov 2010 00:35:56 +0800 (CST) Date: Fri, 19 Nov 2010 10:35:53 -0600 From: Yong Lucy Subject: RE: A clarification on component link advertisement In-reply-to: To: 'Tony Li' , rtgwg@ietf.org Message-id: <004201cb8807$d69e0560$440c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuHuCOHts7kAIXkSlKFBZkxdjKFsgATGxqw References: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 16:35:18 -0000 Hi Tony, Thank you very the clarification. It is very helpful. See inline. Regards, Lucy > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Tony Li > Sent: Friday, November 19, 2010 1:05 AM > To: rtgwg@ietf.org > Subject: A clarification on component link advertisement > > > Hi all, > > In subsequent conversations, it has become apparent that there is some > confusion between advertising information about component links in the IGP > and actually creating IGP adjacencies across those component links. > > To be crystal clear, what I was suggesting was purely the former: we would > inject specific information about the component links into the IGP. This > would contain things like delay and bandwidth only. There would be only 1 > IGP adjacency on the composite link, it would not matter which link it ran > over (but see below), and we would use some other mechanism (e.g., BFD) to > ensure liveness on each component link. [LY] Very clear description. This is the objective. >This insures that the IGP hello > mechanisms and flooding mechanisms scale with the number of the composite > links, [LY] You mean component link here. >even if the IGP's link state database scales with the number of > component links. [LY] Yes. > > Nit/Question: It would be very nice to be able to allow the IGPs on > neighboring boxes to form an asymmetric adjacency over the composite link, > wherein one of them may transmit protocol packets on one component and its > L3 neighbor could transmit protocol packets on a different component of > the same composite link. If we have achieved an appropriate level of > abstraction, this _should_ just work. [LY] Agree the approach. > > However, there's a hitch: do we allow a composite link to have components > which have different models? [LY] There are three kinds of component links in the framework draft. What model do you refer here? Can we put a point-to-point link into the > same composite link as a broadcast network? [LY] IMHO: an interface is either an IGP link or a component link in a composite link, but not both. Operator view on this is necessary. >If we do, then IS-IS at least, > runs differently on the two models and would probably not work in an > asymmetric manner in this situation. I suspect we need a clarification of > requirements here. > > Regards, > Tony > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From ning.so@verizonbusiness.com Fri Nov 19 14:26:36 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C283A68F9 for ; Fri, 19 Nov 2010 14:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK3SQZNsoKy3 for ; Fri, 19 Nov 2010 14:26:34 -0800 (PST) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id 2C4203A68ED for ; Fri, 19 Nov 2010 14:26:34 -0800 (PST) Received: from omzismtp01.vzbi.com ([unknown] [165.122.46.164]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LC500A75L1MFI40@firewall.verizonbusiness.com> for rtgwg@ietf.org; Fri, 19 Nov 2010 22:27:24 +0000 (GMT) Received: from omzismtp01.vzbi.com ([unknown] [127.0.0.1]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LC5001E6L1M8W00@omzismtp01.vzbi.com> for rtgwg@ietf.org; Fri, 19 Nov 2010 22:27:22 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LC5001B8L1L8H00@omzismtp01.vzbi.com> for rtgwg@ietf.org; Fri, 19 Nov 2010 22:27:22 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.147]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 22:27:22 +0000 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: A clarification on component link advertisement Date: Fri, 19 Nov 2010 22:27:19 +0000 Message-id: <14584D6EE26B314187A4F68BA206060005D3973D@ASHEVS008.mcilink.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: A clarification on component link advertisement Thread-index: AcuHuB/n+NZaxkPhSd+suiNGX6AfjgAgE/qQ References: From: "So, Ning" To: Tony Li , rtgwg@ietf.org X-OriginalArrivalTime: 19 Nov 2010 22:27:22.0059 (UTC) FILETIME=[EF10C1B0:01CB8838] X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 22:26:36 -0000 Tony, Thanks for the clarification. As discussed, I agree to the approach that does not aggregate component link BW and latency if it does not impact the IGP adjacency. One more question for you. Could you please elaborate on "put a point-to-point link into the same composite link as a broadcast network"? I am not sure I understand what you mean.=20 =20 Best regrads, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Tony Li Sent: Friday, November 19, 2010 1:05 AM To: rtgwg@ietf.org Subject: A clarification on component link advertisement Hi all, In subsequent conversations, it has become apparent that there is some confusion between advertising information about component links in the IGP and actually creating IGP adjacencies across those component links. To be crystal clear, what I was suggesting was purely the former: we would inject specific information about the component links into the IGP. This would contain things like delay and bandwidth only. There would be only 1 IGP adjacency on the composite link, it would not matter which link it ran over (but see below), and we would use some other mechanism (e.g., BFD) to ensure liveness on each component link. This insures that the IGP hello mechanisms and flooding mechanisms scale with the number of the composite links, even if the IGP's link state database scales with the number of component links. Nit/Question: It would be very nice to be able to allow the IGPs on neighboring boxes to form an asymmetric adjacency over the composite link, wherein one of them may transmit protocol packets on one component and its L3 neighbor could transmit protocol packets on a different component of the same composite link. If we have achieved an appropriate level of abstraction, this _should_ just work. However, there's a hitch: do we allow a composite link to have components which have different models? Can we put a point-to-point link into the same composite link as a broadcast network? If we do, then IS-IS at least, runs differently on the two models and would probably not work in an asymmetric manner in this situation. I suspect we need a clarification of requirements here. Regards, Tony _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From tli@cisco.com Fri Nov 19 22:37:13 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A853A68AC for ; Fri, 19 Nov 2010 22:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3iCfm73vCms for ; Fri, 19 Nov 2010 22:37:08 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 760003A696E for ; Fri, 19 Nov 2010 22:37:08 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJj75kyrR7Hu/2dsb2JhbACiY3GgSJsjhUsEhFiGAw X-IronPort-AV: E=Sophos;i="4.59,227,1288569600"; d="scan'208";a="248333002" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Nov 2010 06:37:59 +0000 Received: from tky-vpn-client-231-233.cisco.com (tky-vpn-client-231-233.cisco.com [10.70.231.233]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oAK6bt7t007497; Sat, 20 Nov 2010 06:37:58 GMT Subject: Re: A clarification on component link advertisement Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <004201cb8807$d69e0560$440c7c0a@china.huawei.com> Date: Sat, 20 Nov 2010 15:37:53 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004201cb8807$d69e0560$440c7c0a@china.huawei.com> To: Yong Lucy X-Mailer: Apple Mail (2.1081) Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 06:37:13 -0000 Hi Lucy, >> This insures that the IGP hello >> mechanisms and flooding mechanisms scale with the number of the = composite >> links,=20 > [LY] You mean component link here. Yes, thank you. Doh. >> even if the IGP's link state database scales with the number of >> component links. >> However, there's a hitch: do we allow a composite link to have = components >> which have different models? =20 > [LY] There are three kinds of component links in the framework draft. = What > model do you refer here? You seem to be missing anything other than point-to-point components = (e.g., Ethernet). Do we support those? The requirements don't seem to = exclude those. > Can we put a point-to-point link into the >> same composite link as a broadcast network? =20 > [LY] IMHO: an interface is either an IGP link or a component link in a > composite link, but not both. Operator view on this is necessary. That would seem to preclude recursion, where a composite link is also a = component. I'm not sure that this is useful, but it seems worthy of = being explicitly considered. Tony From tli@cisco.com Fri Nov 19 22:40:41 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACEE3A68D2 for ; Fri, 19 Nov 2010 22:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rZH4vXebWnW for ; Fri, 19 Nov 2010 22:40:39 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8792C3A68AC for ; Fri, 19 Nov 2010 22:40:38 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEr85kytJV2d/2dsb2JhbACiY3GgUZsjhUsEhFiGAw X-IronPort-AV: E=Sophos;i="4.59,227,1288569600"; d="scan'208";a="184307442" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2010 06:41:28 +0000 Received: from tky-vpn-client-231-233.cisco.com (tky-vpn-client-231-233.cisco.com [10.70.231.233]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id oAK6fIwG026442; Sat, 20 Nov 2010 06:41:22 GMT Subject: Re: A clarification on component link advertisement Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <14584D6EE26B314187A4F68BA206060005D3973D@ASHEVS008.mcilink.com> Date: Sat, 20 Nov 2010 15:41:16 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <3236F061-4591-4389-9377-E828986B3936@cisco.com> References: <14584D6EE26B314187A4F68BA206060005D3973D@ASHEVS008.mcilink.com> To: "So, Ning" X-Mailer: Apple Mail (2.1081) Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 06:40:41 -0000 Hi Ning, > One more question for you. Could you please elaborate on "put a > point-to-point link into the same composite link as a broadcast > network"? I am not sure I understand what you mean.=20 Can a point-to-point Ethernet be a component? What about a switched Ethernet? What about a switched Ethernet with other hosts on the Ethernet? What happens if there are multiple switched Ethernets, with partially = intersecting sets of other hosts? I'm hoping that you're going to say that a component must be a logical = point-to-point link, but I don't see that in the requirements. Regards, Tony From lucyyong@huawei.com Mon Nov 22 12:34:20 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B799D28C160 for ; Mon, 22 Nov 2010 12:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuIfHdXmS2MD for ; Mon, 22 Nov 2010 12:34:18 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 740B628C162 for ; Mon, 22 Nov 2010 12:34:18 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCA00DKGZUG9F@szxga04-in.huawei.com> for rtgwg@ietf.org; Tue, 23 Nov 2010 04:35:04 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCA002ORZUGMU@szxga04-in.huawei.com> for rtgwg@ietf.org; Tue, 23 Nov 2010 04:35:04 +0800 (CST) Received: from y736742 ([10.124.12.68]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCA009G2ZUDHW@szxml04-in.huawei.com> for rtgwg@ietf.org; Tue, 23 Nov 2010 04:35:04 +0800 (CST) Date: Mon, 22 Nov 2010 14:35:01 -0600 From: Yong Lucy Subject: RE: A clarification on component link advertisement In-reply-to: To: 'Tony Li' Message-id: <00e501cb8a84$be047370$440c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuIfXvUCT9g3s7bSIGjekJpxyd49gCBas2Q References: <004201cb8807$d69e0560$440c7c0a@china.huawei.com> Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 20:34:21 -0000 Hi Tony, > > >> However, there's a hitch: do we allow a composite link to have > components > >> which have different models? > > [LY] There are three kinds of component links in the framework draft. > What > > model do you refer here? > > > You seem to be missing anything other than point-to-point components (e.g., > Ethernet). Do we support those? The requirements don't seem to exclude > those. [LY] Thank you for the statement. IMO, we need to clarify about component link definition in the draft. i.e. point-to-point connection. > > > > Can we put a point-to-point link into the > >> same composite link as a broadcast network? > > [LY] IMHO: an interface is either an IGP link or a component link in a > > composite link, but not both. Operator view on this is necessary. > > > That would seem to preclude recursion, where a composite link is also a > component. I'm not sure that this is useful, but it seems worthy of being > explicitly considered. > [LY] A composite link can be one segment of a component link in another composite link. But, IMHO: an IGP link should not be a component link as well vice versa. It seems that the definitions are not precise yet. Regards, Lucy From ning.so@verizonbusiness.com Tue Nov 23 14:10:52 2010 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBF628C0E5 for ; Tue, 23 Nov 2010 14:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ymFJLD3CbzE for ; Tue, 23 Nov 2010 14:10:46 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id A20113A69D5 for ; Tue, 23 Nov 2010 14:10:46 -0800 (PST) Received: from omzismtp01.vzbi.com ([unknown] [165.122.46.164]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LCC003E0YZKVK60@firewall.verizonbusiness.com> for rtgwg@ietf.org; Tue, 23 Nov 2010 22:11:44 +0000 (GMT) Received: from omzismtp01.vzbi.com ([unknown] [127.0.0.1]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LCC005FLYZJB500@omzismtp01.vzbi.com> for rtgwg@ietf.org; Tue, 23 Nov 2010 22:11:44 +0000 (GMT) Received: from ASHSRV139.mcilink.com ([unknown] [153.39.68.165]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LCC0055IYZJBA00@omzismtp01.vzbi.com> for rtgwg@ietf.org; Tue, 23 Nov 2010 22:11:43 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.145]) by ASHSRV139.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Nov 2010 22:11:43 +0000 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: A clarification on component link advertisement Date: Tue, 23 Nov 2010 22:11:40 +0000 Message-id: <14584D6EE26B314187A4F68BA206060005DB4CE4@ASHEVS008.mcilink.com> In-reply-to: <3236F061-4591-4389-9377-E828986B3936@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: A clarification on component link advertisement Thread-index: AcuIffdV5Gc+kTBnT9yhznjaGEkRsAC3LgLQ References: <14584D6EE26B314187A4F68BA206060005D3973D@ASHEVS008.mcilink.com> <3236F061-4591-4389-9377-E828986B3936@cisco.com> From: "So, Ning" To: Tony Li X-OriginalArrivalTime: 23 Nov 2010 22:11:43.0117 (UTC) FILETIME=[691093D0:01CB8B5B] Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 22:10:52 -0000 Tony, Thank you for the clarification, and I agree with you that a component link should be limited to a physical and/or logical point-to-point link. Personally I do not see an application for the other types, and allowing them will make solutions too complicated. I can certainly make the changes to the requirement draft if there is no objection. =20 =20 Best regrads, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 -----Original Message----- From: Tony Li [mailto:tli@cisco.com]=20 Sent: Saturday, November 20, 2010 12:41 AM To: So, Ning Cc: rtgwg@ietf.org Subject: Re: A clarification on component link advertisement Hi Ning, > One more question for you. Could you please elaborate on "put a > point-to-point link into the same composite link as a broadcast > network"? I am not sure I understand what you mean.=20 Can a point-to-point Ethernet be a component? What about a switched Ethernet? What about a switched Ethernet with other hosts on the Ethernet? What happens if there are multiple switched Ethernets, with partially intersecting sets of other hosts? I'm hoping that you're going to say that a component must be a logical point-to-point link, but I don't see that in the requirements. Regards, Tony