From lizho.jin@gmail.com  Sat Dec  5 07:11:26 2009
Return-Path: <lizho.jin@gmail.com>
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 0C8D33A6819 for <rtgwg@core3.amsl.com>; Sat,  5 Dec 2009 07:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6KiHgsfiktj for <rtgwg@core3.amsl.com>; Sat,  5 Dec 2009 07:11:25 -0800 (PST)
Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 1A6BB3A68F4 for <rtgwg@ietf.org>; Sat,  5 Dec 2009 07:11:24 -0800 (PST)
Received: by iwn33 with SMTP id 33so2344499iwn.29 for <rtgwg@ietf.org>; Sat, 05 Dec 2009 07:11:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ez42p/Mm+gw1YnydZmdVN9m/CvPIfk8KinIG3LMfSOQ=; b=h2cDi5BqED06s91mQJ8qmihWghtQ709U8ZE6NHiktMSRiSb6hSsAWAnrTh2LPKA3PS MYIQDbgtbP13PNuE+ynN+N+tA5qm2kEyovby2GeBxUUOxNvwBz1fnWXxZ9MadE8UbYAM PLxAdUHR8ocPh5AWjKh8GSGIpP7RBs91gBuzo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QWeiIUCGajuptvI8avktsTzgPX/+CWyUB2FKsoe+KHbLUiIC8UZgUmbPn9jH23GYq+ qdcXYB2qDNFWImTqwxrwTHCCjNbekW/Ex34yJoDfT4ohinKxdPGPIHoyXu4YuerUqKpn 9xlarELLEEDvBdHQapgjQoVgiFqFCbgKYTyho=
MIME-Version: 1.0
Received: by 10.231.122.36 with SMTP id j36mr22331ibr.21.1260025873318; Sat,  05 Dec 2009 07:11:13 -0800 (PST)
Date: Sat, 5 Dec 2009 23:11:13 +0800
Message-ID: <a1833a360912050711t1e9fcf01kaeb44fe99355392e@mail.gmail.com>
Subject: Re: Composite Link Requirements as WG document
From: Lizhong Jin <lizho.jin@gmail.com>
To: rtgwg@ietf.org
Content-Type: multipart/alternative; boundary=0016e64603ea96433d0479fca23c
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Dec 2009 15:11:26 -0000

--0016e64603ea96433d0479fca23c
Content-Type: text/plain; charset=ISO-8859-1

Yes, support.

Best Regards
Lizhong Jin


-----Original Message-----
From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of
John G. Scudder
Sent: Tuesday, November 10, 2009 3:08 AM
To: rtgwg@ietf.org
Cc: alia.atlas@bt.com; ZININ Alex
Subject: Composite Link Requirements as WG document
Folks,
At today's meeting we received a request to adopt draft-so-yong-mpls-
ctg-requirement-00 as a working group document.  There was reasonably
strong support in the room for doing so.  Please respond to the
mailing list with your discussion, support or opposition (please do
this even if you did so in person).  The deadline for comments is
November 30.
Note that accepting the document simply means that the working group
would begin working on requirements.  It does not imply blanket
acceptance of the document as it now stands.
Thanks,
--John
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

--0016e64603ea96433d0479fca23c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, support.<br>=A0<br>Best Regards<br>Lizhong Jin<br>=A0<br>=A0<br>-----O=
riginal Message-----<br>From: <a href=3D"mailto:rtgwg-bounces@ietf.org">rtg=
wg-bounces@ietf.org</a> [mailto:<a href=3D"mailto:rtgwg-bounces@ietf.org">r=
tgwg-bounces@ietf.org</a>] On Behalf Of<br>
John G. Scudder<br>Sent: Tuesday, November 10, 2009 3:08 AM<br>To: <a href=
=3D"mailto:rtgwg@ietf.org">rtgwg@ietf.org</a><br>Cc: <a href=3D"mailto:alia=
.atlas@bt.com">alia.atlas@bt.com</a>; ZININ Alex<br>Subject: Composite Link=
 Requirements as WG document<br>
Folks,<br>At today&#39;s meeting we received a request to adopt draft-so-yo=
ng-mpls-<br>ctg-requirement-00 as a working group document.=A0 There was re=
asonably<br>strong support in the room for doing so.=A0 Please respond to t=
he<br>
mailing list with your discussion, support or opposition (please do<br>this=
 even if you did so in person).=A0 The deadline for comments is<br>November=
 30.<br>Note that accepting the document simply means that the working grou=
p<br>
would begin working on requirements.=A0 It does not imply blanket<br>accept=
ance of the document as it now stands.<br>Thanks,<br>--John<br>____________=
___________________________________<br>rtgwg mailing list<br><a href=3D"mai=
lto:rtgwg@ietf.org">rtgwg@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/rtgwg">https://www.ietf.or=
g/mailman/listinfo/rtgwg</a>

--0016e64603ea96433d0479fca23c--

From Dimitri.Papadimitriou@alcatel-lucent.com  Sun Dec  6 02:10:58 2009
Return-Path: <Dimitri.Papadimitriou@alcatel-lucent.com>
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 EF8463A6857 for <rtgwg@core3.amsl.com>; Sun,  6 Dec 2009 02:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.746
X-Spam-Level: 
X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 i9YV-XYVdPSs for <rtgwg@core3.amsl.com>; Sun,  6 Dec 2009 02:10:57 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 053B73A67AE for <rtgwg@ietf.org>; Sun,  6 Dec 2009 02:10:55 -0800 (PST)
Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nB6AAi0s025169;  Sun, 6 Dec 2009 11:10:44 +0100
Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Dec 2009 11:10:44 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Composite Link Requirements as WG document
Date: Sun, 6 Dec 2009 11:10:43 +0100
Message-ID: <00275A5B436CA441900CB10936742A38038E95ED@FRVELSMBS22.ad2.ad.alcatel.com>
In-Reply-To: <920D04EF-71DA-4CCA-9E9C-51F3F1FD237C@juniper.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Composite Link Requirements as WG document
Thread-Index: Acph5byWwoYdCihSQmuqXEn8MXVmmAUcaqbQ
References: <920D04EF-71DA-4CCA-9E9C-51F3F1FD237C@juniper.net>
From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.com>
To: "John G. Scudder" <jgs@juniper.net>, <rtgwg@ietf.org>
X-OriginalArrivalTime: 06 Dec 2009 10:10:44.0075 (UTC) FILETIME=[5F429BB0:01CA765C]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80
Cc: alia.atlas@bt.com, ZININ Alex <Alex.Zinin@alcatel-lucent.sg>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Dec 2009 10:11:00 -0000

