From Internet-Drafts@ietf.org Mon Jan 10 07:00:06 2011 Return-Path: X-Original-To: rtgwg@core3.amsl.com Delivered-To: rtgwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14CD3A69C5; Mon, 10 Jan 2011 07:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 FSyBn0KTvnvz; Mon, 10 Jan 2011 07:00:05 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EC528C113; Mon, 10 Jan 2011 07:00:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-rtgwg-cl-requirement-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110150003.25108.41544.idtracker@localhost> Date: Mon, 10 Jan 2011 07:00:03 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:00:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : Requirements for MPLS Over a Composite Link Author(s) : C. Villamizar, et al. Filename : draft-ietf-rtgwg-cl-requirement-03.txt Pages : 20 Date : 2011-01-10 There is often a need to provide large aggregates of bandwidth that are best provided using parallel links between routers or MPLS LSR. In core networks there is often no alternative since the aggregate capacities of core networks today far exceed the capacity of a single physical link or single packet processing element. The presence of parallel links, with each link potentially comprised of multiple layers has resulted in additional requirements. Certain services may benefit from being restricted to a subset of the component links or a specific component link, where component link characteristics, such as latency, differ. Certain services require that an LSP be treated as atomic and avoid reordering. Other services will continue to require only that reordering not occur within a microflow as is current practice. Current practice related to multipath is described briefly in an appendix. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-cl-requirement-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-rtgwg-cl-requirement-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-10065702.I-D@ietf.org> --NextPart-- From dave.mcdysan@verizon.com Mon Jan 10 07:00: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 539833A69C5 for ; Mon, 10 Jan 2011 07:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szYy8DvChtxT for ; Mon, 10 Jan 2011 07:00:45 -0800 (PST) Received: from tpamail4.verizon.com (tpamail4.verizon.com [192.76.82.161]) by core3.amsl.com (Postfix) with ESMTP id EAE853A6975 for ; Mon, 10 Jan 2011 07:00:41 -0800 (PST) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id p0AErRfq004238 for ; Mon, 10 Jan 2011 09:56:45 -0500 (EST) X-AuditID: 8a53433a-b7b57ae0000011e0-c7-4d2b1f9f97c2 Received: from smtptpa4.verizon.com ( [138.83.71.177]) by tpaintrmemf3.verizon.com (EMF) with SMTP id 1B.70.04576.F9F1B2D4; Mon, 10 Jan 2011 10:02:55 -0500 (EST) Received: from FHDP1LUMXC7HB02.us.one.verizon.com (fhdp1lumxc7hb02.verizon.com [166.68.59.189]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id p0AF2snc002519; Mon, 10 Jan 2011 10:02:54 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Mon, 10 Jan 2011 10:02:54 -0500 From: "Mcdysan, David E" To: "So, Ning" , "rtgwg@ietf.org" Date: Mon, 10 Jan 2011 10:02:52 -0500 Subject: Re: Revised text on Component Link Requirement draft Thread-Topic: Revised text on Component Link Requirement draft Thread-Index: Acuw13R3Z2F5Q/G4RESw1eilLkdt4w== 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-Brightmail-Tracker: AAAAAA== X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:00:47 -0000 Hi, I revised the draft to version 03 and submitted it today. As discussed in the Beijing meeting, we are requesting a last call. Thanks, Dave On 12/13/10 10:16 AM, "Mcdysan, David E" wrote: >I recommend that we make two other relatively minor changes to the I-D >with reference to DR#6 and the paragraph following it: > >" DR#6 The Solution SHALL support composite link IGP advertisement > that results in convergence time better than that of > advertising the individual component links. The solution SHALL > be designed so that it represents the range of capabilities of > the individual component links such that functional > requirements are met, and also minimizes the frequency of > advertisement updates which may cause IGP convergence to occur. > > One solution approach is to summarize the characteristics of > the component links in IGP advertisements; however, the intent > > of the above requirement is not to specify the form of a > solution. Examples of advertisement update triggering events > to be considered include: LSP establishment/release, changes in > component link characteristics (e.g., latency, up/down state), > and/or bandwidth utilization." > > > >First, I recommend replacing SHALL with SHOULD in the requirement. It is >desirable for the convergence to be better than what is provided today, >but if FR#1 is met then SHALL is not appropriate. Also, a solution (e.g., >like the one Tony described in Beijing) may not result in (markedly) >faster convergence time. > >Second, I recommend deleting the first sentence of the paragraph following >DR#6=20 > > "One solution approach is to summarize the characteristics of > the component links in IGP advertisements; however, the intent > of the above requirement is not to specify the form of a > solution. " > >Since requirements are not to describe solutions, this sentence is out of >scope. > >Thanks, > >Dave=20 > > > > >On 12/7/10 3:17 PM, "So, Ning" wrote: > >>All, >> >>Here is the updated text based on Tony's input. >> >>New text: FR#1 The solution SHALL provide a means to summarize some >>routing advertisements regarding the characteristics of a composite link >>such that the routing protocol converges within the timeframe needed to >>meet the network performance objective. A composite link CAN be >>announced in conjunction with detailed parameters about its component >>links, such as bandwidth and latency. The composite link SHALL behave as >>a single IGP adjacency. >> >>Regarding Curtis' suggestion about preferred and backup component for >>the adjacency, can we leave it for the solutions' draft? >> >>=20 >>Best regrads, >>=20 >>Ning So >>Network Evolution Planning >>Verizon, Inc. >>(office) 972-729-7905 >>(Cell) 972-955-0914 >>=20 >>-----Original Message----- >>From: Tony Li [mailto:tony.li@tony.li] >>Sent: Saturday, December 04, 2010 11:52 PM >>To: So, Ning >>Cc: rtgwg@ietf.org >>Subject: Re: Revised text on Component Link Requirement draft >> >> >>Hi Ning, >> >>Thanks for the changes. >> >>> Old text: FR#1 The solution SHALL provide a means to summarize >>routing >>> advertisements regarding the characteristics of a composite link such >>> that the routing protocol converges within the timeframe needed to >>meet >>> the network performance objective. >>>=20 >>> New text: FR#1 The solution SHALL provide a means to summarize some >>> routing advertisements regarding the characteristics of a composite >>link >>> such that the routing protocol converges within the timeframe needed >>to >>> meet the network performance objective. Composite link CAN announce >>> each individual component link's bandwidth and latency parameters. >>The >>> composite link SHALL behave as a single IGP adjacency. >> >> >>Looks good. One editorial nit: the second sentence should probably read >>something like: 'A composite link CAN be announced in conjunction with >>detailed parameters about its component links, such as bandwidth and >>latency.' >> >> >>> Since the current draft has already specified component link as >>> point-to-point physical or logical link, I do not see any needs to >>> further clarify that matter although we have discussed that on the >>mail >>> list. =20 >>>=20 >>> Existing text:=20 >>> Component Link: A point-to-point physical or logical link that >>> preserves ordering in the steady state. A component link may have >>> transient out of order events, but such events must not exceed the >>> network's specific NPO. Examples of a physical link are: Lambda, >>> Ethernet PHY, and OTN. Examples of a logical link are: MPLS LSP, >>> Ethernet VLAN, and MPLS-TP LSP. >> >> >>My bad, I was looking at the -01 text. >> >>Tony >> >>_______________________________________________ >>rtgwg mailing list >>rtgwg@ietf.org >>https://www.ietf.org/mailman/listinfo/rtgwg > From ning.so@verizonbusiness.com Mon Jan 17 10:33: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 A102A28C0D7 for ; Mon, 17 Jan 2011 10:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 GPUrkhbU3cCi for ; Mon, 17 Jan 2011 10:33:49 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 252C428C132 for ; Mon, 17 Jan 2011 10:33:48 -0800 (PST) Received: from pdcismtp01.vzbi.com ([unknown] [166.40.77.67]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LF6009H7JON8Q10@firewall.verizonbusiness.com> for rtgwg@ietf.org; Mon, 17 Jan 2011 18:36:23 +0000 (GMT) Received: from pdcismtp01.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LF6001G8JONXR00@pdcismtp01.vzbi.com> for rtgwg@ietf.org; Mon, 17 Jan 2011 18:36:23 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([unknown] [153.39.68.167]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LF6001FLJONT300@pdcismtp01.vzbi.com> for rtgwg@ietf.org; Mon, 17 Jan 2011 18:36:23 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 18:36:22 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Subject: RE: Revised text on Component Link Requirement draft Date: Mon, 17 Jan 2011 18:36:21 +0000 Message-id: <14584D6EE26B314187A4F68BA2060600064CB2C1@ASHEVS008.mcilink.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Revised text on Component Link Requirement draft Thread-index: Acuw13R3Z2F5Q/G4RESw1eilLkdt4wFnckWA References: From: "So, Ning" To: rtgwg@ietf.org X-OriginalArrivalTime: 17 Jan 2011 18:36:22.0773 (UTC) FILETIME=[70A8CA50:01CBB675] 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, 17 Jan 2011 18:33:50 -0000 RTGWG Chairs, It has been a week since the last call of the draft has been requested. Could you please make the last call announcement? =20 =20 Best regrads, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 -----Original Message----- From: Mcdysan, David E [mailto:dave.mcdysan@one.verizon.com]=20 Sent: Monday, January 10, 2011 9:03 AM To: So, Ning; rtgwg@ietf.org Subject: Re: Revised text on Component Link Requirement draft Hi, I revised the draft to version 03 and submitted it today. As discussed in the Beijing meeting, we are requesting a last call. Thanks, Dave On 12/13/10 10:16 AM, "Mcdysan, David E" wrote: >I recommend that we make two other relatively minor changes to the I-D >with reference to DR#6 and the paragraph following it: > >" DR#6 The Solution SHALL support composite link IGP advertisement > that results in convergence time better than that of > advertising the individual component links. The solution SHALL > be designed so that it represents the range of capabilities of > the individual component links such that functional > requirements are met, and also minimizes the frequency of > advertisement updates which may cause IGP convergence to occur. > > One solution approach is to summarize the characteristics of > the component links in IGP advertisements; however, the intent > > of the above requirement is not to specify the form of a > solution. Examples of advertisement update triggering events > to be considered include: LSP establishment/release, changes in > component link characteristics (e.g., latency, up/down state), > and/or bandwidth utilization." > > > >First, I recommend replacing SHALL with SHOULD in the requirement. It is >desirable for the convergence to be better than what is provided today, >but if FR#1 is met then SHALL is not appropriate. Also, a solution (e.g., >like the one Tony described in Beijing) may not result in (markedly) >faster convergence time. > >Second, I recommend deleting the first sentence of the paragraph following >DR#6=20 > > "One solution approach is to summarize the characteristics of > the component links in IGP advertisements; however, the intent > of the above requirement is not to specify the form of a > solution. " > >Since requirements are not to describe solutions, this sentence is out of >scope. > >Thanks, > >Dave=20 > > > > >On 12/7/10 3:17 PM, "So, Ning" wrote: > >>All, >> >>Here is the updated text based on Tony's input. >> >>New text: FR#1 The solution SHALL provide a means to summarize some >>routing advertisements regarding the characteristics of a composite link >>such that the routing protocol converges within the timeframe needed to >>meet the network performance objective. A composite link CAN be >>announced in conjunction with detailed parameters about its component >>links, such as bandwidth and latency. The composite link SHALL behave as >>a single IGP adjacency. >> >>Regarding Curtis' suggestion about preferred and backup component for >>the adjacency, can we leave it for the solutions' draft? >> >>=20 >>Best regrads, >>=20 >>Ning So >>Network Evolution Planning >>Verizon, Inc. >>(office) 972-729-7905 >>(Cell) 972-955-0914 >>=20 >>-----Original Message----- >>From: Tony Li [mailto:tony.li@tony.li] >>Sent: Saturday, December 04, 2010 11:52 PM >>To: So, Ning >>Cc: rtgwg@ietf.org >>Subject: Re: Revised text on Component Link Requirement draft >> >> >>Hi Ning, >> >>Thanks for the changes. >> >>> Old text: FR#1 The solution SHALL provide a means to summarize >>routing >>> advertisements regarding the characteristics of a composite link such >>> that the routing protocol converges within the timeframe needed to >>meet >>> the network performance objective. >>>=20 >>> New text: FR#1 The solution SHALL provide a means to summarize some >>> routing advertisements regarding the characteristics of a composite >>link >>> such that the routing protocol converges within the timeframe needed >>to >>> meet the network performance objective. Composite link CAN announce >>> each individual component link's bandwidth and latency parameters. >>The >>> composite link SHALL behave as a single IGP adjacency. >> >> >>Looks good. One editorial nit: the second sentence should probably read >>something like: 'A composite link CAN be announced in conjunction with >>detailed parameters about its component links, such as bandwidth and >>latency.' >> >> >>> Since the current draft has already specified component link as >>> point-to-point physical or logical link, I do not see any needs to >>> further clarify that matter although we have discussed that on the >>mail >>> list. =20 >>>=20 >>> Existing text:=20 >>> Component Link: A point-to-point physical or logical link that >>> preserves ordering in the steady state. A component link may have >>> transient out of order events, but such events must not exceed the >>> network's specific NPO. Examples of a physical link are: Lambda, >>> Ethernet PHY, and OTN. Examples of a logical link are: MPLS LSP, >>> Ethernet VLAN, and MPLS-TP LSP. >> >> >>My bad, I was looking at the -01 text. >> >>Tony >> >>_______________________________________________ >>rtgwg mailing list >>rtgwg@ietf.org >>https://www.ietf.org/mailman/listinfo/rtgwg > From akatlas@gmail.com Mon Jan 24 17:10:28 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 EEF253A69DF for ; Mon, 24 Jan 2011 17:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 pJlI-qilPej2 for ; Mon, 24 Jan 2011 17:10:28 -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 F32CA3A699F for ; Mon, 24 Jan 2011 17:10:27 -0800 (PST) Received: by fxm9 with SMTP id 9so5129531fxm.31 for ; Mon, 24 Jan 2011 17:13:23 -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=mIQLvwFJQeDhBPByzXFY8h23xqAfxW2RguXVXuK4Tas=; b=W/yf6h26r4fS5f1dz2oR2zMA3eGfpQH1bzdnJ75lPN3CT0w+zY21FIaixuEGa5ueZ6 99/YpQd+pbijQIOCkdYME/M53V5erUMrBr5TrnkdfuXlnKYPfCEWdG8XNo5eVsSdahRG BgRoVA5FP/OHU2Bf1OTcPrwE07DjqU1iQsEfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=B7NAV34JrqjdUl8JP4I92sIhKAOqdxXvKG9VytUsHebfSmJiv2GmZJl5Em9+Lffm15 srUCuU7RZYkAakiwC3+5ENrgou3Tasrg4WkfQFCQdvyOOt7xjqtTKoM4F79BqWPPMpBO wwFGzoU8yi99c50YwWyISO7f3Sr3WQgPu7h1k= MIME-Version: 1.0 Received: by 10.103.249.16 with SMTP id b16mr1942744mus.120.1295918003566; Mon, 24 Jan 2011 17:13:23 -0800 (PST) Received: by 10.103.192.15 with HTTP; Mon, 24 Jan 2011 17:13:23 -0800 (PST) Date: Mon, 24 Jan 2011 20:13:23 -0500 Message-ID: Subject: RTGWG Last Call: 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, 25 Jan 2011 01:10:29 -0000 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 From mark.ietf@gmail.com Thu Jan 27 16:43:27 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 3B8363A6A0C for ; Thu, 27 Jan 2011 16:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=0.618, 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 AQaOZr6xKXqt for ; Thu, 27 Jan 2011 16:43:26 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 6E6A53A6A0E for ; Thu, 27 Jan 2011 16:43:26 -0800 (PST) Received: by qyk34 with SMTP id 34so254266qyk.10 for ; Thu, 27 Jan 2011 16:46:31 -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=H9Ou6upswefhd49IMow1OPbSXDKQyn7YNikR6cU1fro=; b=uj8LBv2NyefbOlyClnkcjjSKjqDBwE9yBnoQrVoDVFgVb2ql0mMFGNL/L3vRE8LIoG Q4eiJAtGn8mYLp5lyWbLt5PQZrVX1qBjI9LMS3v/yuq9vK6Bee8YAJxA1bjoSy+hnzvp llNq50C1u0kfzwTPcv3frgQKn7z8llL6wcjME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=I7pTeUQkSWcj0PuIpxj8ezJTcJIXAOoOVOl/XZpZjuZf9nEWFEd2ucosdd41RSAiMM 6xzbJUdjYt+yZQkHXZcg/deh85TD4oJXydUOtXUG2xlAohUEadCN/8jD+6248uvJzIes x42qVfMrPXWYmYBps4SRbBlCQ0YEL/fMjK2pU= MIME-Version: 1.0 Received: by 10.229.81.11 with SMTP id v11mr337798qck.152.1296175590140; Thu, 27 Jan 2011 16:46:30 -0800 (PST) Received: by 10.229.222.73 with HTTP; Thu, 27 Jan 2011 16:46:30 -0800 (PST) Date: Fri, 28 Jan 2011 06:16:30 +0530 Message-ID: Subject: Doubt regarding the component links 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: Fri, 28 Jan 2011 00:43:27 -0000 Hi, Is it possible to create a composite link which has a physical point-to-point link as one component link and an MPLS LSP as the other component link? Is it also possible to create a composite link that has two different MPLS LSPs, both between the same endpoints, and each taking up a different path, as the component links? Thanks, Mark From tony.li@tony.li Thu Jan 27 16:53: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 C0DF33A6B3E for ; Thu, 27 Jan 2011 16:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 dTDZnd+mFCKV for ; Thu, 27 Jan 2011 16:53:03 -0800 (PST) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id 8448A3A6B3B for ; Thu, 27 Jan 2011 16:53:00 -0800 (PST) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta14.emeryville.ca.mail.comcast.net with comcast id 0oun1g0011bwxycAEow5DF; Fri, 28 Jan 2011 00:56:05 +0000 Received: from dhcp-171-70-245-132.cisco.com ([171.70.245.132]) by omta18.emeryville.ca.mail.comcast.net with comcast id 0ovt1g01W2s79i38eovw8t; Fri, 28 Jan 2011 00:56:02 +0000 Subject: Re: Doubt regarding the component links Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Thu, 27 Jan 2011 16:55:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3A81B14B-C922-45F2-BD82-A39E45BD446E@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: Fri, 28 Jan 2011 00:53:03 -0000 On Jan 27, 2011, at 4:46 PM, mark Brown wrote: > Is it possible to create a composite link which has a physical > point-to-point link as one component link and an MPLS LSP as the other > component link? >=20 > Is it also possible to create a composite link that has two different > MPLS LSPs, both between the same endpoints, and each taking up a > different path, as the component links? I'm not quite sure of the context of your question. In the context of = draft-ietf-rtgwg-cl-requirement-03, it is quite clear: Composite Link: A composite link is a logical link composed of a set of parallel point-to-point component links, where all links in the set share the same endpoints. A composite link may itself be a component of another composite link, but only a strict hierarchy of links is allowed. Component Link: A point-to-point physical or logical link that preserves ordering in the steady state. A component link may have transient out of order events, but such events must not exceed the network's specific NPO. Examples of a physical link are: Lambda, Ethernet PHY, and OTN. Examples of a logical link are: MPLS LSP, Ethernet VLAN, and MPLS-TP LSP. Both of the cases that you cite should be supported, per these = requirements. Tony From mark.ietf@gmail.com Thu Jan 27 17:06: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 6910D3A6A0D for ; Thu, 27 Jan 2011 17:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[AWL=0.464, 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 hMtwaNSVS2-L for ; Thu, 27 Jan 2011 17:06:06 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 814BC3A69F5 for ; Thu, 27 Jan 2011 17:06:06 -0800 (PST) Received: by qyk34 with SMTP id 34so270522qyk.10 for ; Thu, 27 Jan 2011 17:09:11 -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; bh=1CcOAMbgxWwPThnJKxY0xE5x0fyYS/snMrUhiA63blw=; b=Fgt99mOMEXg6VXAyJXrqsMI0RNPCJNN8IN68tcpSYd5bGQZApiX7EAgO3ixAdZQBSe AJNC33py5FP95GEMLwJOrDhlR6JdXTZs248YZ+GwmaaJmJ1VUlaw5Xoga+iaxwt69YwT 7gvLKSpxs6UzJqOtK8vZNlE+MwUxaFCGeh7Rg= 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; b=Rw21MAArh4Zeq74hHoLMl+96hkPmR/eMyfzNjhARzEiGimmln7OvcBofB9P1pj8MI8 P+UAc65J4UGwBeRdQWx9dKU0dW98ZNLy5z9QH8VGPtybN3r6v7B5SV//YrRBBcJ6xfQk 2RIT5DRqCAG+vBnISHMxBVCydQslOqT3OudMM= MIME-Version: 1.0 Received: by 10.229.212.6 with SMTP id gq6mr2182361qcb.150.1296176951055; Thu, 27 Jan 2011 17:09:11 -0800 (PST) Received: by 10.229.222.73 with HTTP; Thu, 27 Jan 2011 17:09:11 -0800 (PST) In-Reply-To: <3A81B14B-C922-45F2-BD82-A39E45BD446E@tony.li> References: <3A81B14B-C922-45F2-BD82-A39E45BD446E@tony.li> Date: Fri, 28 Jan 2011 06:39:11 +0530 Message-ID: Subject: Re: Doubt regarding the component links From: mark Brown To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 01:06:07 -0000 Hi Tony, Thanks for the confirmation! >> >> Is it also possible to create a composite link that has two different >> MPLS LSPs, both between the same endpoints, and each taking up a >> different path, as the component links? Assume that i set up an MPLS LSP (or a pseudowire) between two points and there lies a composite link in that path. When the traffic enters the composite link it will get an MPLS label slapped on. Thus if the original packet was carrying two MPLS labels (which usually happens for L2 and L3 VPNs), it will now carry 3 labels, while its transiting the composite link. Is my understanding correct here? If this composite links terminates at an LER then it will have to pop off at least two labels before it can process the packet. The first label would correspond to the endpoint of the composite link and the other for the original tunnel termination. Thanks, Mark From tony.li@tony.li Thu Jan 27 17: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 CFC1B3A6AD6 for ; Thu, 27 Jan 2011 17:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+912QjHEwpU for ; Thu, 27 Jan 2011 17:17:59 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id C01AA3A68FC for ; Thu, 27 Jan 2011 17:17:59 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta02.westchester.pa.mail.comcast.net with comcast id 0ox01g0041c6gX852pM5yv; Fri, 28 Jan 2011 01:21:05 +0000 Received: from dhcp-171-70-245-132.cisco.com ([171.70.245.132]) by omta23.westchester.pa.mail.comcast.net with comcast id 0pLt1g00F2s79i33jpLveW; Fri, 28 Jan 2011 01:21:02 +0000 Subject: Re: Doubt regarding the component links Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Thu, 27 Jan 2011 17:20:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A81B14B-C922-45F2-BD82-A39E45BD446E@tony.li> 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: Fri, 28 Jan 2011 01:18:00 -0000 Hi Mark, > Assume that i set up an MPLS LSP (or a pseudowire) between two points > and there lies a composite link in that path. When the traffic enters > the composite link it will get an MPLS label slapped on. Thus if the > original packet was carrying two MPLS labels (which usually happens > for L2 and L3 VPNs), it will now carry 3 labels, while its transiting > the composite link. Is my understanding correct here? Assuming the composite link has an LSP as a component, that seems not = unreasonable. However, might some implementations perform PHP? Also, adding a third label is NOT necessary if the composite link is = purely physical links. > If this composite links terminates at an LER then it will have to pop > off at least two labels before it can process the packet. The first > label would correspond to the endpoint of the composite link and the > other for the original tunnel termination. Sounds right. Tony From mark.ietf@gmail.com Thu Jan 27 17:40: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 953D03A6B60 for ; Thu, 27 Jan 2011 17:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 CrBEJqfjD3ki for ; Thu, 27 Jan 2011 17:40:54 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id B04363A6AE1 for ; Thu, 27 Jan 2011 17:40:54 -0800 (PST) Received: by qyk34 with SMTP id 34so293664qyk.10 for ; Thu, 27 Jan 2011 17:43:59 -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=zj26zFH23CLF6IuWKS1assX7RFcMyjvdZ+lQj0POxMg=; b=Ni5Yb/HRJhRAB1Yo9jMXTtTuqYC4L+7pvj0DiMkmo90MIMg0G5MG58MPrPX/jOgnxv qLbIn4wkD/bFCwuPl4kOHDHlxvW8RONys3w5W4Z75hyKGxBY07tlYm2JnXr9+LStJM0l /nrsw/qrHtdOaewS5vZ52gF78dwacV9YcI85Q= 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=T5eu5+/OCl0EYCAALsYsS/K6lAEBQdlnY1b+tYzVddQxJbjIH82MluOSoEeF7Mw9vJ 9hlIb1rebd4hOY2cep7wcjEfngsPKXDUIfzWjekBb/uV5Wg6GmmejS9QUF2DF7RrAexY IGeshwFugv9FJQKngNON7v8dmBNXRcvL4OUAg= MIME-Version: 1.0 Received: by 10.229.242.83 with SMTP id lh19mr2154101qcb.226.1296179039158; Thu, 27 Jan 2011 17:43:59 -0800 (PST) Received: by 10.229.222.73 with HTTP; Thu, 27 Jan 2011 17:43:59 -0800 (PST) In-Reply-To: References: <3A81B14B-C922-45F2-BD82-A39E45BD446E@tony.li> Date: Fri, 28 Jan 2011 07:13:59 +0530 Message-ID: Subject: Re: Doubt regarding the component links From: mark Brown To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 01:40:55 -0000 Hi Tony, >> Assume that i set up an MPLS LSP (or a pseudowire) between two points >> and there lies a composite link in that path. When the traffic enters >> the composite link it will get an MPLS label slapped on. Thus if the >> original packet was carrying two MPLS labels (which usually happens >> for L2 and L3 VPNs), it will now carry 3 labels, while its transiting >> the composite link. Is my understanding correct here? > > > Assuming the composite link has an LSP as a component, that seems not unr= easonable. =A0However, might some implementations perform PHP? > > Also, adding a third label is NOT necessary if the composite link is pure= ly physical links. I agree. However, i was describing a case when my composite link comprises of an MPLS LSP. > > >> If this composite links terminates at an LER then it will have to pop >> off at least two labels before it can process the packet. The first >> label would correspond to the endpoint of the composite link and the >> other for the original tunnel termination. > > > Sounds right. Thanks for the help Mark From manav.bhatia@alcatel-lucent.com Thu Jan 27 18:54: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 764563A6A5C for ; Thu, 27 Jan 2011 18:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 xpNFs5A7pCNA for ; Thu, 27 Jan 2011 18:54:35 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id AD50F3A68B8 for ; Thu, 27 Jan 2011 18:54:35 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p0S2vax1001695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 27 Jan 2011 20:57:39 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0S2vZBh029344 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 28 Jan 2011 08:27:36 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 28 Jan 2011 08:27:35 +0530 From: "Bhatia, Manav (Manav)" To: "rtgwg@ietf.org" Date: Fri, 28 Jan 2011 08:27:29 +0530 Subject: Designated Component Link Thread-Topic: Designated Component Link Thread-Index: Acu+lxo0RJrML79jSayIEmFGHoZQSw== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB18B85B@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 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, 28 Jan 2011 02:54:36 -0000 Hi, Due to the nature of composite links there is a high chance that the forwar= d and reverse traffic takes up different component links resulting in perce= ptible difference in the transit times. This may not be acceptable for prot= ocols like 1588, NTP, etc that would like a symmetrical forward/reverse pat= h for an accurate delay measurement. Can we introduce a concept of a design= ated component link which applications/protocols that are sensitive to symm= etry can take when transiting a composite link? Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From tony.li@tony.li Thu Jan 27 19:01:39 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 8922D3A6B84 for ; Thu, 27 Jan 2011 19:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 BH2z2ZXBx5E8 for ; Thu, 27 Jan 2011 19:01:38 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 9C95D3A6B72 for ; Thu, 27 Jan 2011 19:01:38 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta09.westchester.pa.mail.comcast.net with comcast id 0r3j1g0021c6gX859r4k5b; Fri, 28 Jan 2011 03:04:44 +0000 Received: from dhcp-171-70-245-132.cisco.com ([171.70.245.132]) by omta23.westchester.pa.mail.comcast.net with comcast id 0r4Y1g00w2s79i33jr4b2b; Fri, 28 Jan 2011 03:04:42 +0000 Subject: Re: Designated Component Link Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB18B85B@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 27 Jan 2011 19:04:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0FAF3B34-9378-467E-9F18-430FC4165A87@tony.li> References: <7C362EEF9C7896468B36C9B79200D8350CFB18B85B@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" 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: Fri, 28 Jan 2011 03:01:39 -0000 On Jan 27, 2011, at 6:57 PM, Bhatia, Manav (Manav) wrote: > Due to the nature of composite links there is a high chance that the = forward and reverse traffic takes up different component links resulting = in perceptible difference in the transit times. This may not be = acceptable for protocols like 1588, NTP, etc that would like a = symmetrical forward/reverse path for an accurate delay measurement. Can = we introduce a concept of a designated component link which = applications/protocols that are sensitive to symmetry can take when = transiting a composite link? The larger problem is that of full blown path asymmetry, which is being = addressed by requirements for bidirectional LSPs. A reasonable addition to our requirements might be that a composite link = bind both directions of a bidirectional LSP to a single component. Tony From manav.bhatia@alcatel-lucent.com Thu Jan 27 19:31:38 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 71AA73A6906 for ; Thu, 27 Jan 2011 19:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.312, 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 Dksm0-0NYJxq for ; Thu, 27 Jan 2011 19:31:37 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id D71C73A68B8 for ; Thu, 27 Jan 2011 19:31:36 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p0S3Ya1O004383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Jan 2011 21:34:39 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0S3YYD6000729 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Jan 2011 09:04:35 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 28 Jan 2011 09:04:34 +0530 From: "Bhatia, Manav (Manav)" To: Tony Li Date: Fri, 28 Jan 2011 09:04:32 +0530 Subject: RE: Designated Component Link Thread-Topic: Designated Component Link Thread-Index: Acu+mCCxOgVlcwAvQqSnctH/wcdhMgAAnKkg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB18B85F@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB18B85B@INBANSXCHMBSA1.in.alcatel-lucent.com> <0FAF3B34-9378-467E-9F18-430FC4165A87@tony.li> In-Reply-To: <0FAF3B34-9378-467E-9F18-430FC4165A87@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 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, 28 Jan 2011 03:31:38 -0000 =20 > A reasonable addition to our requirements might be that a=20 > composite link bind both directions of a bidirectional LSP to=20 > a single component. Yes, this is precisely what I am looking at. A designated component link is useful in adding some determinism when picki= ng up components from a composite link. We could have an RSVP object that f= orces implementations to use the primary or the designated component link. = This way we can also achieve this symmetry using unidirectional LSPs. Thinking aloud - Wouldn't this also be useful for OAM? To test the liveline= ss of the composite link we would just need to test the liviness of the des= ignated/primary component link. Cheers, Manav >=20 > Tony >=20 > = From tony.li@tony.li Thu Jan 27 23:18:26 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 120D83A6A67 for ; Thu, 27 Jan 2011 23:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 EpCxrtoaN2lk for ; Thu, 27 Jan 2011 23:18:25 -0800 (PST) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 399323A6A44 for ; Thu, 27 Jan 2011 23:18:25 -0800 (PST) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 0vKf1g0041u4NiLA4vMWkF; Fri, 28 Jan 2011 07:21:30 +0000 Received: from [192.168.2.100] ([98.248.36.188]) by omta21.emeryville.ca.mail.comcast.net with comcast id 0vMV1g00A43ZcXW8hvMWFl; Fri, 28 Jan 2011 07:21:30 +0000 Subject: Re: Designated Component Link Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB18B85F@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 27 Jan 2011 23:21:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <771CEFE3-E032-4C6D-88CF-B5477CC5016E@tony.li> References: <7C362EEF9C7896468B36C9B79200D8350CFB18B85B@INBANSXCHMBSA1.in.alcatel-lucent.com> <0FAF3B34-9378-467E-9F18-430FC4165A87@tony.li> <7C362EEF9C7896468B36C9B79200D8350CFB18B85F@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" 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: Fri, 28 Jan 2011 07:18:26 -0000 > A designated component link is useful in adding some determinism when = picking up components from a composite link. We could have an RSVP = object that forces implementations to use the primary or the designated = component link. This way we can also achieve this symmetry using = unidirectional LSPs. This is already a likely consequence of any solution that wishes to = provide MPLS/TE support across composite links. If the LSP path has = component specific requirements, then the ERO computed by the head end = could specify the component link. You can achieve symmetry by either inverting the ERO, or, perhaps using = the mechanisms already specified in GMPLS for an UPSTREAM LABEL, = effectively creating the bidirectional LSP. > Thinking aloud - Wouldn't this also be useful for OAM? To test the = liveliness of the composite link we would just need to test the liviness = of the designated/primary component link. >>=20 I'm not sure I understand what you consider to be 'primary'. OAM = already has the capabilities to test the liveness of any LSP, and a = logical extension is to require the use of BFD for component liveness. Tony From dave.mcdysan@verizon.com Fri Jan 28 06:44: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 5B3DF3A687E for ; Fri, 28 Jan 2011 06:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 PaGmT6danmJI for ; Fri, 28 Jan 2011 06:44:47 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 446A43A6808 for ; Fri, 28 Jan 2011 06:44:47 -0800 (PST) Received: from irvintrmemf3.verizon.com (irvintrmemf3.verizon.com [138.83.34.103]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p0SElXlK004010; Fri, 28 Jan 2011 09:47:34 -0500 (EST) X-AuditID: 8a532267-b7bf7ae0000034a2-84-4d42d7036360 Received: from smtptpa4.verizon.com ( [138.83.71.177]) by irvintrmemf3.verizon.com (Symantec Mail Security) with SMTP id E4.8C.13474.307D24D4; Fri, 28 Jan 2011 08:47:31 -0600 (CST) Received: from FHDP1LUMXC7HB05.us.one.verizon.com (fhdp1lumxc7hb05.verizon.com [166.68.59.192]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id p0SElUPA024886; Fri, 28 Jan 2011 09:47:31 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB05.us.one.verizon.com ([2002:a644:3bc0::a644:3bc0]) with mapi; Fri, 28 Jan 2011 09:47:30 -0500 From: "Mcdysan, David E" To: Tony Li , "Bhatia, Manav (Manav)" Date: Fri, 28 Jan 2011 09:47:29 -0500 Subject: Re: Designated Component Link Thread-Topic: Designated Component Link Thread-Index: Acu++kmxDfk8mcb9TASTHzKADdfFPQ== Message-ID: In-Reply-To: <0FAF3B34-9378-467E-9F18-430FC4165A87@tony.li> 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-Brightmail-Tracker: AAAAAA== 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, 28 Jan 2011 14:44:48 -0000 Hi, Proposed wording of an additional requirement for your review and comment: The solution MUST support a means for LSP signaling to indicate to a composite link that both directions of a bidirectional LSP must be bound to a single component link. In the absence of such a signaling indication, the different directions of a bidirectional LSP need only be bound to a component link that is part of the composite link. Dave On 1/27/11 10:04 PM, "Tony Li" wrote: > >On Jan 27, 2011, at 6:57 PM, Bhatia, Manav (Manav) wrote: > >> Due to the nature of composite links there is a high chance that the >>forward and reverse traffic takes up different component links resulting >>in perceptible difference in the transit times. This may not be >>acceptable for protocols like 1588, NTP, etc that would like a >>symmetrical forward/reverse path for an accurate delay measurement. Can >>we introduce a concept of a designated component link which >>applications/protocols that are sensitive to symmetry can take when >>transiting a composite link? > > >The larger problem is that of full blown path asymmetry, which is being >addressed by requirements for bidirectional LSPs. > >A reasonable addition to our requirements might be that a composite link >bind both directions of a bidirectional LSP to a single component. > >Tony > >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From dave.mcdysan@verizon.com Fri Jan 28 06:48: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 2DA0F3A687B for ; Fri, 28 Jan 2011 06:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 EO30L1TLxU5J for ; Fri, 28 Jan 2011 06:48:14 -0800 (PST) Received: from tpamail4.verizon.com (tpamail4.verizon.com [192.76.82.161]) by core3.amsl.com (Postfix) with ESMTP id 288C03A6838 for ; Fri, 28 Jan 2011 06:48:14 -0800 (PST) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id p0SEhGSF027375; Fri, 28 Jan 2011 09:44:51 -0500 (EST) X-AuditID: 8a53433a-b7b45ae000007b4c-9d-4d42d7e6e49d Received: from smtptpa3.verizon.com ( [138.83.71.176]) by tpaintrmemf3.verizon.com (EMF) with SMTP id A7.5C.31564.6E7D24D4; Fri, 28 Jan 2011 09:51:19 -0500 (EST) Received: from FHDP1LUMXC7HB04.us.one.verizon.com (fhdp1lumxc7hb04.verizon.com [166.68.59.191]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id p0SEp72t003051; Fri, 28 Jan 2011 09:51:18 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Fri, 28 Jan 2011 09:51:12 -0500 From: "Mcdysan, David E" To: mark Brown , Tony Li Date: Fri, 28 Jan 2011 09:51:11 -0500 Subject: Re: Doubt regarding the component links Thread-Topic: Doubt regarding the component links Thread-Index: Acu++s5f/RXrmJhESie2B9DuiE5TSA== 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-Brightmail-Tracker: AAAAAA== 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, 28 Jan 2011 14:48:15 -0000 Hi, Some good discussion here, but I don't see a need to add or change requirements text.=20 May be good to capture some of these clarifications in the proposed composite link framework document. Thanks, Dave On 1/27/11 8:43 PM, "mark Brown" wrote: >Hi Tony, > >>> Assume that i set up an MPLS LSP (or a pseudowire) between two points >>> and there lies a composite link in that path. When the traffic enters >>> the composite link it will get an MPLS label slapped on. Thus if the >>> original packet was carrying two MPLS labels (which usually happens >>> for L2 and L3 VPNs), it will now carry 3 labels, while its transiting >>> the composite link. Is my understanding correct here? >> >> >> Assuming the composite link has an LSP as a component, that seems not >>unreasonable. However, might some implementations perform PHP? >> >> Also, adding a third label is NOT necessary if the composite link is >>purely physical links. > >I agree. However, i was describing a case when my composite link >comprises of an MPLS LSP. > >> >> >>> If this composite links terminates at an LER then it will have to pop >>> off at least two labels before it can process the packet. The first >>> label would correspond to the endpoint of the composite link and the >>> other for the original tunnel termination. >> >> >> Sounds right. > >Thanks for the help > >Mark >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From manav.bhatia@alcatel-lucent.com Fri Jan 28 07:36: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 3AC123A67D1 for ; Fri, 28 Jan 2011 07:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 AhhTum3vJyAq for ; Fri, 28 Jan 2011 07:36:17 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 179843A67A8 for ; Fri, 28 Jan 2011 07:36:17 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p0SFdImR012966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Jan 2011 09:39:21 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0SFdHu6028871 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Jan 2011 21:09:17 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 28 Jan 2011 21:09:17 +0530 From: "Bhatia, Manav (Manav)" To: "Mcdysan, David E" , Tony Li Date: Fri, 28 Jan 2011 21:09:16 +0530 Subject: RE: Designated Component Link Thread-Topic: Designated Component Link Thread-Index: Acu++kmxDfk8mcb9TASTHzKADdfFPQAByTYw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB18BAAD@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <0FAF3B34-9378-467E-9F18-430FC4165A87@tony.li> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 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, 28 Jan 2011 15:36:19 -0000 Yup, this should be good. Cheers, Manav > -----Original Message----- > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com]=20 > Sent: Friday, January 28, 2011 8.17 PM > To: Tony Li; Bhatia, Manav (Manav) > Cc: rtgwg@ietf.org > Subject: Re: Designated Component Link >=20 > Hi, >=20 > Proposed wording of an additional requirement for your review=20 > and comment: >=20 > The solution MUST support a means for LSP signaling to indicate to a > composite link that both directions of a bidirectional LSP=20 > must be bound > to a single component link. In the absence of such a=20 > signaling indication, > the different directions of a bidirectional LSP need only be=20 > bound to a > component link that is part of the composite link. >=20 > Dave >=20 > On 1/27/11 10:04 PM, "Tony Li" wrote: >=20 > > > >On Jan 27, 2011, at 6:57 PM, Bhatia, Manav (Manav) wrote: > > > >> Due to the nature of composite links there is a high=20 > chance that the > >>forward and reverse traffic takes up different component=20 > links resulting > >>in perceptible difference in the transit times. This may not be > >>acceptable for protocols like 1588, NTP, etc that would like a > >>symmetrical forward/reverse path for an accurate delay=20 > measurement. Can > >>we introduce a concept of a designated component link which > >>applications/protocols that are sensitive to symmetry can take when > >>transiting a composite link? > > > > > >The larger problem is that of full blown path asymmetry,=20 > which is being > >addressed by requirements for bidirectional LSPs. > > > >A reasonable addition to our requirements might be that a=20 > composite link > >bind both directions of a bidirectional LSP to a single component. > > > >Tony > > > >_______________________________________________ > >rtgwg mailing list > >rtgwg@ietf.org > >https://www.ietf.org/mailman/listinfo/rtgwg >=20 > = From tony.li@tony.li Fri Jan 28 10:30:09 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 7C35E28C0D9 for ; Fri, 28 Jan 2011 10:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 rlG4v-8VAdTl for ; Fri, 28 Jan 2011 10:30:08 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 205373A6924 for ; Fri, 28 Jan 2011 10:30:06 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id 16Uh1g0011ap0As5A6ZEFj; Fri, 28 Jan 2011 18:33:14 +0000 Received: from dhcp-171-70-245-132.cisco.com ([171.70.245.132]) by omta22.westchester.pa.mail.comcast.net with comcast id 16Z11g00b2s79i33i6Z3Yx; Fri, 28 Jan 2011 18:33:12 +0000 Subject: Re: Designated Component Link Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Fri, 28 Jan 2011 10:32:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Mcdysan, David E" 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: Fri, 28 Jan 2011 18:30:09 -0000 Hi Dave, > The solution MUST support a means for LSP signaling to indicate to a > composite link that both directions of a bidirectional LSP must be = bound > to a single component link. In the absence of such a signaling = indication, > the different directions of a bidirectional LSP need only be bound to = a > component link that is part of the composite link. We want this to signaling option to apply to unidirectional LSPs as = well, yes? If so, we might wordsmith it this way: 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. Tony