IETF Logo Mail Archive

Re: [mpls] Review: draft-ietf-mpls-tp-identifiers-06- Tunnel Identifier

George Swallow <swallow@cisco.com> Fri, 01 July 2011 18:39 UTC

Return-Path: <swallow@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8725211E8160; Fri, 1 Jul 2011 11:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.202
X-Spam-Level:
X-Spam-Status: No, score=-109.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go2mKgB64xYW; Fri, 1 Jul 2011 11:39:42 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 99DCE11E8155; Fri, 1 Jul 2011 11:39:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=2976; q=dns/txt; s=iport; t=1309545582; x=1310755182; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=ktvI87/7QxpdUHJ0OIypNafkVxzs7TYc05ksGpmdHfQ=; b=Xc9afFpspG2brY2XgnyWZwYPsRJTO3rTfTUCRAeYjgaPiFoak4REw3R7 +JuANdIQk+QW5tIhpcsPOrWssEVGNJkf7ZZzV/8TPRKISent9I7YhM70G Nk6LB8PIwUKFnz2bHpG6NvmKMTqVL/wb3SwYZV7F5hR0A4CttadY2Fk7X A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAAgTDk6tJXG+/2dsb2JhbABSglGkQm53iHmjIZ1shjIEkjKEf4tO
X-IronPort-AV: E=Sophos; i="4.65,460,1304294400"; d="scan'208,217"; a="351609598"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2011 18:39:42 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p61IdfDK011177; Fri, 1 Jul 2011 18:39:41 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 13:39:41 -0500
Received: from 10.86.244.99 ([10.86.244.99]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Jul 2011 18:39:41 +0000
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Fri, 01 Jul 2011 14:39:40 -0400
From: George Swallow <swallow@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, IETF discussion list <ietf@ietf.org>, mpls@ietf.org
Message-ID: <CA338CAC.1110E%swallow@cisco.com>
Thread-Topic: [mpls] Review: draft-ietf-mpls-tp-identifiers-06- Tunnel Identifier
Thread-Index: Acw37/Of5BdGrxOFR9KA3LaJwlR13QALkjBa
In-Reply-To: <4E0DC68F.2060306@joelhalpern.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3392375980_148694742"
X-OriginalArrivalTime: 01 Jul 2011 18:39:41.0398 (UTC) FILETIME=[3D354F60:01CC381E]
Subject: Re: [mpls] Review: draft-ietf-mpls-tp-identifiers-06- Tunnel Identifier
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2011 18:39:43 -0000

The primary motivation is to allow for a compact form for the Tunnel MEP_ID.
A secondary motivation is compatibility with existing MPLS/GMPLS Session
objects.

...George


On 7/1/11 9:07 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

> In performing a gen-art review of this document, which seems quite good
> over all, I noticed a minor question, but did not remember to include it
> in my gen-art review.
> 
> The defines a Tunnel-Identifier, identifying the end-point of a tunnel
> within a node.
> That identifier is defined as 16 bits.
> In one sense, that seems sufficient.  But it is more restrictive than
> the number of parallel LSPs that the node could be an end-point for (by
> a factor of 16.)  So it seems that there ought to at least be an
> explanation for the mismatch.
> 
> Thank you,
> Joel
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

v2.23.0 | Report a Bug | By Email