Hi,

Two comments on this document:

"Unlike a link bundle [RFC4201], the component links in a=20
composite link can have different properties such as cost=20
or capacity."

Component link "capacity" heterogeneity is "allowed" in 4201 I can
understand the potential limitation of identical TE metrics (for each
component) unfortunately limited explanation are given to sustain why it
should be addressed.

"This document describes a framework for managing aggregated=20
traffic over a composite link."
[...]
"To achieve the better component link utilization and avoid=20
component link congestion, the document describes some new
aspects on the traffic flow assignment to component links."

The document is specifically dealing to TE control but does not explain
why "measuring" component link capacity is assumed impossible (cf. 4201
Section 4) ?

Bottom-line: not clear if this document is intended to improve
applicability of bundling TE control in IP/MPLS or if the current
bundling approach is not fulfilling expected functionality (and this
document would outline the why/what). The issue is that the document
describes "modeling" but does not provide an answer to this question.=20

Thanks,
-dimitri.=20



> -----Original Message-----
> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20
> On Behalf Of John G. Scudder
> Sent: Tuesday, November 10, 2009 10:08 AM
> To: rtgwg@ietf.org
> Cc: alia.atlas@bt.com; ZININ Alex
> Subject: Composite Link Requirements as WG document
>=20
> Folks,
>=20
> At today's meeting we received a request to adopt draft-so-yong-mpls-=20
> ctg-requirement-00 as a working group document.  There was=20
> reasonably =20
> strong support in the room for doing so.  Please respond to the =20
> mailing list with your discussion, support or opposition (please do =20
> this even if you did so in person).  The deadline for comments is =20
> November 30.
>=20
> Note that accepting the document simply means that the working group =20
> would begin working on requirements.  It does not imply blanket =20
> acceptance of the document as it now stands.
>=20
> Thanks,
>=20
> --John
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>=20

