Re: [CCAMP] Objective function draft

Julien Meuric <julien.meuric@orange.com> Tue, 18 September 2012 10:32 UTC

Return-Path: <julien.meuric@orange.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF06021F84F3 for <ccamp@ietfa.amsl.com>; Tue, 18 Sep 2012 03:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 7iWvVrwjCcqq for <ccamp@ietfa.amsl.com>; Tue, 18 Sep 2012 03:32:51 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29021F841D for <ccamp@ietf.org>; Tue, 18 Sep 2012 03:32:51 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6972E5D89D9; Tue, 18 Sep 2012 12:32:49 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5AD975D894A; Tue, 18 Sep 2012 12:32:49 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Sep 2012 12:32:48 +0200
Received: from [10.193.71.236] ([10.193.71.236]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Sep 2012 12:32:48 +0200
Message-ID: <50584DCE.5090407@orange.com>
Date: Tue, 18 Sep 2012 12:32:46 +0200
From: Julien Meuric <julien.meuric@orange.com>
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com> <B5630A95D803744A81C51AD4040A6DAA26E0C5B495@ESESSCMS0360.eemea.ericsson.se>
In-Reply-To: <B5630A95D803744A81C51AD4040A6DAA26E0C5B495@ESESSCMS0360.eemea.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Sep 2012 10:32:48.0882 (UTC) FILETIME=[F303DD20:01CD9588]
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Objective function draft
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2012 10:32:51 -0000

Hi Daniele.

That is a good idea to bring back this issue we did not have time to 
discuss in details in Vancouver.

As far as I used to understand:
- UNI stands for User-to-Network, which refers to client-server 
relationship;
- NNI stands for Network-to-Network, which refers to inter-domain 
relationship within a common technology.

I believe the protocols we use on those interfaces is orthogonal to 
their type. E.g. one can do signaling only over an E-NNI; building an 
IGP-TE adjacency on the tributary links (UNI) of my WDM network does not 
transmute my UNI into an NNI. Boundaries are not defined with respect to 
control protocols, in CCAMP we put protocols between network nodes, 
including boundaries, we do not change boundary names...
That is also why I prefer to use accurate phrases such as "signaling 
protocol/RSVP-TE" and "IGP", rather than "UNI" or "NNI" acronyms, which 
are sometimes too loose for a protocol specification context like CCAMP.

Cheers,

Julien


On 09/18/2012 09:19, Daniele Ceccarelli wrote:
> Fully agree on the second part of your statement. At the time of RFC4208 the UNI allowed the exchange of signaling and routing messages. Now that we're defining also the E-NNI i would prefer to have:
>
> - UNI: signaling only
> - E-NNI: signaling AND routing (i would prefer to call it reachability rather than routing, because it is not a topology info)