Re: [CCAMP] UNI/NNI (was: Objective function draft)

Daniele Ceccarelli <> Wed, 19 September 2012 07:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB07721F8629 for <>; Wed, 19 Sep 2012 00:12:22 -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 8zxgGTSTq968 for <>; Wed, 19 Sep 2012 00:12:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9F05421F8644 for <>; Wed, 19 Sep 2012 00:12:21 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-f3-505970536271
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 08.C9.17130.35079505; Wed, 19 Sep 2012 09:12:20 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Wed, 19 Sep 2012 09:12:19 +0200
From: Daniele Ceccarelli <>
To: Julien Meuric <>
Date: Wed, 19 Sep 2012 09:12:18 +0200
Thread-Topic: [CCAMP] UNI/NNI (was: Objective function draft)
Thread-Index: Ac2Vtb248klpKt5zTqO5OibMqqLQWAAf1+ig
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+JvrW5IQWSAwZLDrBZP5txgsViyaxmL xZ/Tf5ksbk9pYnRg8ZjyeyOrx5IlP5k8rjddZfdoeXaSLYAlissmJTUnsyy1SN8ugSvjxbt/ bAX9shUbdk5mbWC8Jd7FyMEhIWAisW2dVhcjJ5ApJnHh3nq2LkYuDiGBU4wSCxfOZ4dwFjBK 3Lu0mwWkgU3ASuLJIR+QBhEBHYnz78+wg9jMAjUS12edZQWxWQRUJd4194PFhQVsJBqmvmGH qLeV+LCxmQ3CNpLYtWw1C4jNKxAusa2rHWrxDiaJ5ae7mUESnAJaEk9PfmQCsRkFZCUm7F7E CLFMXOLWk/lMEFcLSCzZc54ZwhaVePn4HytEvYzEr03fWCHq9SRuTJ3CBmFrSyxb+JoZYrGg xMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsopRODcxMye93FwvtSgzubg4P0+vOHUTIzDGDm75 bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw+vomSojM0NIx YlzmEvSgP/j++Q9CfBq/G/ukj++1zlnqdjXzgXlyCtfGDTfOqnLzHmcWbg4r/ro0/pjFm5rC BQe+m7z55CAmtWupn+gzuSD12ktHF13/nvql7Wh5vHeu38GWmXX7L6RfmZvm5ZKmUJkQcpV9 3r4vpS/fGZzcIWQbw5SVLnxLiaU4I9FQi7moOBEAucoCSX8CAAA=
Cc: "" <>
Subject: Re: [CCAMP] UNI/NNI (was: 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: Wed, 19 Sep 2012 07:12:22 -0000

Ciao Julien,

The key word in your reply is "tune". Ok, maybe having different protocols on different interface could be a too coarse distinction among interfaces, but at least i would expect different features for the same protocols on the different interfaces. DO you agree with me?


>-----Original Message-----
>From: Julien Meuric [] 
>Sent: martedì 18 settembre 2012 17.53
>To: Daniele Ceccarelli
>Cc: Gert Grammel; George Swallow (swallow);
>Subject: Re: [CCAMP] UNI/NNI (was: Objective function draft)
>Ciao Daniele.
>Your intend to propose definitions was nice. I also believe 
>that the ITU-T has identified some particular reference points 
>which already have a functional definition (in G.8080?).
>I think it is worth defining protocols that I can 
>enable/disable/tune between my network elements.  I am not 
>shocked if different reference points have protocols in 
>common: I suspect this is the goal of common control...
>Le 18/09/2012 14:12, Daniele Ceccarelli a écrit :
>> 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.
>> E.g.
>> - 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)
>> Cheers,
>> Daniele
>>> -----Original Message-----
>>> From: Julien Meuric []
>>> 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 
>>> 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)
>> >