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

[Julien Meuric <[e-mail]>]

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