Re: [CCAMP] Objective function draft

"Ong, Lyndon" <Lyong@Ciena.com> Tue, 18 September 2012 14:27 UTC

Return-Path: <prvs=46084d3bd1=lyong@ciena.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 5665E21F8611 for <ccamp@ietfa.amsl.com>; Tue, 18 Sep 2012 07:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.265
X-Spam-Level:
X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 qI4GGPf0ghyr for <ccamp@ietfa.amsl.com>; Tue, 18 Sep 2012 07:27:31 -0700 (PDT)
Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id C067C21F860D for <ccamp@ietf.org>; Tue, 18 Sep 2012 07:27:31 -0700 (PDT)
Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q8IEPB1Y025339; Tue, 18 Sep 2012 10:27:29 -0400
Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 17erny0dyp-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Sep 2012 10:27:29 -0400
Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 18 Sep 2012 10:27:29 -0400
Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Tue, 18 Sep 2012 10:27:28 -0400
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: Julien Meuric <julien.meuric@orange.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Date: Tue, 18 Sep 2012 10:27:27 -0400
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: Ac2ViPuHvajUZUi2QUqmNo1l59hqDgAIJrfA
Message-ID: <A0B4FC0A5EFBD44585414760DB4FD274ABCADB58@MDWEXGMB02.ciena.com>
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com> <B5630A95D803744A81C51AD4040A6DAA26E0C5B495@ESESSCMS0360.eemea.ericsson.se> <50584DCE.5090407@orange.com>
In-Reply-To: <50584DCE.5090407@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-19190.007
X-TM-AS-Result: No--20.789800-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-18_01:2012-09-18, 2012-09-17, 1970-01-01 signatures=0
X-Proofpoint-Spam-Reason: safe
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] 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 14:27:32 -0000

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