From akatlas@gmail.com Mon Feb 7 08:44:14 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D433A6E24 for ; Mon, 7 Feb 2011 08:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9D-JB-jY+zg for ; Mon, 7 Feb 2011 08:44:13 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7F2453A6E0F for ; Mon, 7 Feb 2011 08:44:13 -0800 (PST) Received: by gyd12 with SMTP id 12so2038957gyd.31 for ; Mon, 07 Feb 2011 08:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=7nSqANFnaYMdK5ueScPNKfatyEByOP13LkKIoE9vSKo=; b=hX4t9II/8gX4K5Nx+W99j+BDZiMIjQnBX+cn6rkk7uemMqQr9AxeoDladZsUArEP0s QTTT0QzcTZylFM1+r58CjZv5KZJxlh+NmCo7Csddpy1PUdRbj6CwW61wLUsfWHjJA3M8 nBO73sZU81cElGeFzRe5rnNjEQnORFxQoTTmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=rQT8pyvcTdreK03rYF5B3bWuzyDqHw6S3RiYRsrpe6JvTvKAV5t7g7HfmOHB6H0ROi 6muI7zMvqU1MDCWmedHk7LMzp5XC3PRBTEUjLIwbGR64mGtcUTHlgfk6wCrnHCQZ2DG/ 4Hg/FHk3PKGAVyLKgmJI+DBsFrIQ3F0h2E/28= MIME-Version: 1.0 Received: by 10.103.220.6 with SMTP id x6mr11298808muq.90.1297097057163; Mon, 07 Feb 2011 08:44:17 -0800 (PST) Received: by 10.103.224.1 with HTTP; Mon, 7 Feb 2011 08:44:17 -0800 (PST) Date: Mon, 7 Feb 2011 11:44:17 -0500 Message-ID: Subject: LAST DAY: RTGWG Last Call: draft-ietf-rtgwg-cl-requirement-03 From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:44:14 -0000 I have only received one response to this last call. We need more. Thanks, Alia On Mon, Jan 24, 2011 at 8:13 PM, Alia Atlas wrote: > This is to announce a working group last call on > =A0 =A0 =A0draft-ietf-rtgwg-cl-requirement-03 > to conclude on February 7, 2011. > > Please do read this version and send your comments to the list. > > Alia > From akatlas@gmail.com Mon Feb 7 08:47:40 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FBD63A6E28 for ; Mon, 7 Feb 2011 08:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qbrpV37a4dL for ; Mon, 7 Feb 2011 08:47:39 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id AE9683A6E22 for ; Mon, 7 Feb 2011 08:47:39 -0800 (PST) Received: by gxk27 with SMTP id 27so2042369gxk.31 for ; Mon, 07 Feb 2011 08:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=HgCBewh02jz+Oa5z3/64S68b+DVPy/LScvsat0YW7Ts=; b=C8JOw+zmnyU/Dz35cUYTEt5niw9fS1RmQH8pZ3I1wBu89dkPemClraum5B2hdebBpR Zxnt2nLyHd2N2TtnoaOdR+DcN7FGDV2ODpRUu5HoqDMAzEoGRsRDmj3T8osPvlFfEKMt 6gupbshf/5lXwFojD4aptAiDJjVu2UoXRKGEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DvvtrbuHG0n18VyI8wvNr7QBcR0QM7PLWxA42ZgtXNqo2DxxTjXDkS9o/mp7ghfvLK /VSfNdFGxO3VnGrpuK5tds8CFUWofERhy5D2Pswggw8AjJhv2FFew3ow4VDl8lOXI+kd JJfqaXe/THpjsIDqQVaCmixFjA2dNlY09CqMI= MIME-Version: 1.0 Received: by 10.103.198.18 with SMTP id a18mr11200449muq.126.1297097263492; Mon, 07 Feb 2011 08:47:43 -0800 (PST) Received: by 10.103.224.1 with HTTP; Mon, 7 Feb 2011 08:47:43 -0800 (PST) Date: Mon, 7 Feb 2011 11:47:43 -0500 Message-ID: Subject: items for upcoming IETF meeting 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: Mon, 07 Feb 2011 16:47:40 -0000 We are scheduling our RTGWG session for the next IETF. Please let us know if you would like time during the meeting. For this IETF, I would like to see discussion around the possible architectures and solutions to meet the Composite Link requirements. In RTGWG, we don't do the protocols, but we do the architectures that connect the different protocol pieces together. Please submit drafts soon. Thanks, Alia From mark.ietf@gmail.com Mon Feb 7 20:50:55 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBA63A6C99 for ; Mon, 7 Feb 2011 20:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zy8FpXhqQ25 for ; Mon, 7 Feb 2011 20:50:54 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 5E7503A6BDF for ; Mon, 7 Feb 2011 20:50:54 -0800 (PST) Received: by iym1 with SMTP id 1so5285724iym.31 for ; Mon, 07 Feb 2011 20:51:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=K9YfezLEDYIc4oonzhedosRfjVeQWBw2ip/Q8rY2i20=; b=qfa99czaXcVtv4Y1Pfz7PD5kDRQehd1rAhMslpiDULqeQnrKAsoTThVpMpngXM0Uav djEl4Iv3mkmpTG14ISCHIgzUE0Laod1LjzII7VsPgvYXQs16954/NRqOamt70CBVTaNH uKxTzeiTXMdOnX+yHQI5Kq/gPX6sxnb9yV7Sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XlSAQtlH8YHMb6vKYndWVT7QRlxslHpLeg3Czk2rR2bBKB83fodkI18hlhKv1vd+4Z EoNkm4AAOqWcxEjLKAVjX4Ha/ad7qtLYZ+U448530FJnSaVNrh9v33f+AfOuUuumq/8s Af42tB0Kg+2a6Kwpt/2qIkMcANU9zvjcPLL/0= MIME-Version: 1.0 Received: by 10.231.153.195 with SMTP id l3mr18385051ibw.150.1297140660139; Mon, 07 Feb 2011 20:51:00 -0800 (PST) Received: by 10.231.200.132 with HTTP; Mon, 7 Feb 2011 20:51:00 -0800 (PST) Date: Tue, 8 Feb 2011 10:21:00 +0530 Message-ID: Subject: IP interface over a Composite link From: mark Brown 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: Tue, 08 Feb 2011 04:50:55 -0000 Hi, I am assuming that we can create an IP interface over composite links and can do all sorts of funky things that one can do on an IP interface like running OSPF, IS-IS, etc over it. Is this correct? The two ends of the composite links (even if the component links are MPLS LSPs) will be able to ping, etc. and behave as normal IP interfaces. Thanks, Mark From tony.li@tony.li Mon Feb 7 21:31:07 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59413A7024 for ; Mon, 7 Feb 2011 21:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s6E5ITv3Z1J for ; Mon, 7 Feb 2011 21:31:07 -0800 (PST) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id 18E7E3A7022 for ; Mon, 7 Feb 2011 21:31:07 -0800 (PST) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta13.emeryville.ca.mail.comcast.net with comcast id 5H4b1g0031u4NiLADHEmk1; Tue, 08 Feb 2011 05:14:46 +0000 Received: from [192.168.2.100] ([98.248.36.188]) by omta21.emeryville.ca.mail.comcast.net with comcast id 5HEk1g00W43ZcXW8hHEkg5; Tue, 08 Feb 2011 05:14:45 +0000 Subject: Re: IP interface over a Composite link Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Mon, 7 Feb 2011 21:13:43 -0800 Content-Transfer-Encoding: 7bit Message-Id: <00450255-6D8F-4866-8C55-05E499F10FD6@tony.li> References: To: mark Brown X-Mailer: Apple Mail (2.1082) 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, 08 Feb 2011 05:31:07 -0000 On Feb 7, 2011, at 8:51 PM, mark Brown wrote: > Hi, > > I am assuming that we can create an IP interface over composite links > and can do all sorts of funky things that one can do on an IP > interface like running OSPF, IS-IS, etc over it. Is this correct? > > The two ends of the composite links (even if the component links are > MPLS LSPs) will be able to ping, etc. and behave as normal IP > interfaces. That would match my expectations. Tony From jeff.tantsura@ericsson.com Mon Feb 7 22:17:36 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787233A7019 for ; Mon, 7 Feb 2011 22:17:36 -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 53r3St+8cyov for ; Mon, 7 Feb 2011 22:17:34 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 430553A6B69 for ; Mon, 7 Feb 2011 22:17:34 -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 p1871FG6021487; Tue, 8 Feb 2011 01:01:17 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.168]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 8 Feb 2011 01:17:32 -0500 From: Jeff Tantsura To: Tony Li Date: Tue, 8 Feb 2011 01:17:24 -0500 Subject: Re: IP interface over a Composite link Thread-Topic: IP interface over a Composite link Thread-Index: AcvHV96SBRzauNNJToSELVeNi89efw== Message-ID: <9B778999-3FF4-400D-8918-22F02C6DDFF4@ericsson.com> References: <00450255-6D8F-4866-8C55-05E499F10FD6@tony.li> In-Reply-To: <00450255-6D8F-4866-8C55-05E499F10FD6@tony.li> 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: Tue, 08 Feb 2011 06:17:36 -0000 We may even consider running RIP over it! Regards, Jeff On Feb 7, 2011, at 21:31, "Tony Li" wrote: >=20 > On Feb 7, 2011, at 8:51 PM, mark Brown wrote: >=20 >> Hi, >>=20 >> I am assuming that we can create an IP interface over composite links >> and can do all sorts of funky things that one can do on an IP >> interface like running OSPF, IS-IS, etc over it. Is this correct? >>=20 >> The two ends of the composite links (even if the component links are >> MPLS LSPs) will be able to ping, etc. and behave as normal IP >> interfaces. >=20 >=20 > That would match my expectations. >=20 > Tony >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From sriganeshkini@gmail.com Tue Feb 8 07:41:31 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80583A6765 for ; Tue, 8 Feb 2011 07:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, 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 wxeOWaZWMqdy for ; Tue, 8 Feb 2011 07:41:31 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id AA55B3A67A8 for ; Tue, 8 Feb 2011 07:41:30 -0800 (PST) Received: by fxm9 with SMTP id 9so6673051fxm.31 for ; Tue, 08 Feb 2011 07:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=SXdE3rliIRZZCwkSRv1itRVho+extIfVZ+1nz8UN0kw=; b=TbDa0k1J7UEatCceMt6ijZ0JDY0IeAQF2Ey6gaeauxK/+gHTOcaFfAibT1/mq5HRFX ubCjTsKWjZ6eU5cA5jybyjOy50lt+ArmNRuzqILg3UcpsOanUpqAnQZjwmWzfYZ6ExYu I/5DActSAMuq8pAjYch6StlGNrX67gctYqewk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; b=mC2N+xgL9oOLb42YZ2txiUPpUP/HemzHxpk3L1yHSJyNTmDO6RZoBYodOTxEUDBeLm nugQKFiGqh0Ic9EMzdyfzin+jZEHxkWiHVp+r60Ym7AWI14B5EFu8rhUEK1GFw5m4iL4 MPTE3ik9jhRmcayd6ya0xdUPboVJHEQq2XcEA= Received: by 10.223.86.2 with SMTP id q2mr10505678fal.139.1297179696953; Tue, 08 Feb 2011 07:41:36 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.223.102.65 with HTTP; Tue, 8 Feb 2011 07:29:24 -0800 (PST) From: Sriganesh Kini Date: Tue, 8 Feb 2011 07:29:24 -0800 X-Google-Sender-Auth: _m6-Gc7gR0uEaNsxvaljLY5eivE Message-ID: Subject: Regarding definition of component and composite link To: Alia Atlas , dave.mcdysan@verizon.com Content-Type: multipart/alternative; boundary=20cf30433ee80bfc8c049bc72ff2 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, 08 Feb 2011 15:41:32 -0000 --20cf30433ee80bfc8c049bc72ff2 Content-Type: text/plain; charset=ISO-8859-1 Hi Dave (and other authors), It may be useful to clarify in the definition of component and composite links in sec 3, whether the component links share the same endpoints as the composite that it belongs to. While this may seem trivially obvious, consider a topology such as +-----+ +----------+ | |------------| Ethernet | +------+ |LSR A| | Switch |-------------|LSR B | | |------------| | +------+ +-----+ +----------+ Here LSR A and the Ethernet Switch are connected by an Ethernet Link Group having two (component) links. The switch itself may be bridging or simply cross-connecting the Link Group to the link to LSR B. LSR A and LSR B have a link between themselves through the ethernet switch. By the definition in sec 3 it may be possible to interpret that LSR A has a 2 member composite link to another LSR. Another way to reword the definition in sec 3 may be to use the term subnetwork similar to the ITU-T definition. Thanks On Mon, Jan 24, 2011 at 5:13 PM, Alia Atlas wrote: > > This is to announce a working group last call on > draft-ietf-rtgwg-cl-requirement-03 > to conclude on February 7, 2011. > > Please do read this version and send your comments to the list. > > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg -- - Sri --20cf30433ee80bfc8c049bc72ff2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dave (and other authors)= ,