From lucyyong@huawei.com  Sun Dec  6 18:21:23 2009
Return-Path: <lucyyong@huawei.com>
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 86A163A6978 for <rtgwg@core3.amsl.com>; Sun,  6 Dec 2009 18:21:23 -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 qJOCxoGyCewO for <rtgwg@core3.amsl.com>; Sun,  6 Dec 2009 18:21:22 -0800 (PST)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 27D2A3A677C for <rtgwg@ietf.org>; Sun,  6 Dec 2009 18:21:22 -0800 (PST)
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU90031RFVCVM@usaga01-in.huawei.com> for rtgwg@ietf.org; Sun, 06 Dec 2009 18:21:12 -0800 (PST)
Received: from y736742 (cpe-173-173-92-181.tx.res.rr.com [173.173.92.181]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0KU900MAMFVBF6@usaga01-in.huawei.com> for rtgwg@ietf.org; Sun, 06 Dec 2009 18:21:12 -0800 (PST)
Date: Sun, 06 Dec 2009 20:21:13 -0600
From: Yong Lucy <lucyyong@huawei.com>
Subject: RE: Composite Link Requirements as WG document
In-reply-to: <00275A5B436CA441900CB10936742A38038E95ED@FRVELSMBS22.ad2.ad.alcatel.com>
To: 'PAPADIMITRIOU Dimitri' <Dimitri.Papadimitriou@alcatel-lucent.com>, "'John G. Scudder'" <jgs@juniper.net>, rtgwg@ietf.org
Message-id: <000e01ca76e3$f2f66c10$6401a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Acph5byWwoYdCihSQmuqXEn8MXVmmAUcaqbQACHGLyA=
References: <920D04EF-71DA-4CCA-9E9C-51F3F1FD237C@juniper.net> <00275A5B436CA441900CB10936742A38038E95ED@FRVELSMBS22.ad2.ad.alcatel.com>
Cc: alia.atlas@bt.com, 'ZININ Alex' <Alex.Zinin@alcatel-lucent.sg>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 02:21:24 -0000

Hi Dimitri,

See inline.

Regards,
Lucy

> -----Original Message-----
> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of
> PAPADIMITRIOU Dimitri
> Sent: Sunday, December 06, 2009 4:11 AM
> To: John G. Scudder; rtgwg@ietf.org
> Cc: alia.atlas@bt.com; ZININ Alex
> Subject: RE: Composite Link Requirements as WG document
> 
> Hi,
> 
> Two comments on this document:
> 
> "Unlike a link bundle [RFC4201], the component links in a
> composite link can have different properties such as cost
> or capacity."
> 
> Component link "capacity" heterogeneity is "allowed" in 4201 I can
> understand the potential limitation of identical TE metrics (for each
> component) unfortunately limited explanation are given to sustain why it
> should be addressed.
[LY] Carriers want to bundle component links that do not have the same
capacities (may even have different delays) together as one IGP link in MPLS
network. They have several such applications.
> 
> "This document describes a framework for managing aggregated
> traffic over a composite link."
> [...]
> "To achieve the better component link utilization and avoid
> component link congestion, the document describes some new
> aspects on the traffic flow assignment to component links."
> 
> The document is specifically dealing to TE control but does not explain
> why "measuring" component link capacity is assumed impossible (cf. 4201
> Section 4) ?
[LY] Measuring component link as whole does not give detail information when
need to move traffic flow from one component link to another in the case
that one component link fails or higher priority flow arrives. 
> 
> Bottom-line: not clear if this document is intended to improve
> applicability of bundling TE control in IP/MPLS or if the current
> bundling approach is not fulfilling expected functionality (and this
> document would outline the why/what). The issue is that the document
> describes "modeling" but does not provide an answer to this question.

[LY] I don't see much different between two cases you are giving. RFC4201
can't apply to the situation carrier wants, i.e. bundling component links
that do not have the same capacities (may even have different delays)
together as one IGP link in MPLS network. In fact, RFC4201 only applies to
IGP TE link and RSVP-TE, carriers also need such link bundle as a IGP link
that supports LDP signaled LSPs as well.

[LY] once it becomes WG document, we can further work on the text to make it
clear. We do not make the drafts as a solution drafts. It just describes the
basic composite link framework and requirements.
> 
> Thanks,
> -dimitri.
> 
> 
> 
> > -----Original Message-----
> > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]
> > On Behalf Of John G. Scudder
> > Sent: Tuesday, November 10, 2009 10:08 AM
> > To: rtgwg@ietf.org
> > Cc: alia.atlas@bt.com; ZININ Alex
> > Subject: Composite Link Requirements as WG document
> >
> > Folks,
> >
> > At today's meeting we received a request to adopt draft-so-yong-mpls-
> > ctg-requirement-00 as a working group document.  There was
> > reasonably
> > strong support in the room for doing so.  Please respond to the
> > mailing list with your discussion, support or opposition (please do
> > this even if you did so in person).  The deadline for comments is
> > November 30.
> >
> > Note that accepting the document simply means that the working group
> > would begin working on requirements.  It does not imply blanket
> > acceptance of the document as it now stands.
> >
> > Thanks,
> >
> > --John
> > _______________________________________________
> > 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 ning.so@verizonbusiness.com  Mon Dec  7 11:13:10 2009
Return-Path: <ning.so@verizonbusiness.com>
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 4D9AE3A686B for <rtgwg@core3.amsl.com>; Mon,  7 Dec 2009 11:13:10 -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 wEvrmPdHnOZp for <rtgwg@core3.amsl.com>; Mon,  7 Dec 2009 11:13:00 -0800 (PST)
Received: from omzesmtp03a.verizonbusiness.com (omzesmtp03a.verizonbusiness.com [199.249.25.201]) by core3.amsl.com (Postfix) with ESMTP id CC40C3A6946 for <rtgwg@ietf.org>; Mon,  7 Dec 2009 11:12:49 -0800 (PST)
Received: from pdcismtp02.vzbi.com ([unknown] [166.40.77.70]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KUA00J05QP17100@firewall.verizonbusiness.com> for rtgwg@ietf.org; Mon, 07 Dec 2009 19:12:38 +0000 (GMT)
Received: from pdcismtp02.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KUA00A3ZQP1DD00@pdcismtp02.vzbi.com> for rtgwg@ietf.org; Mon, 07 Dec 2009 19:12:37 +0000 (GMT)
Received: from ASHSRV140.mcilink.com ([unknown] [153.39.68.166]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KUA00A9IQP1AM00@pdcismtp02.vzbi.com> for rtgwg@ietf.org; Mon, 07 Dec 2009 19:12:37 +0000 (GMT)
Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 07 Dec 2009 19:12:37 +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: Composite Link Requirements as WG document
Date: Mon, 07 Dec 2009 19:12:35 +0000
Message-id: <14584D6EE26B314187A4F68BA20606000272398D@ASHEVS008.mcilink.com>
In-reply-to: <00275A5B436CA441900CB10936742A38038E95ED@FRVELSMBS22.ad2.ad.alcatel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: Composite Link Requirements as WG document
Thread-index: Acph5byWwoYdCihSQmuqXEn8MXVmmAUcaqbQAEYoUhA=
References: <920D04EF-71DA-4CCA-9E9C-51F3F1FD237C@juniper.net> <00275A5B436CA441900CB10936742A38038E95ED@FRVELSMBS22.ad2.ad.alcatel.com>
From: "So, Ning" <ning.so@verizonbusiness.com>
To: PAPADIMITRIOU Dimitri <Dimitri.Papadimitriou@alcatel-lucent.com>, "John G. Scudder" <jgs@juniper.net>, rtgwg@ietf.org
X-OriginalArrivalTime: 07 Dec 2009 19:12:37.0524 (UTC) FILETIME=[3D32F540:01CA7771]
Cc: alia.atlas@bt.com, ZININ Alex <Alex.Zinin@alcatel-lucent.sg>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 19:13:10 -0000

Dimitri,

Both of your questions are related to the motivation of the draft.  From
carrier/operator's point of view, we have thought long and hard about
this, and we have detailed our motivations in the previous drafts,
although not in this one because we thought they were well understood
since we have presented it numerous times in several WGs and meetings.
I have copied and pasted what we had in the last draft below.  I think
it addressed your questions in detail.=20


Appendix A.  Problem Statements

   Two applications are described here that encounter problems when
   multiple parallel links are deployed between two routers in today's
   IP/MPLS networks.

A.1.  Incomplete/Inefficient Utilization

   An MPLS-TE network is deployed to carry traffic on RSVP-TE LSPs, i.e.
   traffic engineered flows.  When traffic volume exceeds the capacity
   of a single physical link, multiple physical links are deployed
   between two routers as a single backbone trunk.  How to assign LSP
   traffic over multiple links and maintain this backbone trunk as a
   higher capacity and higher availability trunk than a single physical
   link becomes an extremely difficult task for carriers today.  Three
   methods that are available today are described here.

   1.  A hashing method is a common practice for traffic distribution
       over multiple paths.  Equal Cost Multi-Path (ECMP) for IP
       services and IEEE-defined Link Aggregation Group (LAG) for
       Ethernet traffic are two of the widely deployed hashing based
       technologies.  However, two common occurrences in carrier
       networks often prevent hashing being used efficiently.  First,
       for MPLS networks carrying mostly Virtual Private Network (VPN)
       traffic, the incoming traffic are usually highly encrypted, so
       that hashing depth is severely limited.  Second, the traffic in
       an MPLS-TE network typically contain a certain number of traffic
       flows that have vast differences in the bandwidth requirements.
       Furthermore, the links may be of different speeds.  In those
       cases hashing can cause some links to be congested while others
       are partially filled because hashing can only distinguish the
       flows but not the flow rates.  A TE based solution better applies
       for these cases.  IETF has always had two technology tracks for
       traffic distribution: TE-based and non-TE based.  A TE based
       solution provides a natural compliment to non-TE based hashing
       methods.

   2.  Assigning individual LSPs to each link through constrained
       routing.  A planning tool can track the utilization of each link
       and assignment of LSPs to the links.  The lag time between
       measurement and action may be large relative to the fluctuations
       in LSP utilization, and the availability and performance of the
       planning tool are also important operational factors.
       Furthermore, the flexibility in response to failure scenarios is
       limited as summarized in the following.  To gain high
       availability, FRR [RFC4090] is used to create a bypass tunnel on
       a link to protect traffic on another link or to create a detour
       LSP to protect another LSP.  If BW is reserved for the bypass
       tunnels or the detour LSPs, the network will need to reserve a
       large amount of capacity for failure recovery, which reduces the
       capacity to carry other traffic.  If BW is not reserved for the
       bypass tunnels and the detour LSPs, the planning tool can not
       assign LSPs properly to avoid the congestion during link failure
       when there are more than two parallel links.  This is because
       during the link failure, the impacted traffic is simply put on a
       bypass tunnel or detour LSPs which does not have enough reserved
       bandwidth to carry the extra traffic during the failure recovery
       phase.  An alternative is to use prioritized queuing so that
       premium traffic sees good performance during a congestion
       interval.  The LSP sources will receive an RSVP-TE path error and
       reoptimize the new LSP .  After a configurable period of time the
       LSPs will reoptimize and all traffic will experience good
       performance.  However, it will not work well when support is
       needed for both RSVP-TE signaled and LDP signaled traffic.

   3.  Facility protection, also called 1:1 protection.  Dedicate one
       link to protect another link.  Only assign traffic to one link in
       the normal condition.  When the working link fails, switch
       traffic over the protection link.  This requires 50% capacity for
       failure recovery.  This works when there are only two links.
       Under the multiple parallel link condition, this causes
       inefficient use of network capacity because there is no
       protection capacity sharing.  In addition, due to traffic
       burstiness, having one link fully loaded and another link idle
       increases transport latency and packet loss, which lowers the
       link performance quality for transport.

   None of these methods satisfies carrier requirement either because of
   poor link utilization or poor performance.  This forces carriers to
   go with the solution of deploying single higher capacity link.
   However, a higher capacity link can be expensive as compared with
   parallel low capacity links of equivalent aggregate capacity; a high
   capacity link can not be deployed in some circumstances due to
   physical impairments; or the highest capacity link may not large
   enough for some carriers.

   An LDP network can encounter the same issue as an MPLS-TE enabled
   network when multiple parallel links are deployed as a backbone
   trunk.  An LDP network can have large variance in flow rates where,
   for example, the small flows may be carrying stock tickers at a few
   kbps per flow while the large flows can be near 10 Gbps per flow
   carrying machine to machine and server to server traffic from
   individual customers.  Those large traffic flows often cannot be
   broken into micro flows.  Therefore, hashing would not work well for
   the networks carrying such flows.  Without per-flow TE information,
   this type of network has even more difficulty to use multiple
   parallel links and keep high link utilization.

A.2.  Inefficiency/Inflexibility of Logical Interface Bandwidth
      Allocation

   Using logically-separate routing instances in some implementations
   further complicates the situation.  Dedicating separate physical
   backbone links, or, in the case of sharing of a single common link,
   dedicating a portion of the link, to each routing instance is not
   efficient.  Assume that each routing instance must have at least the
   capacity of a single link, and also must have equal access to unused
   capacity.  Then, for example, if there are 2 routing instances and 3
   parallel links and half of each link bandwidth is assigned to a
   routing instance, neither routing instance can support an LSP with
   bandwidth greater than half the link bandwidth.  The same problem is
   also present in the case of the sharing of a single common link using
   the dedicated logical interface and link bandwidth method.  An
   alternative in dealing with multiple parallel links is to assign a
   logical interface and bandwidth on each of the parallel physical
   links to each routing instance, which improves efficiency as compared
   to dedicating physical links to each routing instance.

   Note that the traffic flows and LSPs from these different routing
   instances effectively operate in a Ships-in-the-Night mode, where
   they are unaware of each other.  Inflexibility results if there are
   multiple sets of LSPs (e.g., from different routing instances)
   sharing one link or a set of parallel links, and at least one set of
   LSPs can preempt others, in this case more efficient sharing of the
   link set between the routing instances is highly desirable.

A.3.  Additional Functions Required Beyond Link Bundling

   A link bundle [RFC4201] is a collection of TE links.  It is a logical
   construct that represents a way to group/map the information about
   certain physical resources that interconnect routers.  The purpose of
   link bundle is to improve routing scalability by reducing the amount
   of information that has to be handled by OSPF/IS-IS.  Each physical
   link in the link bundle is an IGP link in OSPF/IS-IS if numbered link
   is used.  A link bundle only has the significance at the router
   control plane.  The mapping of LSP to component link in a bundle is
   determined at LSP setup time and this mapping does not change due to
   newly configured LSP/LDP traffic on the same component link.  A link
   bundle only applies to RSVP-TE signaled traffic, which implies no mix
   of RSVP-TE and LDP traffic on a same interface.  CTG can handle
   RSVP-TE and LDP signaled traffic.

   Link bundling does not support groups of links with different
   characteristics (e.g., bandwidth, latency).  Furthermore, link
   bundling only supports RSVP-TE signaled LSPs and not LDP signaled
   LSPs.


Ning So
Lead Engineer
Enterprise Data Network and Traffic Planning
972-729-7905
=20

-----Original Message-----
From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf
Of PAPADIMITRIOU Dimitri
Sent: Sunday, December 06, 2009 4:11 AM
To: John G. Scudder; rtgwg@ietf.org
Cc: alia.atlas@bt.com; ZININ Alex
Subject: RE: Composite Link Requirements as WG document

Hi,

Two comments on this document:

"Unlike a link bundle [RFC4201], the component links in a=20
composite link can have different properties such as cost=20
or capacity."

Component link "capacity" heterogeneity is "allowed" in 4201 I can
understand the potential limitation of identical TE metrics (for each
component) unfortunately limited explanation are given to sustain why it
should be addressed.

"This document describes a framework for managing aggregated=20
traffic over a composite link."
[...]
"To achieve the better component link utilization and avoid=20
component link congestion, the document describes some new
aspects on the traffic flow assignment to component links."

The document is specifically dealing to TE control but does not explain
why "measuring" component link capacity is assumed impossible (cf. 4201
Section 4) ?

Bottom-line: not clear if this document is intended to improve
applicability of bundling TE control in IP/MPLS or if the current
bundling approach is not fulfilling expected functionality (and this
document would outline the why/what). The issue is that the document
describes "modeling" but does not provide an answer to this question.=20

Thanks,
-dimitri.=20



> -----Original Message-----
> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20
> On Behalf Of John G. Scudder
> Sent: Tuesday, November 10, 2009 10:08 AM
> To: rtgwg@ietf.org
> Cc: alia.atlas@bt.com; ZININ Alex
> Subject: Composite Link Requirements as WG document
>=20
> Folks,
>=20
> At today's meeting we received a request to adopt draft-so-yong-mpls-=20
> ctg-requirement-00 as a working group document.  There was=20
> reasonably =20
> strong support in the room for doing so.  Please respond to the =20
> mailing list with your discussion, support or opposition (please do =20
> this even if you did so in person).  The deadline for comments is =20
> November 30.
>=20
> Note that accepting the document simply means that the working group =20
> would begin working on requirements.  It does not imply blanket =20
> acceptance of the document as it now stands.
>=20
> Thanks,
>=20
> --John
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>=20
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

From Dimitri.Papadimitriou@alcatel-lucent.com  Mon Dec  7 11:52:10 2009
Return-Path: <Dimitri.Papadimitriou@alcatel-lucent.com>
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 728D628C1DA for <rtgwg@core3.amsl.com>; Mon,  7 Dec 2009 11:52:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.72
X-Spam-Level: 
X-Spam-Status: No, score=-4.72 tagged_above=-999 required=5 tests=[AWL=1.529,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 w89SJPi7ommd for <rtgwg@core3.amsl.com>; Mon,  7 Dec 2009 11:52:09 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id A411028C123 for <rtgwg@ietf.org>; Mon,  7 Dec 2009 11:52:08 -0800 (PST)
Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nB7Jpp3N004493;  Mon, 7 Dec 2009 20:51:51 +0100
Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 20:51:23 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Composite Link Requirements as WG document
Date: Mon, 7 Dec 2009 20:51:22 +0100
Message-ID: <00275A5B436CA441900CB10936742A38038E9CCF@FRVELSMBS22.ad2.ad.alcatel.com>
In-Reply-To: <000e01ca76e3$f2f66c10$6401a8c0@china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Composite Link Requirements as WG document
Thread-Index: Acph5byWwoYdCihSQmuqXEn8MXVmmAUcaqbQACHGLyAAI8xQQA==
References: <920D04EF-71DA-4CCA-9E9C-51F3F1FD237C@juniper.net> <00275A5B436CA441900CB10936742A38038E95ED@FRVELSMBS22.ad2.ad.alcatel.com> <000e01ca76e3$f2f66c10$6401a8c0@china.huawei.com>
From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.com>
To: "Yong Lucy" <lucyyong@huawei.com>, "John G. Scudder" <jgs@juniper.net>, <rtgwg@ietf.org>
X-OriginalArrivalTime: 07 Dec 2009 19:51:23.0383 (UTC) FILETIME=[A784E070:01CA7776]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80
Cc: alia.atlas@bt.com, ZININ Alex <Alex.Zinin@alcatel-lucent.sg>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 19:52:10 -0000

=20
Hi,=20

See inline:
> -----Original Message-----
> From: Yong Lucy [mailto:lucyyong@huawei.com]=20
> Sent: Monday, December 07, 2009 3:21 AM
> To: PAPADIMITRIOU Dimitri; 'John G. Scudder'; rtgwg@ietf.org
> Cc: alia.atlas@bt.com; ZININ Alex
> Subject: RE: Composite Link Requirements as WG document
>=20
> Hi Dimitri,
>=20
> See inline.
>=20
> Regards,
> Lucy
>=20
> > -----Original Message-----
> > From: rtgwg-bounces@ietf.org=20
> [mailto:rtgwg-bounces@ietf.org] On Behalf Of
> > PAPADIMITRIOU Dimitri
> > Sent: Sunday, December 06, 2009 4:11 AM
> > To: John G. Scudder; rtgwg@ietf.org
> > Cc: alia.atlas@bt.com; ZININ Alex
> > Subject: RE: Composite Link Requirements as WG document
> >=20
> > Hi,
> >=20
> > Two comments on this document:
> >=20
> > "Unlike a link bundle [RFC4201], the component links in a
> > composite link can have different properties such as cost
> > or capacity."
> >=20
> > Component link "capacity" heterogeneity is "allowed" in 4201 I can
> > understand the potential limitation of identical TE metrics=20
> (for each
> > component) unfortunately limited explanation are given to=20
> sustain why it
> > should be addressed.
> [LY] Carriers want to bundle component links that do not have the same
> capacities (may even have different delays) together as one=20
> IGP link in MPLS
> network. They have several such applications.
> >=20
> > "This document describes a framework for managing aggregated
> > traffic over a composite link."
> > [...]
> > "To achieve the better component link utilization and avoid
> > component link congestion, the document describes some new
> > aspects on the traffic flow assignment to component links."
> >=20
> > The document is specifically dealing to TE control but does=20
> not explain
> > why "measuring" component link capacity is assumed=20
> impossible (cf. 4201
> > Section 4) ?
> [LY] Measuring component link as whole does not give detail=20
> information when
> need to move traffic flow from one component link to another=20
> in the case
> that one component link fails or higher priority flow arrives.=20

Operation listed in that 4201 section refers to "component links".
Preemption is probably something that can be documented but not sure how
the mechanisms would differ from "link ressource allocation" as
documented elsewhere.

> > Bottom-line: not clear if this document is intended to improve
> > applicability of bundling TE control in IP/MPLS or if the current
> > bundling approach is not fulfilling expected functionality (and this
> > document would outline the why/what). The issue is that the document
> > describes "modeling" but does not provide an answer to this=20
> question.
>=20
> [LY] I don't see much different between two cases you are=20
> giving.

See it as follows: I would have preferred to see a "problem statement"
document/discussion on the list more than a framework that links to a
CTG requirement document which blurs the landscape.

> RFC4201 can't apply to the situation carrier wants, i.e.=20
> bundling component links
> that do not have the same capacities (may even have different delays)

This statement is not correct actually. i) component links do not have
to be identical in terms of capacity per 4201; and ii) the TE metric per
component should be identical (per 4201) but it does not mean that the
"delay" of each component has to be identical.

> together as one IGP link in MPLS network. In fact, RFC4201=20
> only applies to
> IGP TE link and RSVP-TE, carriers also need such link bundle=20
> as a IGP link
> that supports LDP signaled LSPs as well.

Concerning the relationship to other protocols: LMP (link property
correlation) provides the possibility to bundle component links without
"imposing" any routing protocol. RFC 4220 can also be used to set such
bundle links. The question is more what is usage of the information,
i.e., if not included as part of "TE routing" information how "bundle
information" will be made available to TE control ? One seem to question
the use of "IGP TE" but what is the alternative to disseminate this
information as part of the TE routing instance ?

Your remark concerning the relationship to signaling is not clear to me,
in the MPLS context which signaling protocol outside RSVP supports TE
capability ? If there a need to incorporate TE capabilities as part of
other signaling protocols ?

> [LY] once it becomes WG document, we can further work on the=20
> text to make it
> clear. We do not make the drafts as a solution drafts. It=20
> just describes the
> basic composite link framework and requirements.

See my questioning as follows: the "bundled link" concept and "TE link"
concepts play a central role in TE control one must capture both
motivations and consequences before revisiting them (as we don't start
from a blank sheet here and consequence falls well beyond this specific
document).=20

Thanks,
-dimitri.
=20
> > Thanks,
> > -dimitri.
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]
> > > On Behalf Of John G. Scudder
> > > Sent: Tuesday, November 10, 2009 10:08 AM
> > > To: rtgwg@ietf.org
> > > Cc: alia.atlas@bt.com; ZININ Alex
> > > Subject: Composite Link Requirements as WG document
> > >
> > > Folks,
> > >
> > > At today's meeting we received a request to adopt=20
> draft-so-yong-mpls-
> > > ctg-requirement-00 as a working group document.  There was
> > > reasonably
> > > strong support in the room for doing so.  Please respond to the
> > > mailing list with your discussion, support or opposition=20
> (please do
> > > this even if you did so in person).  The deadline for comments is
> > > November 30.
> > >
> > > Note that accepting the document simply means that the=20
> working group
> > > would begin working on requirements.  It does not imply blanket
> > > acceptance of the document as it now stands.
> > >
> > > Thanks,
> > >
> > > --John
> > > _______________________________________________
> > > rtgwg mailing list
> > > rtgwg@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtgwg
> > >
> > _______________________________________________
> > rtgwg mailing list
> > rtgwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtgwg
>=20
>=20

