Re: [RAM] Crisper Terminology

Scott W Brim <swb@employees.org> Mon, 11 June 2007 20:05 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxq8S-0008Dd-Og; Mon, 11 Jun 2007 16:05:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxq8S-0008DY-7s for ram@iab.org; Mon, 11 Jun 2007 16:05:08 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxq8Q-0006Wa-Rz for ram@iab.org; Mon, 11 Jun 2007 16:05:08 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2007 13:05:06 -0700
X-IronPort-AV: i="4.16,409,1175497200"; d="scan'208"; a="162685172:sNHT43778340"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5BK56Mu027296; Mon, 11 Jun 2007 13:05:06 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5BK4ttf014077; Mon, 11 Jun 2007 20:05:02 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:04:58 -0700
Received: from [171.70.254.34] ([171.70.254.34]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:04:57 -0700
Message-ID: <466D7FF5.8060302@employees.org>
Date: Mon, 11 Jun 2007 13:01:41 -0400
From: Scott W Brim <swb@employees.org>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: [RAM] Crisper Terminology
References: <20070608162021.1266686AF0@mercury.lcs.mit.edu> <1061608D-5E5D-45E9-965C-9E66B4C41E95@extremenetworks.com> <466A4BCE.4010208@gmail.com>
In-Reply-To: <466A4BCE.4010208@gmail.com>
X-Enigmail-Version: 0.95.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jun 2007 20:04:58.0022 (UTC) FILETIME=[C92C6C60:01C7AC63]
Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: RJ Atkinson <rja@extremenetworks.com>, ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

On 06/09/2007 02:42 AM, Brian E Carpenter allegedly wrote:
> I'd be tempted to agree with that, but I just had occasion to
> review draft-ietf-ccamp-gmpls-addressing-07.txt, and found my head
> spinning rapidly on exactly this question.

The problem there is separation of planes.  Router and Forwarder are
somewhat independent, thus Control and Forwarding (Data) Plane are as
well.  In GMPLS you have an independent control plane, and an
independent control plane requires independent transport names.  The
IP component of control plane transport, has its own locators, and
forwards packets which carry in them identifiers of components of the
(possibly non-IP) forwarding plane.  I believe it's right to say that
the "addresses" in the forwarding plane are really identifiers, but it
depends how path setups are done.  However, it seems that those
identifiers are not only system identifiers but also interface or link
identifiers.

> Well, if we use OSI formalism, we'd have to say that the transport
> address is the network address concatenated with the port number.
> There was a fairly clear model for layered endpoint addressing in
> OSI, and it still a valid thinking aid IMHO.
> 
>     Brian
> 
> _______________________________________________
> RAM mailing list
> RAM@iab.org
> https://www1.ietf.org/mailman/listinfo/ram
> 

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram