Re: [CCAMP] UNI/NNI

[Julien Meuric <[e-mail]>]

Hi Daniele.

The phrase "different features (for the same protocol)" covers protocol 
fields and policies, which seems reasonable. I believe we agree on that.

Julien


On 09/19/2012 09:12, Daniele Ceccarelli wrote:
> 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]]
>>
>> 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)
>>
> >