It may be useful to clarify in the definition of component and com= posite links in sec 3, whether the component links share the same endpoints= as the composite that it belongs to.

While this may seem trivially obvious, consider a topology such as
<= br> =A0+-----+ =A0 =A0 =A0 =A0 =A0 =A0+----------+
=A0| =A0 =A0 |------------| Ethernet | = =A0 =A0 =A0 =A0 =A0 =A0 +------+
=A0|LSR A| =A0 =A0 =A0 =A0 =A0 =A0| Switch =A0 |-------------|LSR B |
=A0| =A0 =A0 |------= ------| =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 +------+
=A0+-----+ =A0 =A0 =A0 = =A0 =A0 =A0+----------+

Here LSR A and the Ethernet Switch are connected by an Ethern= et Link Group having two (component) links. The switch itself may be bridgi= ng or simply cross-connecting the Link Group to the link to LSR B. LSR A an= d LSR B have a link between themselves through the ethernet switch. By the = definition in sec 3 it may be possible to interpret that LSR A has a 2 memb= er composite link to another LSR.

= Another way to reword the d= efinition in sec 3 may be to use the term subnetwork similar to the ITU-T d= efinition.

= Thanks
=A0=A0

On Mon, Jan 24, 2011 at 5:13 PM, Alia Atlas <akatlas@gmail.com> wrote:
&g= t;
> This is to announce a working group last call on
> =A0 =A0= =A0draft-ietf-rtgwg-cl-requirement-03
> to conclude on February 7, 2011.
>
> Please do read this v= ersion and send your comments to the list.
>
> Alia
> ___= ____________________________________________
> rtgwg mailing list
> rtgwg@ietf.org=
> https://www.ietf.org/mailman/listinfo/rtgwg




--
- Sri
--20cf30433ee80bfc8c049bc72ff2-- From ning.so@verizonbusiness.com Wed Feb 9 07:14:20 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAFC03A69BE for ; Wed, 9 Feb 2011 07:14:20 -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 9xZSvH9VHFNv for ; Wed, 9 Feb 2011 07:14:13 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id DA8E03A6405 for ; Wed, 9 Feb 2011 07:14:12 -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 <0LGC00E0OVNUZK10@firewall.verizonbusiness.com> for rtgwg@ietf.org; Wed, 09 Feb 2011 15:14:22 +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 <0LGC00909VNW2100@omzismtp01.vzbi.com> for rtgwg@ietf.org; Wed, 09 Feb 2011 15:14:21 +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 <0LGC0091CVNV1W00@omzismtp01.vzbi.com> for rtgwg@ietf.org; Wed, 09 Feb 2011 15:14:20 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 09 Feb 2011 15:14:19 +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_01CBC86C.0625DB7D" Subject: RE: Regarding definition of component and composite link Date: Wed, 09 Feb 2011 15:14:18 +0000 Message-id: <14584D6EE26B314187A4F68BA2060600068C2357@ASHEVS008.mcilink.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Regarding definition of component and composite link Thread-index: AcvHprVrFIOXHeexTOqlSCYHnTHT+QAxK/iQ References: From: "So, Ning" To: Sriganesh Kini , Alia Atlas , "McDysan, David E (Dave)" X-OriginalArrivalTime: 09 Feb 2011 15:14:19.0708 (UTC) FILETIME=[06401FC0:01CBC86C] 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, 09 Feb 2011 15:14:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC86C.0625DB7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The current definition limits the component link to "a point-to-point physical or logical link that preserves ordering in the steady state". As one of the co-authors, I do not see the need to extend the definition beyond its current definition as it introduces much more complexity with limited benefits, from my point-of-view. =20 =20 =20 Best regards, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 ________________________________ From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Sriganesh Kini Sent: Tuesday, February 08, 2011 9:29 AM To: Alia Atlas; McDysan, David E (Dave) Cc: rtgwg@ietf.org Subject: Regarding definition of component and composite link =20 Hi Dave (and other authors), It may be useful to clarify in the definition of component and composite links in sec 3, whether the component links share the same endpoints as the composite that it belongs to. While this may seem trivially obvious, consider a topology such as +-----+ +----------+ | |------------| Ethernet | +------+ |LSR A| | Switch |-------------|LSR B | | |------------| | +------+ +-----+ +----------+ =20 Here LSR A and the Ethernet Switch are connected by an Ethernet Link Group having two (component) links. The switch itself may be bridging or simply cross-connecting the Link Group to the link to LSR B. LSR A and LSR B have a link between themselves through the ethernet switch. By the definition in sec 3 it may be possible to interpret that LSR A has a 2 member composite link to another LSR. =20 Another way to reword the definition in sec 3 may be to use the term subnetwork similar to the ITU-T definition. =20 Thanks =20 On Mon, Jan 24, 2011 at 5:13 PM, Alia Atlas wrote: > > This is to announce a working group last call on > draft-ietf-rtgwg-cl-requirement-03 > to conclude on February 7, 2011. > > Please do read this version and send your comments to the list. > > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg --=20 - Sri ------_=_NextPart_001_01CBC86C.0625DB7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The current definition limits the = component link to “a point-to-point physical or logical link that preserves = ordering in the steady state”.  As one of the co-authors, I do not see = the need to extend the definition beyond its current definition as it introduces = much more complexity with limited benefits, from my point-of-view.  =  

 

 

=

Best regards,

 

=

Ning So

Network Evolution = Planning

Verizon, Inc.

(office) = 972-729-7905

(Cell) = 972-955-0914

 

=

From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Sriganesh Kini
Sent: Tuesday, February = 08, 2011 9:29 AM
To: Alia Atlas; = McDysan, David E (Dave)
Cc: rtgwg@ietf.org
Subject: Regarding = definition of component and composite link

 

Hi Dave (and other authors),

It may be useful to clarify in the definition of component and composite = links in sec 3, whether the component links share the same endpoints as the = composite that it belongs to.

While this may seem trivially obvious, consider a topology such as

 +-----+           =  +----------+

 |     |------------| Ethernet | =             +------+
 |LSR A|            | Switch   |-------------|LSR B |

 |     |------------|   =        |             = +------+

 +-----+            +----------+

 

Here LSR A and the Ethernet Switch are connected = by an Ethernet Link Group having two (component) links. The switch itself may = be bridging or simply cross-connecting the Link Group to the link to LSR B. = LSR A and LSR B have a link between themselves through the ethernet switch. By = the definition in sec 3 it may be possible to interpret that LSR A has a 2 = member composite link to another LSR.

 

Another way to reword the definition in sec 3 may = be to use the term subnetwork similar to the ITU-T = definition.

 

Thanks

  


On Mon, Jan 24, 2011 at 5:13 PM, Alia Atlas <akatlas@gmail.com> wrote:
>
> This is to announce a working group last call on
>      draft-ietf-rtgwg-cl-requirement-03
> to conclude on February 7, 2011.
>
> Please do read this version and send your comments to the list.
>
> Alia
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg




--
- Sri