From ning.so@verizonbusiness.com  Mon Dec  7 11:53:10 2009
Return-Path: <ning.so@verizonbusiness.com>
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 B737E28C1DD for <rtgwg@core3.amsl.com>; Mon,  7 Dec 2009 11:53:10 -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 tA466iIalkLz for <rtgwg@core3.amsl.com>; Mon,  7 Dec 2009 11:53:09 -0800 (PST)
Received: from omzesmtp03a.verizonbusiness.com (omzesmtp03a.verizonbusiness.com [199.249.25.201]) by core3.amsl.com (Postfix) with ESMTP id CD1A928C1A7 for <rtgwg@ietf.org>; Mon,  7 Dec 2009 11:53:08 -0800 (PST)
Received: from omzismtp02.vzbi.com ([unknown] [165.122.46.167]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KUA00L4BSI71G00@firewall.verizonbusiness.com> for rtgwg@ietf.org; Mon, 07 Dec 2009 19:51:43 +0000 (GMT)
Received: from omzismtp02.vzbi.com ([unknown] [127.0.0.1]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KUA00E1TSI7I400@omzismtp02.vzbi.com> for rtgwg@ietf.org; Mon, 07 Dec 2009 19:51:43 +0000 (GMT)
Received: from ASHSRV139.mcilink.com ([unknown] [153.39.68.165]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KUA00ED7SI6AJ00@omzismtp02.vzbi.com> for rtgwg@ietf.org; Mon, 07 Dec 2009 19:51:43 +0000 (GMT)
Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV139.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 07 Dec 2009 19:51:42 +0000
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Subject: RE: Composite Link Requirements as WG document
Date: Mon, 07 Dec 2009 19:51:39 +0000
Message-id: <14584D6EE26B314187A4F68BA206060002723A11@ASHEVS008.mcilink.com>
In-reply-to: <14584D6EE26B314187A4F68BA2060600B3D351@ASHEVS008.mcilink.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: Composite Link Requirements as WG document
Thread-index: Acph5byWwoYdCihSQmuqXEn8MXVmmAUcaqbQAEYoUhAAAZBWcA==
References: <00275A5B436CA441900CB10936742A38038E95ED@FRVELSMBS22.ad2.ad.alcatel.com> <14584D6EE26B314187A4F68BA2060600B3D351@ASHEVS008.mcilink.com>
From: "So, Ning" <ning.so@verizonbusiness.com>
To: "So, Ning" <ning.so@verizonbusiness.com>, PAPADIMITRIOU Dimitri <Dimitri.Papadimitriou@alcatel-lucent.com>, "John G. Scudder" <jgs@juniper.net>, rtgwg@ietf.org
X-OriginalArrivalTime: 07 Dec 2009 19:51:42.0212 (UTC) FILETIME=[B2BDF440:01CA7776]
Cc: alia.atlas@bt.com, ZININ Alex <Alex.Zinin@alcatel-lucent.sg>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 19:53:10 -0000

Dimitri,

I sent the e-mail a bit too fast, and mixed the two related drafts.  The
problem statement is indeed in the requirement draft. =20

Ning So
Lead Engineer
Enterprise Data Network and Traffic Planning
972-729-7905
=20

-----Original Message-----
From: So, Ning=20
Sent: Monday, December 07, 2009 1:13 PM
To: 'PAPADIMITRIOU Dimitri'; 'John G. Scudder'; 'rtgwg@ietf.org'
Cc: 'alia.atlas@bt.com'; 'ZININ Alex'
Subject: RE: Composite Link Requirements as WG document

Dimitri,

Both of your questions are related to the motivation of the draft.  From
carrier/operator's point of view, we have thought long and hard about
this, and we have detailed our motivations in the previous drafts,
although not in this one because we thought they were well understood
since we have presented it numerous times in several WGs and meetings.
I have copied and pasted what we had in the last draft below.  I think
it addressed your questions in detail.=20


Appendix A.  Problem Statements

   Two applications are described here that encounter problems when
   multiple parallel links are deployed between two routers in today's
   IP/MPLS networks.

A.1.  Incomplete/Inefficient Utilization

   An MPLS-TE network is deployed to carry traffic on RSVP-TE LSPs, i.e.
   traffic engineered flows.  When traffic volume exceeds the capacity
   of a single physical link, multiple physical links are deployed
   between two routers as a single backbone trunk.  How to assign LSP
   traffic over multiple links and maintain this backbone trunk as a
   higher capacity and higher availability trunk than a single physical
   link becomes an extremely difficult task for carriers today.  Three
   methods that are available today are described here.

   1.  A hashing method is a common practice for traffic distribution
       over multiple paths.  Equal Cost Multi-Path (ECMP) for IP
       services and IEEE-defined Link Aggregation Group (LAG) for
       Ethernet traffic are two of the widely deployed hashing based
       technologies.  However, two common occurrences in carrier
       networks often prevent hashing being used efficiently.  First,
       for MPLS networks carrying mostly Virtual Private Network (VPN)
       traffic, the incoming traffic are usually highly encrypted, so
       that hashing depth is severely limited.  Second, the traffic in
       an MPLS-TE network typically contain a certain number of traffic
       flows that have vast differences in the bandwidth requirements.
       Furthermore, the links may be of different speeds.  In those
       cases hashing can cause some links to be congested while others
       are partially filled because hashing can only distinguish the
       flows but not the flow rates.  A TE based solution better applies
       for these cases.  IETF has always had two technology tracks for
       traffic distribution: TE-based and non-TE based.  A TE based
       solution provides a natural compliment to non-TE based hashing
       methods.

   2.  Assigning individual LSPs to each link through constrained
       routing.  A planning tool can track the utilization of each link
       and assignment of LSPs to the links.  The lag time between
       measurement and action may be large relative to the fluctuations
       in LSP utilization, and the availability and performance of the
       planning tool are also important operational factors.
       Furthermore, the flexibility in response to failure scenarios is
       limited as summarized in the following.  To gain high
       availability, FRR [RFC4090] is used to create a bypass tunnel on
       a link to protect traffic on another link or to create a detour
       LSP to protect another LSP.  If BW is reserved for the bypass
       tunnels or the detour LSPs, the network will need to reserve a
       large amount of capacity for failure recovery, which reduces the
       capacity to carry other traffic.  If BW is not reserved for the
       bypass tunnels and the detour LSPs, the planning tool can not
       assign LSPs properly to avoid the congestion during link failure
       when there are more than two parallel links.  This is because
       during the link failure, the impacted traffic is simply put on a
       bypass tunnel or detour LSPs which does not have enough reserved
       bandwidth to carry the extra traffic during the failure recovery
       phase.  An alternative is to use prioritized queuing so that
       premium traffic sees good performance during a congestion
       interval.  The LSP sources will receive an RSVP-TE path error and
       reoptimize the new LSP .  After a configurable period of time the
       LSPs will reoptimize and all traffic will experience good
       performance.  However, it will not work well when support is
       needed for both RSVP-TE signaled and LDP signaled traffic.

   3.  Facility protection, also called 1:1 protection.  Dedicate one
       link to protect another link.  Only assign traffic to one link in
       the normal condition.  When the working link fails, switch
       traffic over the protection link.  This requires 50% capacity for
       failure recovery.  This works when there are only two links.
       Under the multiple parallel link condition, this causes
       inefficient use of network capacity because there is no
       protection capacity sharing.  In addition, due to traffic
       burstiness, having one link fully loaded and another link idle
       increases transport latency and packet loss, which lowers the
       link performance quality for transport.

   None of these methods satisfies carrier requirement either because of
   poor link utilization or poor performance.  This forces carriers to
   go with the solution of deploying single higher capacity link.
   However, a higher capacity link can be expensive as compared with
   parallel low capacity links of equivalent aggregate capacity; a high
   capacity link can not be deployed in some circumstances due to
   physical impairments; or the highest capacity link may not large
   enough for some carriers.

   An LDP network can encounter the same issue as an MPLS-TE enabled
   network when multiple parallel links are deployed as a backbone
   trunk.  An LDP network can have large variance in flow rates where,
   for example, the small flows may be carrying stock tickers at a few
   kbps per flow while the large flows can be near 10 Gbps per flow
   carrying machine to machine and server to server traffic from
   individual customers.  Those large traffic flows often cannot be
   broken into micro flows.  Therefore, hashing would not work well for
   the networks carrying such flows.  Without per-flow TE information,
   this type of network has even more difficulty to use multiple
   parallel links and keep high link utilization.

A.2.  Inefficiency/Inflexibility of Logical Interface Bandwidth
      Allocation

   Using logically-separate routing instances in some implementations
   further complicates the situation.  Dedicating separate physical
   backbone links, or, in the case of sharing of a single common link,
   dedicating a portion of the link, to each routing instance is not
   efficient.  Assume that each routing instance must have at least the
   capacity of a single link, and also must have equal access to unused
   capacity.  Then, for example, if there are 2 routing instances and 3
   parallel links and half of each link bandwidth is assigned to a
   routing instance, neither routing instance can support an LSP with
   bandwidth greater than half the link bandwidth.  The same problem is
   also present in the case of the sharing of a single common link using
   the dedicated logical interface and link bandwidth method.  An
   alternative in dealing with multiple parallel links is to assign a
   logical interface and bandwidth on each of the parallel physical
   links to each routing instance, which improves efficiency as compared
   to dedicating physical links to each routing instance.

   Note that the traffic flows and LSPs from these different routing
   instances effectively operate in a Ships-in-the-Night mode, where
   they are unaware of each other.  Inflexibility results if there are
   multiple sets of LSPs (e.g., from different routing instances)
   sharing one link or a set of parallel links, and at least one set of
   LSPs can preempt others, in this case more efficient sharing of the
   link set between the routing instances is highly desirable.

A.3.  Additional Functions Required Beyond Link Bundling

   A link bundle [RFC4201] is a collection of TE links.  It is a logical
   construct that represents a way to group/map the information about
   certain physical resources that interconnect routers.  The purpose of
   link bundle is to improve routing scalability by reducing the amount
   of information that has to be handled by OSPF/IS-IS.  Each physical
   link in the link bundle is an IGP link in OSPF/IS-IS if numbered link
   is used.  A link bundle only has the significance at the router
   control plane.  The mapping of LSP to component link in a bundle is
   determined at LSP setup time and this mapping does not change due to
   newly configured LSP/LDP traffic on the same component link.  A link
   bundle only applies to RSVP-TE signaled traffic, which implies no mix
   of RSVP-TE and LDP traffic on a same interface.  CTG can handle
   RSVP-TE and LDP signaled traffic.

   Link bundling does not support groups of links with different
   characteristics (e.g., bandwidth, latency).  Furthermore, link
   bundling only supports RSVP-TE signaled LSPs and not LDP signaled
   LSPs.


Ning So
Lead Engineer
Enterprise Data Network and Traffic Planning
972-729-7905
=20

-----Original Message-----
From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf
Of PAPADIMITRIOU Dimitri
Sent: Sunday, December 06, 2009 4:11 AM
To: John G. Scudder; rtgwg@ietf.org
Cc: alia.atlas@bt.com; ZININ Alex
Subject: RE: Composite Link Requirements as WG document

Hi,

Two comments on this document:

"Unlike a link bundle [RFC4201], the component links in a=20
composite link can have different properties such as cost=20
or capacity."

Component link "capacity" heterogeneity is "allowed" in 4201 I can
understand the potential limitation of identical TE metrics (for each
component) unfortunately limited explanation are given to sustain why it
should be addressed.

"This document describes a framework for managing aggregated=20
traffic over a composite link."
[...]
"To achieve the better component link utilization and avoid=20
component link congestion, the document describes some new
aspects on the traffic flow assignment to component links."

The document is specifically dealing to TE control but does not explain
why "measuring" component link capacity is assumed impossible (cf. 4201
Section 4) ?

Bottom-line: not clear if this document is intended to improve
applicability of bundling TE control in IP/MPLS or if the current
bundling approach is not fulfilling expected functionality (and this
document would outline the why/what). The issue is that the document
describes "modeling" but does not provide an answer to this question.=20

Thanks,
-dimitri.=20



> -----Original Message-----
> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20
> On Behalf Of John G. Scudder
> Sent: Tuesday, November 10, 2009 10:08 AM
> To: rtgwg@ietf.org
> Cc: alia.atlas@bt.com; ZININ Alex
> Subject: Composite Link Requirements as WG document
>=20
> Folks,
>=20
> At today's meeting we received a request to adopt draft-so-yong-mpls-=20
> ctg-requirement-00 as a working group document.  There was=20
> reasonably =20
> strong support in the room for doing so.  Please respond to the =20
> mailing list with your discussion, support or opposition (please do =20
> this even if you did so in person).  The deadline for comments is =20
> November 30.
>=20
> Note that accepting the document simply means that the working group =20
> would begin working on requirements.  It does not imply blanket =20
> acceptance of the document as it now stands.
>=20
> Thanks,
>=20
> --John
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>=20
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg