Re: [CCAMP] Objective function draft

Daniele Ceccarelli <> Tue, 18 September 2012 12:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FA0F21E80BF for <>; Tue, 18 Sep 2012 05:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Nq582Wc8XIz for <>; Tue, 18 Sep 2012 05:12:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7616E21F8459 for <>; Tue, 18 Sep 2012 05:12:52 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-54-5058653f3f02
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 1C.01.11467.F3568505; Tue, 18 Sep 2012 14:12:48 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Tue, 18 Sep 2012 14:12:47 +0200
From: Daniele Ceccarelli <>
To: Julien Meuric <>
Date: Tue, 18 Sep 2012 14:12:45 +0200
Thread-Topic: [CCAMP] Objective function draft
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: it-IT, en-US
Content-Language: en-US
acceptlanguage: it-IT, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvra5DakSAwdnLTBZP5txgsViyaxmL xZ/Tf5ksbk9pYnRg8ZjyeyOrx5IlP5k8rjddZfdoeXaSLYAlissmJTUnsyy1SN8ugSvj4Uqj gn6Rij2vV7M0MG4T6GLk5JAQMJE4sXAiE4QtJnHh3nq2LkYuDiGBU4wS8w6uYYdwFjBK3Gl8 BVTFwcEmYCXx5JAPSIOIgI7E+fdn2EFsZoEaieuzzrKC2CwCqhI3Fk0BGyosoCvxc38nE0S9 nsTj3UvYIWwjiVf3HrKA2LwC4RK7Th9iglv85EA7M0iCU0BL4vvR7YwgNqOArMSE3YsYIZaJ S9x6Mh/qagGJJXvOM0PYohIvH/9jhaiXkfi16RsrRL2exI2pU9ggbG2JZQtfM0MsFpQ4OfMJ ywRGsVlIxs5C0jILScssJC0LGFlWMQrnJmbmpJcb6qUWZSYXF+fn6RWnbmIExtjBLb91dzCe OidyiFGag0VJnJcrab+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYDgZqlEV0TNO59TGZb dSpznbjXy4TrtXICv4/E7WCouPt5mvMN9zDFm6qzVx68tZpHScQ4h6/dsWGXZXHdpJwey/fL z7ter/g4e4mYyvt5NW92GuSxT5ktN89BSMBQnHn+FYX7bB8k5gVaf3746Mpcl5jpyRPehOl0 vRZ6pX/sSMqpSfys8nJKLMUZiYZazEXFiQDWoVyhfwIAAA==
Cc: "" <>
Subject: Re: [CCAMP] Objective function draft
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Sep 2012 12:12:53 -0000

Hi Julien,

Your argument is flawless, but if the only difference between UNI and NNI is the relationship between the two domains is it worth defining two different types of interface?

My attempt (a bit clumpy) was to associate to each type of interface a given set of properties and functionalities. This also solves the problem of using unappropriate or not well defined language.
- UNI: functionalies supported: A, B, C, -- Interface Properties: X, Y, Z
- E-NNI: functionalities supported: A, D, E -- Interface Properties: X, W

So that when you say UNI you automatically indentify certain properties and functionalities and when you say E-NNI different ones (not necessarily fully disjoint...A and X, for example, are in common)


>-----Original Message-----
>From: Julien Meuric [] 
>Sent: martedì 18 settembre 2012 12.33
>To: Daniele Ceccarelli
>Cc: Gert Grammel; George Swallow (swallow);
>Subject: Re: [CCAMP] Objective function draft
>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.
>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 
>> rather than routing, because it is not a topology info)