------_=_NextPart_001_01CBC86C.0625DB7D-- From akatlas@gmail.com Tue Feb 22 10:42:05 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64243A692B for ; Tue, 22 Feb 2011 10:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQyOGZtq0+Qs for ; Tue, 22 Feb 2011 10:42:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 43AC83A6916 for ; Tue, 22 Feb 2011 10:42:01 -0800 (PST) Received: by iyj8 with SMTP id 8so2135546iyj.31 for ; Tue, 22 Feb 2011 10:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=ANsLohmDSkH5xUGPmGEsqoWAK4c/oWrbhFN+uXSIXHs=; b=a8MBTAbJX2MX0PxPBwTYuerwC9TnyIlHNXE9QIhLr5px/Nm/qnkKMHnin9thTgU0XW HESfIhAJsV4RMGwRBm6iqy8yZSWB/8SzN2Ykf1XyZ1l3DvNN9CPAHHF+R1q5GlEuWypZ U58TA3li80cFsXCBKqGxlrM1kRoeTmMxTXGMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qXSlydRAzspa6h9Ddw8WvdPDcbMf9EuQLKrFg/j84UcmD1Jf1xX3nXIKMyBumlLxrt l7wSjUtxZ8eIqTLif/gAvOxAPrXwScOw2fBviD0gT5LxATwzm5u9x3e/Tny+HYtncBBx 4FHjHeHGl50yLfJOdRj+efg1XicT25k3Bk0wg= MIME-Version: 1.0 Received: by 10.42.95.17 with SMTP id d17mr3230971icn.136.1298400166065; Tue, 22 Feb 2011 10:42:46 -0800 (PST) Received: by 10.42.75.199 with HTTP; Tue, 22 Feb 2011 10:42:46 -0800 (PST) Date: Tue, 22 Feb 2011 13:42:46 -0500 Message-ID: Subject: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 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: Tue, 22 Feb 2011 18:42:05 -0000 The WG last call on draft-ietf-rtgwg-cl-requirement-03 is successfully completed. There were a few comments that should be rolled into a new version - and we'll send that updated draft to the IESG. Alia From dave.mcdysan@verizon.com Wed Feb 23 05:55:37 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EB83A69FA for ; Wed, 23 Feb 2011 05:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97Uuu2HeVxN8 for ; Wed, 23 Feb 2011 05:55:36 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id C4BEB3A68D5 for ; Wed, 23 Feb 2011 05:55:36 -0800 (PST) Received: from fldsmtpi03.verizon.com ([166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p1NDu8nw012992 for ; Wed, 23 Feb 2011 08:56:13 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,212,1297036800"; d="scan'208";a="93416" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 23 Feb 2011 13:56:08 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB05.us.one.verizon.com ([2002:a644:3bc0::a644:3bc0]) with mapi; Wed, 23 Feb 2011 08:56:08 -0500 To: Alia Atlas , "rtgwg@ietf.org" Date: Wed, 23 Feb 2011 08:56:07 -0500 Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-Topic: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-Index: AcvTYWuh0tenYTIeROuklY+RojWZAg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 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: Wed, 23 Feb 2011 13:55:37 -0000 Hi, According to my records, the following changes resulted from the last call discussion: Thread titled "Designated Component link, final proposed text from Tony Li 1/28/11 "The solution MUST support an optional means for LSP signaling to bind an LSP to a particular component link within a composite link. If this option is applied to a bidirectional LSP, both directions of the LSP are bound to the component. If this option is not exercised, then an LSP that is bound to a composite link may be bound to any component link matching all other signaled requirements, and different directions of a bidirectional LSP can be bound to different component links." ------ There was a separate thread started by Sringagesh Kini titled "Regarding definition of component and composite link," which continued in an off list discussion. The result of that discussion was to add the specific use case clarifications and associated text proposed by Sri to the framework draft and not modify the requirements draft. If I missed something from the last call discussion, please respond to this Email so that I can roll these comments into a new version as Alia has requested. Thanks, Dave On 2/22/11 1:42 PM, "Alia Atlas" wrote: >The WG last call on draft-ietf-rtgwg-cl-requirement-03 is successfully >completed. >There were a few comments that should be rolled into a new version - and >we'll >send that updated draft to the IESG. > >Alia >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From lucy.yong@huawei.com Wed Feb 23 07:30:46 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69A23A6A42 for ; Wed, 23 Feb 2011 07:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.436, 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 9SjST1pUUL3e for ; Wed, 23 Feb 2011 07:30:46 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id A7E423A6A4E for ; Wed, 23 Feb 2011 07:30:42 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH200GWCTSH7C@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 09:31:29 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LH2004NVTSBGY@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 09:31:27 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Feb 2011 07:31:24 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 23 Feb 2011 07:31:22 -0800 Date: Wed, 23 Feb 2011 15:31:22 +0000 From: Lucy yong Subject: RE: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 In-reply-to: X-Originating-IP: [10.47.141.54] To: "Mcdysan, David E" , Alia Atlas , "rtgwg@ietf.org" Message-id: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-index: AcvTYWuhy7IyJ+0ElkiIdCJYu4kkfgAC4U2w X-MS-Has-Attach: X-MS-TNEF-Correlator: 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, 23 Feb 2011 15:30:47 -0000 > "The solution MUST support an optional means for LSP signaling to bind an > LSP to a particular component link within a composite link. [LY] The network already supports this solution today, i.e. announce each (component) link as an IGP and/or IGP-TE link. Head-end node can use ERO to inform the nodes to bind LSP to the (component) link. [LY] IMO: when the router of a composite link does not explicitly announce all of its component links, the solution should also allow singling a bidirectional LSP w/ an indication whether it has to be placed on the same component link in both direction or not. Lucy If this > option is applied to a bidirectional LSP, both directions of the LSP are > bound to the component. If this option is not exercised, then an LSP that > is bound to a composite link may be bound to any component link matching > all other signaled requirements, and different directions of a > bidirectional LSP can be bound to different component links." > > ------ > > There was a separate thread started by Sringagesh Kini titled "Regarding > definition of component and composite link," which continued in an off > list discussion. The result of that discussion was to add the specific use > case clarifications and associated text proposed by Sri to the framework > draft and not modify the requirements draft. > > If I missed something from the last call discussion, please respond to > this Email so that I can roll these comments into a new version as Alia > has requested. > > Thanks, > > Dave > > > On 2/22/11 1:42 PM, "Alia Atlas" wrote: > > >The WG last call on draft-ietf-rtgwg-cl-requirement-03 is successfully > >completed. > >There were a few comments that should be rolled into a new version - and > >we'll > >send that updated draft to the IESG. > > > >Alia > >_______________________________________________ > >rtgwg mailing list > >rtgwg@ietf.org > >https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From tony.li@tony.li Wed Feb 23 08:18:00 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414953A68FE for ; Wed, 23 Feb 2011 08:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwVgWjSD-88p for ; Wed, 23 Feb 2011 08:17:59 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 5E50C3A68AC for ; Wed, 23 Feb 2011 08:17:59 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id BU6H1g0031ei1Bg57UJnYj; Wed, 23 Feb 2011 16:18:47 +0000 Received: from sjc-vpn4-1042.cisco.com ([128.107.239.233]) by omta24.westchester.pa.mail.comcast.net with comcast id BUJR1g02s52qHCY3kUJW7p; Wed, 23 Feb 2011 16:18:44 +0000 Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> Date: Wed, 23 Feb 2011 08:18:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9CE0B40C-1EA4-41D2-98C0-B8007F45905E@tony.li> References: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> To: Lucy yong X-Mailer: Apple Mail (2.1082) 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, 23 Feb 2011 16:18:00 -0000 Hi Lucy, >> "The solution MUST support an optional means for LSP signaling to = bind an >> LSP to a particular component link within a composite link.=20 >=20 > [LY] The network already supports this solution today, i.e. announce = each (component) link as an IGP and/or IGP-TE link. Head-end node can = use ERO to inform the nodes to bind LSP to the (component) link.=20 A solution can take that approach to fulfill that requirement, but = having each component be an individual IGP adjacency works against the = scalability requirements. Solutions that make use of IGP aggregation to achieve scalability will = want to add mechanisms to provide for binding to individual components. Tony From lucy.yong@huawei.com Wed Feb 23 08:55:01 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5733A68F2 for ; Wed, 23 Feb 2011 08:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 ymQb6Dz80JHC for ; Wed, 23 Feb 2011 08:55:00 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 8D4153A68C5 for ; Wed, 23 Feb 2011 08:55:00 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH200ADIXOWR1@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 10:55:45 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LH200HRJXOVZ5@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 10:55:44 -0600 (CST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Feb 2011 08:55:45 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 23 Feb 2011 08:55:43 -0800 Date: Wed, 23 Feb 2011 16:55:42 +0000 From: Lucy yong Subject: RE: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 In-reply-to: <9CE0B40C-1EA4-41D2-98C0-B8007F45905E@tony.li> X-Originating-IP: [10.47.142.190] To: Tony Li Message-id: <2691CE0099834E4A9C5044EEC662BB9D2AB958@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-index: AcvTYWuhy7IyJ+0ElkiIdCJYu4kkfgAFBkOxAAEUdCA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> <9CE0B40C-1EA4-41D2-98C0-B8007F45905E@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, 23 Feb 2011 16:55:01 -0000 > > >> "The solution MUST support an optional means for LSP signaling to bind > an > >> LSP to a particular component link within a composite link. > > > > [LY] The network already supports this solution today, i.e. announce > each (component) link as an IGP and/or IGP-TE link. Head-end node can use > ERO to inform the nodes to bind LSP to the (component) link. > > > A solution can take that approach to fulfill that requirement, but having > each component be an individual IGP adjacency works against the > scalability requirements. [LY] Yes. Composite link ability to hide some individual component link provides the scalability in IGP. > > Solutions that make use of IGP aggregation to achieve scalability will > want to add mechanisms to provide for binding to individual components. [LY] If individual component link needs to be advertised, it is not clear to me how to achieve the scalability. > > Tony From tony.li@tony.li Wed Feb 23 09:59:30 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4563A693B for ; Wed, 23 Feb 2011 09:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 VfvXX7IbfWmD for ; Wed, 23 Feb 2011 09:59:30 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id ED41B3A6810 for ; Wed, 23 Feb 2011 09:59:29 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta14.westchester.pa.mail.comcast.net with comcast id BVf01g0031swQuc5EW0J4i; Wed, 23 Feb 2011 18:00:18 +0000 Received: from dhcp-171-70-245-59.cisco.com ([171.70.245.59]) by omta15.westchester.pa.mail.comcast.net with comcast id BW011g01e1Hd52b3bW04KM; Wed, 23 Feb 2011 18:00:15 +0000 Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D2AB958@DFWEML501-MBX.china.huawei.com> Date: Wed, 23 Feb 2011 09:59:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@tony.li> References: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> <9CE0B40C-1EA4-41D2-98C0-B8007F45905E@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2AB958@DFWEML501-MBX.china.huawei.com> To: Lucy yong X-Mailer: Apple Mail (2.1082) 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, 23 Feb 2011 17:59:31 -0000 > [LY] If individual component link needs to be advertised, it is not = clear to me how to achieve the scalability. Well, there's a tradeoff involved. One possible compromise, as I = outlined in Beijing, would be to create IGP adjacencies only for the = composite links and then to enumerate the relevant link attributes of = the components as subTLVs of the composite link. This reduces the number of IGP adjacencies, reduces the number of L3 = visible links for SPF purposes, and reduces the LSDB overhead (as a = component is less data than a full link). This is not a panacea. In advertising the component attributes (as = required), additional state is required. TANSTAAFL. If anyone has discovered a way to break the Shannon limit and transmit = more information without more signal, please step forward now. ;-) Regards, Tony From fu.xihua@zte.com.cn Wed Feb 23 10:18:19 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5BE3A676A; Wed, 23 Feb 2011 10:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.736 X-Spam-Level: X-Spam-Status: No, score=-99.736 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 oqmbY5kr7mXX; Wed, 23 Feb 2011 10:18:18 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 2265E3A68DC; Wed, 23 Feb 2011 10:18:17 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205953898117248; Thu, 24 Feb 2011 02:14:00 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.5422451558; Thu, 24 Feb 2011 02:18:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1NIIscq010138; Thu, 24 Feb 2011 02:18:54 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) In-Reply-To: <9CE0B40C-1EA4-41D2-98C0-B8007F45905E@tony.li> To: Tony Li Subject: Re: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Thu, 24 Feb 2011 02:18:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-24 02:18:57, Serialize complete at 2011-02-24 02:18:57 Content-Type: multipart/alternative; boundary="=_alternative 00649D0648257840_=" X-MAIL: mse01.zte.com.cn p1NIIscq010138 Cc: rtgwg-bounces@ietf.org, "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, 23 Feb 2011 18:18:19 -0000 This is a multipart message in MIME format. --=_alternative 00649D0648257840_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgVG9ueSwNCg0KSSBub3RpY2VkIHRoYXQgdGhlcmUgaXMgYSBjaGFuZ2Ugb2YgRlIjMSBiZXR3 ZWVuIHR3byB2ZXJzaW9uIGRyYWZ0Lg0KIkEgY29tcG9zaXRlIGxpbmsgQ0FOIGJlIGFubm91bmNl ZCBpbiBjb25qdW5jdGlvbiB3aXRoIGRldGFpbGVkIHBhcmFtZXRlcnMgDQphYm91dCBpdHMgY29t cG9uZW50IGxpbmtzLCBzdWNoIGFzIGJhbmR3aWR0aCBhbmQgbGF0ZW5jeS4gVGhlIGNvbXBvc2l0 ZSANCmxpbmsgU0hBTEwgYmVoYXZlIGFzIGEgc2luZ2xlIElHUCBhZGphY2VuY3kuIg0KSSB0aGlu ayB3ZSBtYXkgY2F0Y2ggdGhlIHNvbHV0aW9uIGZyb20gcmZjNDIwMSBhbmQgDQpkcmFmdC1pZXRm LW1wbHMtZXhwbGljaXQtcmVzb3VyY2UtY29udHJvbC1idW5kbGUtMDggZm9yIGJhbmR3aWR0aC4N CkZvciBsYXRlbmN5LCB0aGVydCBpcyBhIGRlc2NyaXB0aW9uIGFib3V0IGl0IGluIA0KZHJhZnQt d2FuZy1jY2FtcC1sYXRlbmN5LXRlLW1ldHJpYy0wMi4gVGhlcmUgbWF5IGJlIHR3byBjaG9pY2Ug Lg0KMS4gIldoZW4gdGhlIGNvbXBvc2l0ZSBsaW5rIGlzIGFkdmVydGlzZWQgaW50byBJR1AsIHRo ZSBsYXRlbmN5IG9mIA0KY29tcG9zaXRlIGxpbmsgc2hvdWxkIGJlIHRoZSByYW5nZSAoZS5nLiwg YXQgbGVhc3QgbWluaW11bSBhbmQgbWF4aW11bSkgDQpsYXRlbmN5IHZhbHVlIG9mIGFsbCBjb21w b25lbnQgbGlua3MuIiAtIGNvbW1lbnQgZnJvbSBEYXZlDQoyLiAiIFdoZW4gdGhlIGNvbXBvc2l0 ZSBsaW5rIGlzIGFkdmVydGlzZWQgaW50byBJR1AsIHRoZSBsYXRlbmN5IG9mIA0KY29tcG9zaXRl IGxpbmsgc2hvdWxkIGJlIHRoZSBtYXhpbXVtIGxhdGVuY3kgdmFsdWUgb2YgYWxsIGNvbXBvbmVu dCANCmxpbmtzLiINCg0KWGlodWEgRnUNCg0KDQoNCg0KVG9ueSBMaSA8dG9ueS5saUB0b255Lmxp PiANCreivP7IyzogIHJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDItMjQgyc/O5yAxMjox OA0KDQrK1bz+yMsNCkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+DQqzrcvNDQoicnRn d2dAaWV0Zi5vcmciIDxydGd3Z0BpZXRmLm9yZz4NCtb3zOINClJlOiBXR0xDIGNvbXBsZXRlZCBv biBkcmFmdC1pZXRmLXJ0Z3dnLWNsLXJlcXVpcmVtZW50LTAzDQoNCg0KDQoNCg0KDQoNCkhpIEx1 Y3ksDQoNCg0KPj4gIlRoZSBzb2x1dGlvbiBNVVNUIHN1cHBvcnQgYW4gb3B0aW9uYWwgbWVhbnMg Zm9yIExTUCBzaWduYWxpbmcgdG8gYmluZCANCmFuDQo+PiBMU1AgdG8gYSBwYXJ0aWN1bGFyIGNv bXBvbmVudCBsaW5rIHdpdGhpbiBhIGNvbXBvc2l0ZSBsaW5rLiANCj4gDQo+IFtMWV0gVGhlIG5l dHdvcmsgYWxyZWFkeSBzdXBwb3J0cyB0aGlzIHNvbHV0aW9uIHRvZGF5LCBpLmUuIGFubm91bmNl IA0KZWFjaCAoY29tcG9uZW50KSBsaW5rIGFzIGFuIElHUCBhbmQvb3IgSUdQLVRFIGxpbmsuIEhl YWQtZW5kIG5vZGUgY2FuIHVzZSANCkVSTyB0byBpbmZvcm0gdGhlIG5vZGVzIHRvIGJpbmQgTFNQ IHRvIHRoZSAoY29tcG9uZW50KSBsaW5rLiANCg0KDQpBIHNvbHV0aW9uIGNhbiB0YWtlIHRoYXQg YXBwcm9hY2ggdG8gZnVsZmlsbCB0aGF0IHJlcXVpcmVtZW50LCBidXQgaGF2aW5nIA0KZWFjaCBj b21wb25lbnQgYmUgYW4gaW5kaXZpZHVhbCBJR1AgYWRqYWNlbmN5IHdvcmtzIGFnYWluc3QgdGhl IA0Kc2NhbGFiaWxpdHkgcmVxdWlyZW1lbnRzLg0KDQpTb2x1dGlvbnMgdGhhdCBtYWtlIHVzZSBv ZiBJR1AgYWdncmVnYXRpb24gdG8gYWNoaWV2ZSBzY2FsYWJpbGl0eSB3aWxsIA0Kd2FudCB0byBh ZGQgbWVjaGFuaXNtcyB0byBwcm92aWRlIGZvciBiaW5kaW5nIHRvIGluZGl2aWR1YWwgY29tcG9u ZW50cy4NCg0KVG9ueQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcnRnd2cgbWFpbGluZyBsaXN0DQpydGd3Z0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zw0KDQoNCg0K --=_alternative 00649D0648257840_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFRvbnksPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIG5vdGljZWQgdGhhdCB0aGVy ZSBpcyBhIGNoYW5nZSBvZg0KRlIjMSBiZXR3ZWVuIHR3byB2ZXJzaW9uIGRyYWZ0LjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7QSBjb21wb3NpdGUgbGlu ayBDQU4gYmUgYW5ub3VuY2VkDQppbiBjb25qdW5jdGlvbiB3aXRoIGRldGFpbGVkIHBhcmFtZXRl cnMgYWJvdXQgaXRzIGNvbXBvbmVudCBsaW5rcywgc3VjaA0KYXMgYmFuZHdpZHRoIGFuZCBsYXRl bmN5LiBUaGUgY29tcG9zaXRlIGxpbmsgU0hBTEwgYmVoYXZlIGFzIGEgc2luZ2xlIElHUA0KYWRq YWNlbmN5LiZxdW90OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ SSB0aGluayB3ZSBtYXkgY2F0Y2ggdGhlIHNvbHV0aW9uIGZyb20NCnJmYzQyMDEgYW5kIGRyYWZ0 LWlldGYtbXBscy1leHBsaWNpdC1yZXNvdXJjZS1jb250cm9sLWJ1bmRsZS0wOCBmb3IgYmFuZHdp ZHRoLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Rm9yIGxhdGVu Y3ksIHRoZXJ0IGlzIGEgZGVzY3JpcHRpb24NCmFib3V0IGl0IGluIGRyYWZ0LXdhbmctY2NhbXAt bGF0ZW5jeS10ZS1tZXRyaWMtMDIuIFRoZXJlIG1heSBiZSB0d28gY2hvaWNlDQouPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiAmcXVvdDtXaGVuIHRoZSBjb21w b3NpdGUgbGluayBpcw0KYWR2ZXJ0aXNlZCBpbnRvIElHUCwgdGhlIGxhdGVuY3kgb2YgY29tcG9z aXRlIGxpbmsgc2hvdWxkIGJlIHRoZSA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNl PSJzYW5zLXNlcmlmIj5yYW5nZQ0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4oZS5nLiwgYXQgbGVhc3QgbWluaW11bSBhbmQgbWF4aW11bSkNCmxhdGVuY3kgdmFsdWUgb2Yg YWxsIGNvbXBvbmVudCBsaW5rcy4mcXVvdDsgLSBjb21tZW50IGZyb20gRGF2ZTwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4gJnF1b3Q7IFdoZW4gdGhlIGNvbXBv c2l0ZSBsaW5rIGlzDQphZHZlcnRpc2VkIGludG8gSUdQLCB0aGUgbGF0ZW5jeSBvZiBjb21wb3Np dGUgbGluayBzaG91bGQgYmUgdGhlIDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9 InNhbnMtc2VyaWYiPm1heGltdW0NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+bGF0ZW5jeSB2YWx1ZSBvZiBhbGwgY29tcG9uZW50IGxpbmtzLiZxdW90OzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WGlodWEgRnU8L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+VG9ueSBM aSAmbHQ7dG9ueS5saUB0b255LmxpJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtydGd3Zy1ib3VuY2VzQGlldGYub3JnPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDItMjQgyc/O5yAx MjoxODwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5MdWN5IHlvbmcgJmx0O2x1Y3kueW9uZ0BodWF3ZWkuY29tJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+JnF1b3Q7cnRnd2dAaWV0Zi5vcmcmcXVvdDsgJmx0O3J0Z3dnQGlldGYub3JnJmd0Ozwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFdHTEMgY29tcGxldGVkIG9uIGRyYWZ0LWlldGYtcnRnd2ct Y2wtcmVxdWlyZW1lbnQtMDM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi cj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCkhpIEx1Y3ksPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyZn dDsgJnF1b3Q7VGhlIHNvbHV0aW9uIE1VU1Qgc3VwcG9ydCBhbiBvcHRpb25hbCBtZWFucyBmb3Ig TFNQIHNpZ25hbGluZw0KdG8gYmluZCBhbjxicj4NCiZndDsmZ3Q7IExTUCB0byBhIHBhcnRpY3Vs YXIgY29tcG9uZW50IGxpbmsgd2l0aGluIGEgY29tcG9zaXRlIGxpbmsuIDxicj4NCiZndDsgPGJy Pg0KJmd0OyBbTFldIFRoZSBuZXR3b3JrIGFscmVhZHkgc3VwcG9ydHMgdGhpcyBzb2x1dGlvbiB0 b2RheSwgaS5lLiBhbm5vdW5jZQ0KZWFjaCAoY29tcG9uZW50KSBsaW5rIGFzIGFuIElHUCBhbmQv b3IgSUdQLVRFIGxpbmsuIEhlYWQtZW5kIG5vZGUgY2FuIHVzZQ0KRVJPIHRvIGluZm9ybSB0aGUg bm9kZXMgdG8gYmluZCBMU1AgdG8gdGhlIChjb21wb25lbnQpIGxpbmsuIDxicj4NCjxicj4NCjxi cj4NCkEgc29sdXRpb24gY2FuIHRha2UgdGhhdCBhcHByb2FjaCB0byBmdWxmaWxsIHRoYXQgcmVx dWlyZW1lbnQsIGJ1dCBoYXZpbmcNCmVhY2ggY29tcG9uZW50IGJlIGFuIGluZGl2aWR1YWwgSUdQ IGFkamFjZW5jeSB3b3JrcyBhZ2FpbnN0IHRoZSBzY2FsYWJpbGl0eQ0KcmVxdWlyZW1lbnRzLjxi cj4NCjxicj4NClNvbHV0aW9ucyB0aGF0IG1ha2UgdXNlIG9mIElHUCBhZ2dyZWdhdGlvbiB0byBh Y2hpZXZlIHNjYWxhYmlsaXR5IHdpbGwNCndhbnQgdG8gYWRkIG1lY2hhbmlzbXMgdG8gcHJvdmlk ZSBmb3IgYmluZGluZyB0byBpbmRpdmlkdWFsIGNvbXBvbmVudHMuPGJyPg0KPGJyPg0KVG9ueTxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KcnRnd2cgbWFpbGluZyBsaXN0PGJyPg0KcnRnd2dAaWV0Zi5vcmc8YnI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnPGJyPg0KPGJyPg0KPC90dD48L2Zv bnQ+DQo8YnI+DQo= --=_alternative 00649D0648257840_=-- From lucy.yong@huawei.com Wed Feb 23 10:19:52 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386BA3A693B for ; Wed, 23 Feb 2011 10:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.374, 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 N9DSscXO34Z9 for ; Wed, 23 Feb 2011 10:19:51 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 6B49F3A6929 for ; Wed, 23 Feb 2011 10:19:51 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH300A861MER1@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 12:20:38 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LH300D2D1MD50@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 12:20:38 -0600 (CST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Feb 2011 10:20:38 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 23 Feb 2011 10:20:36 -0800 Date: Wed, 23 Feb 2011 18:20:36 +0000 From: Lucy yong Subject: RE: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 In-reply-to: <710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@tony.li> X-Originating-IP: [10.47.142.190] To: Tony Li Message-id: <2691CE0099834E4A9C5044EEC662BB9D2AB9A9@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-index: AcvTYWuhy7IyJ+0ElkiIdCJYu4kkfgAFBkOxAAOHT24AAHHjsA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> <9CE0B40C-1EA4-41D2-98C0-B8007F45905E@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2AB958@DFWEML501-MBX.china.huawei.com> <710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@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, 23 Feb 2011 18:19:52 -0000 > Well, there's a tradeoff involved. One possible compromise, as I outlined > in Beijing, would be to create IGP adjacencies only for the composite > links and then to enumerate the relevant link attributes of the components > as subTLVs of the composite link. > [LY] This saves some bits/bytes in SLA, but does not save the amount of the updates for individual component link state. > This reduces the number of IGP adjacencies, reduces the number of L3 > visible links for SPF purposes, and reduces the LSDB overhead (as a > component is less data than a full link). > > This is not a panacea. In advertising the component attributes (as > required), additional state is required. TANSTAAFL. [LY] Yeah. The node scalability is not addressed here. > > If anyone has discovered a way to break the Shannon limit and transmit > more information without more signal, please step forward now. ;-) [LY] If we only advertise a composite link in IGP, each node does not keep the state for individual component links. Can it be the solution? > > Regards, > Tony From tony.li@tony.li Wed Feb 23 10:39:40 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01AFC3A6929 for ; Wed, 23 Feb 2011 10:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 nCR3phV23l6L for ; Wed, 23 Feb 2011 10:39:39 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 22D5F3A6850 for ; Wed, 23 Feb 2011 10:39:39 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta06.westchester.pa.mail.comcast.net with comcast id BWBG1g0031c6gX856WgTvs; Wed, 23 Feb 2011 18:40:27 +0000 Received: from dhcp-171-70-245-59.cisco.com ([171.70.245.59]) by omta23.westchester.pa.mail.comcast.net with comcast id BWg51g02j1Hd52b3jWgCEn; Wed, 23 Feb 2011 18:40:23 +0000 Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D2AB9A9@DFWEML501-MBX.china.huawei.com> Date: Wed, 23 Feb 2011 10:40:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <84CA327B-1101-4C35-93C3-95B40209CBB9@tony.li> References: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> <9CE0B40C-1EA4-41D2-98C0-B8007F45905E@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2AB958@DFWEML501-MBX.china.huawei.com> <710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2AB9A9@DFWEML501-MBX.china.huawei.com> To: Lucy yong X-Mailer: Apple Mail (2.1082) 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, 23 Feb 2011 18:39:40 -0000 > [LY] This saves some bits/bytes in SLA, but does not save the amount = of the updates for individual component link state. TANSTAAFL. > [LY] Yeah. The node scalability is not addressed here. Again, TANSTAAFL. If you have a better idea, please put it on the = table. > [LY] If we only advertise a composite link in IGP, each node does not = keep the state for individual component links. Can it be the solution?=20= It can, but at a very high cost. If the IGP doesn't carry full = information, then you end up being unable to compute successful paths, = even in a stable topology. You end up using crankback for path = computation. We discussed this in Anaheim and Beijing. Tony From tony.li@tony.li Wed Feb 23 11:10:58 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A8F3A6956 for ; Wed, 23 Feb 2011 11:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 k40ER2yjkihw for ; Wed, 23 Feb 2011 11:10:56 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 7CC9E3A6940 for ; Wed, 23 Feb 2011 11:10:55 -0800 (PST) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta01.emeryville.ca.mail.comcast.net with comcast id BWqV1g0071HpZEsA1XBjz0; Wed, 23 Feb 2011 19:11:43 +0000 Received: from dhcp-171-70-245-59.cisco.com ([171.70.245.59]) by omta14.emeryville.ca.mail.comcast.net with comcast id BXBE1g00l1Hd52b8aXBQ3e; Wed, 23 Feb 2011 19:11:38 +0000 Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Wed, 23 Feb 2011 11:11:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: fu.xihua@zte.com.cn X-Mailer: Apple Mail (2.1082) Cc: rtgwg-bounces@ietf.org, "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, 23 Feb 2011 19:10:58 -0000 Hi Xihua, > I think we may catch the solution from rfc4201 and = draft-ietf-mpls-explicit-resource-control-bundle-08 for bandwidth.=20 > For latency, thert is a description about it in = draft-wang-ccamp-latency-te-metric-02. There may be two choice .=20 > 1. "When the composite link is advertised into IGP, the latency of = composite link should be the range (e.g., at least minimum and maximum) = latency value of all component links." - comment from Dave=20 > 2. " When the composite link is advertised into IGP, the latency of = composite link should be the maximum latency value of all component = links."=20 Yes, these possible solutions fall into the variations where you = transmit only partial information in the IGP. In these cases, the = head-end has insufficient information to determine whether a particular = path can support its bandwidth, delay, and jitter requirements. Again, = this leads to crankback. Tony From fu.xihua@zte.com.cn Wed Feb 23 12:33:30 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A43F3A6A39; Wed, 23 Feb 2011 12:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.961 X-Spam-Level: X-Spam-Status: No, score=-95.961 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 YaTPAAuVGYEg; Wed, 23 Feb 2011 12:33:29 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 8FD9C3A6877; Wed, 23 Feb 2011 12:33:27 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35103898117248; Thu, 24 Feb 2011 04:32:03 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 23516.5422451558; Thu, 24 Feb 2011 04:25:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1NKY8dk044506; Thu, 24 Feb 2011 04:34:08 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) In-Reply-To: To: Tony Li Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Thu, 24 Feb 2011 04:34:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-24 04:34:07, Serialize complete at 2011-02-24 04:34:07 Content-Type: multipart/alternative; boundary="=_alternative 0070FD3C48257840_=" X-MAIL: mse01.zte.com.cn p1NKY8dk044506 Cc: rtgwg-bounces@ietf.org, "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, 23 Feb 2011 20:33:30 -0000 This is a multipart message in MIME format. --=_alternative 0070FD3C48257840_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgVG9ueSwNCg0KWW91IGNhbiBjYXJyeSBzb21lIGluZm9ybWF0aW9uIHdoaWNoIGlzIHVzZWQg Zm9yIHRoZSBjb21wb25lbnQgc2VsZWN0aW9uIA0KZHVyaW5nIHRoZSBzaWduYWxpbmcuDQoNClhp aHVhIEZ1DQoNCg0KDQoNClRvbnkgTGkgPHRvbnkubGlAdG9ueS5saT4gDQoyMDExLTAyLTI0IMnP zucgMDM6MTENCg0KytW8/sjLDQpmdS54aWh1YUB6dGUuY29tLmNuDQqzrcvNDQpMdWN5IHlvbmcg PGx1Y3kueW9uZ0BodWF3ZWkuY29tPiwgInJ0Z3dnQGlldGYub3JnIiA8cnRnd2dAaWV0Zi5vcmc+ LCANCnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmcNCtb3zOINClJlOiBXR0xDIGNvbXBsZXRlZCBvbiBk cmFmdC1pZXRmLXJ0Z3dnLWNsLXJlcXVpcmVtZW50LTAzDQoNCg0KDQoNCg0KDQoNCkhpIFhpaHVh LA0KDQo+IEkgdGhpbmsgd2UgbWF5IGNhdGNoIHRoZSBzb2x1dGlvbiBmcm9tIHJmYzQyMDEgYW5k IA0KZHJhZnQtaWV0Zi1tcGxzLWV4cGxpY2l0LXJlc291cmNlLWNvbnRyb2wtYnVuZGxlLTA4IGZv ciBiYW5kd2lkdGguIA0KPiBGb3IgbGF0ZW5jeSwgdGhlcnQgaXMgYSBkZXNjcmlwdGlvbiBhYm91 dCBpdCBpbiANCmRyYWZ0LXdhbmctY2NhbXAtbGF0ZW5jeS10ZS1tZXRyaWMtMDIuIFRoZXJlIG1h eSBiZSB0d28gY2hvaWNlIC4gDQo+IDEuICJXaGVuIHRoZSBjb21wb3NpdGUgbGluayBpcyBhZHZl cnRpc2VkIGludG8gSUdQLCB0aGUgbGF0ZW5jeSBvZiANCmNvbXBvc2l0ZSBsaW5rIHNob3VsZCBi ZSB0aGUgcmFuZ2UgKGUuZy4sIGF0IGxlYXN0IG1pbmltdW0gYW5kIG1heGltdW0pIA0KbGF0ZW5j eSB2YWx1ZSBvZiBhbGwgY29tcG9uZW50IGxpbmtzLiIgLSBjb21tZW50IGZyb20gRGF2ZSANCj4g Mi4gIiBXaGVuIHRoZSBjb21wb3NpdGUgbGluayBpcyBhZHZlcnRpc2VkIGludG8gSUdQLCB0aGUg bGF0ZW5jeSBvZiANCmNvbXBvc2l0ZSBsaW5rIHNob3VsZCBiZSB0aGUgbWF4aW11bSBsYXRlbmN5 IHZhbHVlIG9mIGFsbCBjb21wb25lbnQgDQpsaW5rcy4iIA0KDQoNClllcywgdGhlc2UgcG9zc2li bGUgc29sdXRpb25zIGZhbGwgaW50byB0aGUgdmFyaWF0aW9ucyB3aGVyZSB5b3UgdHJhbnNtaXQg DQpvbmx5IHBhcnRpYWwgaW5mb3JtYXRpb24gaW4gdGhlIElHUC4gIEluIHRoZXNlIGNhc2VzLCB0 aGUgaGVhZC1lbmQgaGFzIA0KaW5zdWZmaWNpZW50IGluZm9ybWF0aW9uIHRvIGRldGVybWluZSB3 aGV0aGVyIGEgcGFydGljdWxhciBwYXRoIGNhbiANCnN1cHBvcnQgaXRzIGJhbmR3aWR0aCwgZGVs YXksIGFuZCBqaXR0ZXIgcmVxdWlyZW1lbnRzLiAgQWdhaW4sIHRoaXMgbGVhZHMgDQp0byBjcmFu a2JhY2suDQoNClRvbnkNCg0KDQoNCg0K --=_alternative 0070FD3C48257840_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFRvbnksPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Zb3UgY2FuIGNhcnJ5IHNvbWUg aW5mb3JtYXRpb24gd2hpY2gNCmlzIHVzZWQgZm9yIHRoZSBjb21wb25lbnQgc2VsZWN0aW9uIGR1 cmluZyB0aGUgc2lnbmFsaW5nLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+WGlodWEgRnU8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+VG9ueSBMaSAmbHQ7dG9ueS5saUB0b255LmxpJmd0Ozwv Yj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTAyLTI0 IMnPzucgMDM6MTE8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+ZnUueGlodWFAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63L zTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+THVjeSB5 b25nICZsdDtsdWN5LnlvbmdAaHVhd2VpLmNvbSZndDssDQomcXVvdDtydGd3Z0BpZXRmLm9yZyZx dW90OyAmbHQ7cnRnd2dAaWV0Zi5vcmcmZ3Q7LCBydGd3Zy1ib3VuY2VzQGlldGYub3JnPC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5SZTogV0dMQyBjb21wbGV0ZWQgb24gZHJhZnQtaWV0Zi1ydGd3Zy1jbC1y ZXF1aXJlbWVudC0wMzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxm b250IHNpemU9Mj48dHQ+PGJyPg0KSGkgWGlodWEsPGJyPg0KPGJyPg0KJmd0OyBJIHRoaW5rIHdl IG1heSBjYXRjaCB0aGUgc29sdXRpb24gZnJvbSByZmM0MjAxIGFuZCBkcmFmdC1pZXRmLW1wbHMt ZXhwbGljaXQtcmVzb3VyY2UtY29udHJvbC1idW5kbGUtMDgNCmZvciBiYW5kd2lkdGguIDxicj4N CiZndDsgRm9yIGxhdGVuY3ksIHRoZXJ0IGlzIGEgZGVzY3JpcHRpb24gYWJvdXQgaXQgaW4gZHJh ZnQtd2FuZy1jY2FtcC1sYXRlbmN5LXRlLW1ldHJpYy0wMi4NClRoZXJlIG1heSBiZSB0d28gY2hv aWNlIC4gPGJyPg0KJmd0OyAxLiAmcXVvdDtXaGVuIHRoZSBjb21wb3NpdGUgbGluayBpcyBhZHZl cnRpc2VkIGludG8gSUdQLCB0aGUgbGF0ZW5jeQ0Kb2YgY29tcG9zaXRlIGxpbmsgc2hvdWxkIGJl IHRoZSByYW5nZSAoZS5nLiwgYXQgbGVhc3QgbWluaW11bSBhbmQgbWF4aW11bSkNCmxhdGVuY3kg dmFsdWUgb2YgYWxsIGNvbXBvbmVudCBsaW5rcy4mcXVvdDsgLSBjb21tZW50IGZyb20gRGF2ZSA8 YnI+DQomZ3Q7IDIuICZxdW90OyBXaGVuIHRoZSBjb21wb3NpdGUgbGluayBpcyBhZHZlcnRpc2Vk IGludG8gSUdQLCB0aGUgbGF0ZW5jeQ0Kb2YgY29tcG9zaXRlIGxpbmsgc2hvdWxkIGJlIHRoZSBt YXhpbXVtIGxhdGVuY3kgdmFsdWUgb2YgYWxsIGNvbXBvbmVudA0KbGlua3MuJnF1b3Q7IDxicj4N Cjxicj4NCjxicj4NClllcywgdGhlc2UgcG9zc2libGUgc29sdXRpb25zIGZhbGwgaW50byB0aGUg dmFyaWF0aW9ucyB3aGVyZSB5b3UgdHJhbnNtaXQNCm9ubHkgcGFydGlhbCBpbmZvcm1hdGlvbiBp biB0aGUgSUdQLiAmbmJzcDtJbiB0aGVzZSBjYXNlcywgdGhlIGhlYWQtZW5kDQpoYXMgaW5zdWZm aWNpZW50IGluZm9ybWF0aW9uIHRvIGRldGVybWluZSB3aGV0aGVyIGEgcGFydGljdWxhciBwYXRo IGNhbg0Kc3VwcG9ydCBpdHMgYmFuZHdpZHRoLCBkZWxheSwgYW5kIGppdHRlciByZXF1aXJlbWVu dHMuICZuYnNwO0FnYWluLCB0aGlzDQpsZWFkcyB0byBjcmFua2JhY2suPGJyPg0KPGJyPg0KVG9u eTxicj4NCjxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K --=_alternative 0070FD3C48257840_=-- From tony.li@tony.li Wed Feb 23 12:41:47 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26FBB3A6877 for ; Wed, 23 Feb 2011 12:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 xe7DUZG7xOZs for ; Wed, 23 Feb 2011 12:41:46 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 57D763A688E for ; Wed, 23 Feb 2011 12:41:46 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id BXlY1g00B1ei1Bg53YiaGE; Wed, 23 Feb 2011 20:42:34 +0000 Received: from dhcp-171-70-245-59.cisco.com ([171.70.245.59]) by omta24.westchester.pa.mail.comcast.net with comcast id BYiH1g0051Hd52b3kYiMtW; Wed, 23 Feb 2011 20:42:32 +0000 Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Wed, 23 Feb 2011 12:42:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: fu.xihua@zte.com.cn X-Mailer: Apple Mail (2.1082) Cc: rtgwg-bounces@ietf.org, "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, 23 Feb 2011 20:41:47 -0000 On Feb 23, 2011, at 12:34 PM, fu.xihua@zte.com.cn wrote: > You can carry some information which is used for the component = selection during the signaling.=20 Hi Xihua, Yes, you can. However, there is the significant possibility that there = is no appropriate component that has the requisite bandwidth, latency, = and jitter. In which case, you get rejected at signaling time. You = can then hunt around for a path as part of signaling, or you can have = the head-end recompute, effectively doing a depth-first search on the = topology. Neither of these are as effective as having full information = at the head-end to start with. It should be noted that we had very similar choices when we did TE in = the first place. We chose to advertise link information, including = bandwidth and policy in the IGP to address this. Regards, Tony From curtis@occnc.com Wed Feb 23 15:46:24 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDC343A697C for ; Wed, 23 Feb 2011 15:46:24 -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 LgI6UWuPeZQp for ; Wed, 23 Feb 2011 15:46:24 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id D1CE73A694E for ; Wed, 23 Feb 2011 15:46:23 -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 p1NNl5gn076554; Wed, 23 Feb 2011 18:47:05 -0500 (EST) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201102232347.p1NNl5gn076554@harbor.orleans.occnc.com> To: Lucy yong From: Curtis Villamizar Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 In-reply-to: Your message of "Wed, 23 Feb 2011 15:31:22 GMT." <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> Date: Wed, 23 Feb 2011 18:47:05 -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: Wed, 23 Feb 2011 23:46:25 -0000 In message <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> Lucy yong writes: > > [LY] IMO: when the router of a composite link does not explicitly > announce all of its component links, the solution should also allow > singling a bidirectional LSP w/ an indication whether it has to be > placed on the same component link in both direction or not. Lucy, Catching up on email. mpls-tp-multipath (which expired end of Dec but will be reneewed shortly) points this out in the context of MPLS-TP LSP. If MPLS-TP LSP (or CL LSP with the same requirement) is carried in an MPLS LSP that due to its capacity must use a hash based (or equiv) multipath technique, then there also needs to be signaling to indicate that the hash for the containing LSP must be limited to two labels. More generally any LSP limited to N label hash depth limits the containing LSP to N+1 label hash depth. For example, a 1Tb/s MPLS LSP and a 50Gb/s MPLS-TP LSP can be carried on the same 11 x 100G multipath as long as the hash depth determined after the label lookup. If a corouted bidirectional LSP must take the same component in both directions or a link bundle, not just the same link bundle (aka same multipath) then it should request a specific component. This is slightly different from indicating that it can take any single component (the MPLS-TP requirement needed for LM OAM and other OAM fate sharing), but doesn't care which one. CL adds the constraint that it must take any compoennt matching some additional criteria (such as a delay criteria). The criteria that any component can be selected as long as it is the same component in both directions also pins the LSP, just as specifying a specific component would pin the LSP today. We really should sort all of this out in the framework draft. These are really more detailed requirements than the requirements thatmade it to cl-requirements but it is better that cl-requirements is moving forward and documenting what we do already agree on. Curtis From lucy.yong@huawei.com Wed Feb 23 15:47:50 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502A53A697F for ; Wed, 23 Feb 2011 15:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 wblaM23pMD1t for ; Wed, 23 Feb 2011 15:47:49 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 781623A697D for ; Wed, 23 Feb 2011 15:47:49 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH300L0OGT028@usaga02-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 15:48:36 -0800 (PST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LH300G1HGT01H@usaga02-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 15:48:36 -0800 (PST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Feb 2011 15:48:37 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 23 Feb 2011 15:48:35 -0800 Date: Wed, 23 Feb 2011 23:48:35 +0000 From: Lucy yong Subject: RE: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 In-reply-to: <84CA327B-1101-4C35-93C3-95B40209CBB9@tony.li> X-Originating-IP: [10.47.131.237] To: Tony Li Message-id: <2691CE0099834E4A9C5044EEC662BB9D2ABA91@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-index: AcvTYWuhy7IyJ+0ElkiIdCJYu4kkfgAFBkOxAAOHT24AAWfS1AAIdNuw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> <9CE0B40C-1EA4-41D2-98C0-B8007F45905E@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2AB958@DFWEML501-MBX.china.huawei.com> <710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2AB9A9@DFWEML501-MBX.china.huawei.com> <84CA327B-1101-4C35-93C3-95B40209CBB9@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, 23 Feb 2011 23:47:50 -0000 > It can, but at a very high cost. If the IGP doesn't carry full > information, then you end up being unable to compute successful paths, > even in a stable topology. You end up using crankback for path > computation. We discussed this in Anaheim and Beijing. [LY] When one of component links fails, the compositel link can announce its available capacity to be zero while performing local recovery. When it finishes the recovery process, it can announce its available capabity again to reflect the true available capacity. Will this can prevent crankback issue? Lucy From curtis@occnc.com Wed Feb 23 15:53:13 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112703A694E for ; Wed, 23 Feb 2011 15:53:13 -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 46ibWDfqdAFI for ; Wed, 23 Feb 2011 15:53:12 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 158EB3A692B for ; Wed, 23 Feb 2011 15:53:11 -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 p1NNrmfR076596; Wed, 23 Feb 2011 18:53:48 -0500 (EST) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201102232353.p1NNrmfR076596@harbor.orleans.occnc.com> To: Tony Li From: Curtis Villamizar Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 In-reply-to: Your message of "Wed, 23 Feb 2011 09:59:59 PST." <710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@tony.li> Date: Wed, 23 Feb 2011 18:53:48 -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: Wed, 23 Feb 2011 23:53:13 -0000 In message <710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@tony.li> Tony Li writes: > > If anyone has discovered a way to break the Shannon limit and transmit > more information without more signal, please step forward now. ;-) Outlawing microsoft applications would improve the S/N ration as measured in information per bit but less so (still somewhat) in information per distraction (spurious font changes, font size changes, color changes, placement, etc). Then there is this sort of noise - nonsensical remarks. So it depends which sort of S/N you want optimized. Or did you mean IGP S/N, not mailing list S/N? :-) Curtis From tony.li@tony.li Wed Feb 23 15:57:48 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE763A692B for ; Wed, 23 Feb 2011 15:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 2++dqk0ij4xq for ; Wed, 23 Feb 2011 15:57:47 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id ECB643A6879 for ; Wed, 23 Feb 2011 15:57:46 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id Bbep1g00227AodY53bybuR; Wed, 23 Feb 2011 23:58:35 +0000 Received: from dhcp-171-70-245-59.cisco.com ([171.70.245.59]) by omta19.westchester.pa.mail.comcast.net with comcast id BbyJ1g00p1Hd52b3fbyNv1; Wed, 23 Feb 2011 23:58:33 +0000 Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D2ABA91@DFWEML501-MBX.china.huawei.com> Date: Wed, 23 Feb 2011 15:58:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <72E75080-8A37-40A6-8E04-81DA2B15AB53@tony.li> References: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> <9CE0B40C-1EA4-41D2-98C0-B8007F45905E@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2AB958@DFWEML501-MBX.china.huawei.com> <710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2AB9A9@DFWEML501-MBX.china.huawei.com> <84CA327B-1101-4C35-93C3-95B40209CBB9@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2ABA91@DFWEML501-MBX.china.huawei.com> To: Lucy yong X-Mailer: Apple Mail (2.1082) 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, 23 Feb 2011 23:57:48 -0000 On Feb 23, 2011, at 3:48 PM, Lucy yong wrote: > [LY] When one of component links fails, the compositel link can = announce its available capacity to be zero while performing local = recovery. When it finishes the recovery process, it can announce its = available capabity again to reflect the true available capacity. Will = this can prevent crankback issue? Hi Lucy, No. To prevent crankback, remote systems need to know the available = capacity and properties for a component. Again as an example, imagine that you have a 100Gb link, but it has a = latency of 300ms. Another component has a capacity of 1Gb, but with a = latency of 1ms. The composite link now might be advertised with a capacity of 101Gb, and = a latency range of 1-300ms. What do you do with a path that requires 10Gb and a latency of 10ms? To = the head end, this composite link looks useable. Tony From lucy.yong@huawei.com Wed Feb 23 16:04:14 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8213A692B for ; Wed, 23 Feb 2011 16:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.272 X-Spam-Level: X-Spam-Status: No, score=-6.272 tagged_above=-999 required=5 tests=[AWL=0.327, 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 yGk19dl55FqS for ; Wed, 23 Feb 2011 16:04:14 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 131103A692A for ; Wed, 23 Feb 2011 16:04:14 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH300LDQHKE28@usaga02-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 16:05:02 -0800 (PST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LH300GBSHKD1H@usaga02-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 16:05:02 -0800 (PST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Feb 2011 16:05:03 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 23 Feb 2011 16:05:01 -0800 Date: Thu, 24 Feb 2011 00:05:00 +0000 From: Lucy yong Subject: RE: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 In-reply-to: <72E75080-8A37-40A6-8E04-81DA2B15AB53@tony.li> X-Originating-IP: [10.47.131.237] To: Tony Li Message-id: <2691CE0099834E4A9C5044EEC662BB9D2ABACB@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-index: AcvTYWuhy7IyJ+0ElkiIdCJYu4kkfgAFBkOxABANT9IAABJ1IA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> <9CE0B40C-1EA4-41D2-98C0-B8007F45905E@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2AB958@DFWEML501-MBX.china.huawei.com> <710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2AB9A9@DFWEML501-MBX.china.huawei.com> <84CA327B-1101-4C35-93C3-95B40209CBB9@tony.li> <2691CE0099834E4A9C5044EEC662BB9D2ABA91@DFWEML501-MBX.china.huawei.com> <72E75080-8A37-40A6-8E04-81DA2B15AB53@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: Thu, 24 Feb 2011 00:04:15 -0000 > > No. To prevent crankback, remote systems need to know the available > capacity and properties for a component. > > Again as an example, imagine that you have a 100Gb link, but it has a > latency of 300ms. Another component has a capacity of 1Gb, but with a > latency of 1ms. > > The composite link now might be advertised with a capacity of 101Gb, and a > latency range of 1-300ms. > > What do you do with a path that requires 10Gb and a latency of 10ms? To > the head end, this composite link looks useable. > [LY] Composite link should not advertise in this way. Furthermore, I don't know if this is a useful case for operator. Lucy From lucy.yong@huawei.com Wed Feb 23 16:28:53 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918313A6911 for ; Wed, 23 Feb 2011 16:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdZzImq0USs6 for ; Wed, 23 Feb 2011 16:28:52 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 5F8043A659A for ; Wed, 23 Feb 2011 16:28:52 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH300E8AIPE20@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 18:29:39 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LH3006SWIPD85@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 23 Feb 2011 18:29:38 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Feb 2011 16:29:38 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 23 Feb 2011 16:29:36 -0800 Date: Thu, 24 Feb 2011 00:29:36 +0000 From: Lucy yong Subject: RE: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 In-reply-to: <201102232347.p1NNl5gn076554@harbor.orleans.occnc.com> X-Originating-IP: [10.47.131.237] To: "curtis@occnc.com" Message-id: <2691CE0099834E4A9C5044EEC662BB9D2ABAF2@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-index: AQHL07P5SMp2qwQzdkWcd47ASqnqK5QPyx8g X-MS-Has-Attach: X-MS-TNEF-Correlator: References: "Your message of Wed, 23 Feb 2011 15:31:22 GMT." <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> <201102232347.p1NNl5gn076554@harbor.orleans.occnc.com> Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:28:53 -0000 Curtis, I agree. The framework draft can state this more clearly. The requirement draft need to move forward. Lucy > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Wednesday, February 23, 2011 5:47 PM > To: Lucy yong > Cc: rtgwg@ietf.org > Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 > > > In message <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501- > MBX.china.huawei.com> > Lucy yong writes: > > > > [LY] IMO: when the router of a composite link does not explicitly > > announce all of its component links, the solution should also allow > > singling a bidirectional LSP w/ an indication whether it has to be > > placed on the same component link in both direction or not. > > > Lucy, > > Catching up on email. > > mpls-tp-multipath (which expired end of Dec but will be reneewed > shortly) points this out in the context of MPLS-TP LSP. If MPLS-TP > LSP (or CL LSP with the same requirement) is carried in an MPLS LSP > that due to its capacity must use a hash based (or equiv) multipath > technique, then there also needs to be signaling to indicate that the > hash for the containing LSP must be limited to two labels. More > generally any LSP limited to N label hash depth limits the containing > LSP to N+1 label hash depth. > > For example, a 1Tb/s MPLS LSP and a 50Gb/s MPLS-TP LSP can be carried > on the same 11 x 100G multipath as long as the hash depth determined > after the label lookup. > > If a corouted bidirectional LSP must take the same component in both > directions or a link bundle, not just the same link bundle (aka same > multipath) then it should request a specific component. This is > slightly different from indicating that it can take any single > component (the MPLS-TP requirement needed for LM OAM and other OAM > fate sharing), but doesn't care which one. CL adds the constraint > that it must take any compoennt matching some additional criteria > (such as a delay criteria). > > The criteria that any component can be selected as long as it is the > same component in both directions also pins the LSP, just as > specifying a specific component would pin the LSP today. > > We really should sort all of this out in the framework draft. These > are really more detailed requirements than the requirements thatmade > it to cl-requirements but it is better that cl-requirements is moving > forward and documenting what we do already agree on. > > Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From albert.e.manfredi@boeing.com Wed Feb 23 16:54:56 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544463A693F for ; Wed, 23 Feb 2011 16:54:56 -0800 (PST) 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 WIc0JaNIvdOt for ; Wed, 23 Feb 2011 16:54:55 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 8A0A23A691B for ; Wed, 23 Feb 2011 16:54:55 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1O0teLZ025708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Feb 2011 16:55:41 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1O0tew0003942; Wed, 23 Feb 2011 18:55:40 -0600 (CST) Received: from XCH-MWHT-01.mw.nos.boeing.com (xch-mwht-01.mw.nos.boeing.com [134.57.113.35]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1O0te2K003935 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 23 Feb 2011 18:55:40 -0600 (CST) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-01.mw.nos.boeing.com ([134.57.113.35]) with mapi; Wed, 23 Feb 2011 18:55:40 -0600 From: "Manfredi, Albert E" To: Tony Li Date: Wed, 23 Feb 2011 18:55:34 -0600 Subject: RE: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-Topic: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-Index: AcvTtPQH407monh0RDCwXfSaV7eTbAABlW6Q Message-ID: References: Your message of "Wed, 23 Feb 2011 09:59:59 PST."<710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@tony.li> <201102232353.p1NNrmfR076596@harbor.orleans.occnc.com> In-Reply-To: <201102232353.p1NNrmfR076596@harbor.orleans.occnc.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: Thu, 24 Feb 2011 00:54:56 -0000 In message <710ABE44-A4DF-4695-AAF0-6A7738F9E7A5@tony.li> Tony Li writes: > =20 > If anyone has discovered a way to break the Shannon limit and transmit > more information without more signal, please step forward now. ;-) Oddly, this effect can be achieved, using a similar aggregation technique a= s discussed in this thread. Over a given RF channel. It's called MIMO (mult= iple in multiple out). You can easily exceed the Shannon limit in b/s/Hz, f= or that RF channel, by exploiting the multiple propagation paths. Most effe= ctive in a rayleigh channel (RF propagation channel where there are no domi= nant paths). A basic criterion of MIMO is that the total transmitted power = can be no greater than if you used a single transmit antenna. Perhaps a cabled analogy would be to exploit the different dispersion modes= in a multimode fiber. Transmit different information on each one, then hav= e clever processing at the receiver that decorrelates each of the separate = transmissions. Another similarity being, the effect becomes range-limited i= n practice, both for radio and in fiber. Bert From akatlas@gmail.com Wed Feb 23 17:03:03 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F160B3A69A2 for ; Wed, 23 Feb 2011 17:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVNDh5SOdqVT for ; Wed, 23 Feb 2011 17:03:02 -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 327F23A6997 for ; Wed, 23 Feb 2011 17:03:02 -0800 (PST) Received: by qwh6 with SMTP id 6so39673qwh.31 for ; Wed, 23 Feb 2011 17:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tCX+z57hEI5h4dCi1ji+jvOFxX5vNzZtthbOZWhsvig=; b=C5ZWHMJSDPl2Wt+Lw2RVqsbGH56xKN38DoJpz+YsjRjHuM+dWlbvtzgmulj82MF7tc uWb4L0aNjvVsc24ag4lrlF00B0xw87ZSDO6aaN3G2DGWxsCmkkONPkJ+O1BMylzbrCdp LK6SvBp3CKtKSmTTQy1o51bJCzBpOkPVpi3lQ= 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=oL7NN2LkG7f3Hny/qNvSyAHvw6KMjMKQy5SjDgZ0gchXEodwf1ysWW/gbgpKu6nxaJ ID4DtRyBgCwfi3ESR+/2qWmxvDIhUJxVT7R+3fyiTOH8DRABkAXUhIEIE5rbsYEhBqa6 nSk9YDlEuHEZzetwxHdYXOovxpEM2A/HxUAf8= MIME-Version: 1.0 Received: by 10.229.81.12 with SMTP id v12mr100840qck.132.1298509430172; Wed, 23 Feb 2011 17:03:50 -0800 (PST) Received: by 10.229.89.11 with HTTP; Wed, 23 Feb 2011 17:03:50 -0800 (PST) In-Reply-To: <201102232347.p1NNl5gn076554@harbor.orleans.occnc.com> References: <2691CE0099834E4A9C5044EEC662BB9D2AB894@DFWEML501-MBX.china.huawei.com> <201102232347.p1NNl5gn076554@harbor.orleans.occnc.com> Date: Wed, 23 Feb 2011 20:03:50 -0500 Message-ID: Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 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: Thu, 24 Feb 2011 01:03:03 -0000 On Wed, Feb 23, 2011 at 6:47 PM, Curtis Villamizar wrote= : > We really should sort all of this out in the framework draft. =A0These > are really more detailed requirements than the requirements thatmade > it to cl-requirements but it is better that cl-requirements is moving > forward and documenting what we do already agree on. > > Curtis > I would certainly welcome more detail and consideration of issues in the framework draft. Alia From curtis@occnc.com Thu Feb 24 15:24:15 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5612F3A680D for ; Thu, 24 Feb 2011 15:24:15 -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=[AWL=0.000, 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 65-Sta4Iu6lG for ; Thu, 24 Feb 2011 15:24:14 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 5F9D43A6876 for ; Thu, 24 Feb 2011 15:24:14 -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 p1ONOrUP016829; Thu, 24 Feb 2011 18:24:53 -0500 (EST) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201102242324.p1ONOrUP016829@harbor.orleans.occnc.com> To: Tony Li From: Curtis Villamizar Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 In-reply-to: Your message of "Wed, 23 Feb 2011 15:58:16 PST." <72E75080-8A37-40A6-8E04-81DA2B15AB53@tony.li> Date: Thu, 24 Feb 2011 18:24:53 -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, 24 Feb 2011 23:24:15 -0000 In message <72E75080-8A37-40A6-8E04-81DA2B15AB53@tony.li> Tony Li writes: > > > On Feb 23, 2011, at 3:48 PM, Lucy yong wrote: > > > [LY] When one of component links fails, the compositel link can > announce its available capacity to be zero while performing local > recovery. When it finishes the recovery process, it can announce its > available capabity again to reflect the true available > capacity. Will this can prevent crankback issue? > > > Hi Lucy, > > No. To prevent crankback, remote systems need to know the available > capacity and properties for a component. > > Again as an example, imagine that you have a 100Gb link, but it has a > latency of 300ms. Another component has a capacity of 1Gb, but with a > latency of 1ms. > > The composite link now might be advertised with a capacity of 101Gb, > and a latency range of 1-300ms. > > What do you do with a path that requires 10Gb and a latency of 10ms? > To the head end, this composite link looks useable. > > Tony Tony, If there are a large number of components with identical properties, then the IGP needs to indicate that how many components exist with a given set of properties. In some cases, it may not be necessary to enumberate each component. I suggest that we go down a path which allows the following options: 1. list existing min-bw, max-bw summary with attached extended attributes per aggregate, with no other information. 2. add to #1, for all or a subset of components a sub-aggregation that is characterized by min-bw, max-bw and attached extended attributes, 3. add to #1 or #1 plus #2, advertisements for individual components. #1 is just extended attributes added to link bundle. #2 and #3 are sub-tlvs added to the link bundle. ... assuming we extend link bundle, for example. Curtis From tony.li@tony.li Thu Feb 24 15:30:08 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751D63A680D for ; Thu, 24 Feb 2011 15:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih6fnZw5+wTs for ; Thu, 24 Feb 2011 15:30:07 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id AACD93A6808 for ; Thu, 24 Feb 2011 15:30:07 -0800 (PST) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta12.emeryville.ca.mail.comcast.net with comcast id BzWP1g00B1vN32cACzWy9v; Thu, 24 Feb 2011 23:30:58 +0000 Received: from [10.154.17.120] ([128.107.239.233]) by omta22.emeryville.ca.mail.comcast.net with comcast id BzWd1g00u52qHCY8izWhyg; Thu, 24 Feb 2011 23:30:51 +0000 Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <201102242324.p1ONOrUP016829@harbor.orleans.occnc.com> Date: Thu, 24 Feb 2011 15:30:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201102242324.p1ONOrUP016829@harbor.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1082) Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 23:30:08 -0000 On Feb 24, 2011, at 3:24 PM, Curtis Villamizar wrote: > If there are a large number of components with identical properties, > then the IGP needs to indicate that how many components exist with a > given set of properties. In some cases, it may not be necessary to > enumberate each component. Hi Curtis, I'm perfectly happy with any encoding tricks that folks may propose that = will allow further aggregation in the cases where doing do does not lose = significant information. I look forward to concrete proposals. Regards, Tony From lucy.yong@huawei.com Thu Feb 24 16:33:35 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF0F3A68B1 for ; Thu, 24 Feb 2011 16:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 L3VqMP7tvNoq for ; Thu, 24 Feb 2011 16:33:34 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id B492E3A68B9 for ; Thu, 24 Feb 2011 16:33:34 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH500BMPDLB9H@usaga02-in.huawei.com> for rtgwg@ietf.org; Thu, 24 Feb 2011 16:34:24 -0800 (PST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LH5000SPDLBNR@usaga02-in.huawei.com> for rtgwg@ietf.org; Thu, 24 Feb 2011 16:34:23 -0800 (PST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 24 Feb 2011 16:34:25 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Thu, 24 Feb 2011 16:34:23 -0800 Date: Fri, 25 Feb 2011 00:34:22 +0000 From: Lucy yong Subject: RE: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 In-reply-to: <201102242324.p1ONOrUP016829@harbor.orleans.occnc.com> X-Originating-IP: [10.47.140.250] To: "curtis@occnc.com" , Tony Li Message-id: <2691CE0099834E4A9C5044EEC662BB9D2ABE9F@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: WGLC completed on draft-ietf-rtgwg-cl-requirement-03 Thread-index: AQHL1HoKSMp2qwQzdkWcd47ASqnqK5QRWkPg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: "Your message of Wed, 23 Feb 2011 15:58:16 PST." <72E75080-8A37-40A6-8E04-81DA2B15AB53@tony.li> <201102242324.p1ONOrUP016829@harbor.orleans.occnc.com> Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 00:33:35 -0000 Hi Curtis, > I suggest that we go down a path which allows the following options: > > 1. list existing min-bw, max-bw summary with attached extended > attributes per aggregate, with no other information. [LY] Does "min-bw" mean the largest LSP that composite link can take? If yes, I agree this is the right direction. > > 2. add to #1, for all or a subset of components a sub-aggregation > that is characterized by min-bw, max-bw and attached extended > attributes, [LY] Yes, we had this in mind. In addition, it is valuable to allow a composite link containing some component links that just use recovery purpose so their BW does not need to be advertised. A good example is that when a composite link contains a 10G component link with 30ms transmission delay and 1G component link with 500ms transmission delay. The composite link can just advertise 10BW with 30ms. 1G link can be used for recovery purpose. This gives operator flexibility to use the composite link. This does not require protocol changes, just need to describe the usage. > > 3. add to #1 or #1 plus #2, advertisements for individual > components. > > #1 is just extended attributes added to link bundle. #2 and #3 are > sub-tlvs added to the link bundle. > [LY] Agree. Lucy