Re: [CCAMP] Objective function draft

I agree with Julien.  (Sorry about the time zone delay)

Lyndon

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Julien Meuric
Sent: Tuesday, September 18, 2012 3:33 AM
To: Daniele Ceccarelli
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

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)

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp