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

Julien Meuric <julien.meuric@orange.com> Tue, 18 September 2012 15:53 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 EF5C321F8790 for <ccamp@ietfa.amsl.com>; Tue, 18 Sep 2012 08:53:27 -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 A04Jodn8D1ha for <ccamp@ietfa.amsl.com>; Tue, 18 Sep 2012 08:53:27 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF5021F8783 for <ccamp@ietf.org>; Tue, 18 Sep 2012 08:53:26 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EF861411106; Tue, 18 Sep 2012 17:53:25 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id E4AA84110C5; Tue, 18 Sep 2012 17:53:25 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Sep 2012 17:53:25 +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 17:53:25 +0200
Message-ID: <505898F4.3080004@orange.com>
Date: Tue, 18 Sep 2012 17:53:24 +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> <50584DCE.5090407@orange.com> <B5630A95D803744A81C51AD4040A6DAA26E0CC2089@ESESSCMS0360.eemea.ericsson.se>
In-Reply-To: <B5630A95D803744A81C51AD4040A6DAA26E0CC2089@ESESSCMS0360.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 18 Sep 2012 15:53:25.0422 (UTC) FILETIME=[BCE2ECE0:01CD95B5]
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] UNI/NNI (was: 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 15:53:28 -0000

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...

Regards,

Julien


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 [mailto:julien.meuric@orange.com]
>>
>> 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)
> >