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

[Daniele Ceccarelli <[e-mail]>]

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?

Cheers,
Daniele

>-----Original Message-----
>From: Julien Meuric [mailto:[e-mail]] 
>Sent: martedì 18 settembre 2012 17.53
>To: Daniele Ceccarelli
>Cc: Gert Grammel; George Swallow (swallow); [e-mail]
>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...
>
>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:[e-mail]]
>>>
>>> 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)
>> >
>
>
>