IETF Logo Mail Archive

Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03

Tony Li <tony.li@tony.li> Wed, 23 February 2011 19:10 UTC

Return-Path: <tony.li@tony.li>
X-Original-To: rtgwg@core3.amsl.com
Delivered-To: rtgwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A8F3A6956 for <rtgwg@core3.amsl.com>; Wed, 23 Feb 2011 11:10:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level:
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k40ER2yjkihw for <rtgwg@core3.amsl.com>; Wed, 23 Feb 2011 11:10:56 -0800 (PST)
Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 7CC9E3A6940 for <rtgwg@ietf.org>; Wed, 23 Feb 2011 11:10:55 -0800 (PST)
Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta01.emeryville.ca.mail.comcast.net with comcast id BWqV1g0071HpZEsA1XBjz0; Wed, 23 Feb 2011 19:11:43 +0000
Received: from dhcp-171-70-245-59.cisco.com ([171.70.245.59]) by omta14.emeryville.ca.mail.comcast.net with comcast id BXBE1g00l1Hd52b8aXBQ3e; Wed, 23 Feb 2011 19:11:38 +0000
Subject: Re: WGLC completed on draft-ietf-rtgwg-cl-requirement-03
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Tony Li <tony.li@tony.li>
In-Reply-To: <OF942B8E41.DE643A2A-ON48257840.00606490-48257840.00649D1C@zte.com.cn>
Date: Wed, 23 Feb 2011 11:11:14 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B0DEE77C-F025-47E0-A8C9-CA558FBDDD86@tony.li>
References: <OF942B8E41.DE643A2A-ON48257840.00606490-48257840.00649D1C@zte.com.cn>
To: fu.xihua@zte.com.cn
X-Mailer: Apple Mail (2.1082)
Cc: rtgwg-bounces@ietf.org, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Area Working Group <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: Wed, 23 Feb 2011 19:10:58 -0000

Hi Xihua,

> I think we may catch the solution from rfc4201 and draft-ietf-mpls-explicit-resource-control-bundle-08 for bandwidth. 
> For latency, thert is a description about it in draft-wang-ccamp-latency-te-metric-02. There may be two choice . 
> 1. "When the composite link is advertised into IGP, the latency of composite link should be the range (e.g., at least minimum and maximum) latency value of all component links." - comment from Dave 
> 2. " When the composite link is advertised into IGP, the latency of composite link should be the maximum latency value of all component links." 


Yes, these possible solutions fall into the variations where you transmit only partial information in the IGP.  In these cases, the head-end has insufficient information to determine whether a particular path can support its bandwidth, delay, and jitter requirements.  Again, this leads to crankback.

Tony

v2.23.0 | Report a Bug | By Email