Re: [CCAMP] Input for Terminology discussion: UNI definitions across different SDOs

Dieter Beller <Dieter.Beller@alcatel-lucent.com> Thu, 07 November 2013 23:19 UTC

Return-Path: <Dieter.Beller@alcatel-lucent.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 C2BFE11E80E2 for <ccamp@ietfa.amsl.com>; Thu, 7 Nov 2013 15:19:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.477
X-Spam-Level:
X-Spam-Status: No, score=-5.477 tagged_above=-999 required=5 tests=[AWL=1.210, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbIBWCqwcP4O for <ccamp@ietfa.amsl.com>; Thu, 7 Nov 2013 15:19:44 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BCE0B11E81BE for <ccamp@ietf.org>; Thu, 7 Nov 2013 15:19:44 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rA7NJdmO011987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2013 17:19:40 -0600 (CST)
Received: from destgsu0709.de.alcatel-lucent.com (slsv7at.de.alcatel-lucent.com [149.204.245.107]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rA7NJbU1012506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Nov 2013 00:19:38 +0100
Received: from [135.244.20.63] (beller.lra.lucent.com [135.244.20.63]) (authenticated bits=0) by destgsu0709.de.alcatel-lucent.com (8.14.3/8.13.8) with ESMTP id rA7NJXHa007354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Nov 2013 00:19:36 +0100 (CET)
Message-ID: <527C2005.4030407@alcatel-lucent.com>
Date: Fri, 08 Nov 2013 00:19:33 +0100
From: Dieter Beller <Dieter.Beller@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Zhangxian (Xian)" <zhang.xian@huawei.com>, Oscar Go nzález de Dios <ogondio@tid.es>, CCAMP <ccamp@ietf.org>
References: <CEA12928.23608%ogondio@tid.es> <C636AF2FA540124E9B9ACB5A6BECCE6B263E04AB@szxeml510-mbx.china.huawei.com>
In-Reply-To: <C636AF2FA540124E9B9ACB5A6BECCE6B263E04AB@szxeml510-mbx.china.huawei.com>
X-SubSwitch: [CCAMP]; [CCAMP]
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: Re: [CCAMP] Input for Terminology discussion: UNI definitions across different SDOs
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: Thu, 07 Nov 2013 23:19:50 -0000

Hi all,

https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.8080-201202-I%21%21PDF-E&type=items" rel="nofollow">ITU-T Recommendation G.8080 is probably the most appropriate reference as far as the existing UNI definitions are
concerned from a CCAMP perspective. The OIF UNI/E-NNI work was based on the architecture and definition of the
UNI/E-NNI reference points in G.8080.

Please note that there is no UNI protocol defined to convey reachability information - the assumption was that this
information needs to be configured on the CE device (UNI-C side). A protocol for conveying this information is
certainly something that can be considered as a future add-on. Policy rules are required on the network side of the
UNI as to what reachbility information should be provided to a specific CE device (-->VPNs).


Thanks,
Dieter


On 07.11.2013 22:33, Zhangxian (Xian) wrote:

Thank you, Oscar. It indeed helps me to understand the UNI better.

 

Previously I thought the UNI defintion would include allowing for reachability information across this interface. Clearly, it DOES NOT from the text you provide below.

 

So, i double-checked RFC4208, it turns out that this "reachability information" is mentioned when talking about overlay model:

 

" In the overlay model, the core-nodes act more as a closed system. The edge-nodes do not participate
  in the routing protocol instance that runs among the core nodes; in particular, the edge-nodes are unaware

of the topology of the core-nodes.  There may, however, be a routing protocol interaction between
   a core-node and an edge-node for the exchange of reachability information to other edge-nodes."

Hope this helps a bit on clarification and ongoing discussion.

 

Regards,

Xian


发件人: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] 代表 Oscar González de Dios [ogondio@tid.es]
发送时间: 2013年11月8日 3:25
收件人: CCAMP
主题: [CCAMP] Input for Terminology discussion: UNI definitions across different SDOs

Hi all,

As inputs for the terminology discussions, please find bellow a set of definitions for UNI coming from different SDOs (with a short reference, they are easy to find with the number):

[G.807] (ITU-T): "User-Network Interface for the control plane (UNI): A bidirectional signaling interface between service requester and service provider control plane entities."

In the same document: "UNI: This interface supports, as a minimum, the following information elements:
? End-point name and address;
? Authentication and connection admission control;
? Connection service messages.”

[G.8081] (ITU-T): "user-network interface for the control plane (UNI): An UNI is a bidirectional signaling interface between service requester and service provider control plane entities.”

[G.8080] (ITU-T): “UNI
Information flows expected across the UNI reference point support the following functions:
- call control
- resource discovery
- connection control
- connection selection.
Note, there is no routing function associated with the UNI reference point. Additional functions such as security and authentication of calls, or enhanced directory services,
may be added to this basic set of functions."

[RFC3717]: “The client-optical internetwork interface (UNI) represents a service boundary between the client (e.g., IP router) and the optical network.  The client and server (optical network) are essentially two different roles: the client role requests a service connection from a server; the server role establishes the connection to fulfill the service request — provided all relevant admission control conditions are satisfied.”

   [OIF UNI1.0]: UNI: “The service control interface between a client device and the transport network.”
 UNI-C: ”The logical entity that terminates UNI signalling on the client device side.”
UNI-N: “The logical entity that terminates UNI signalling on the transport network side.”

       [MEF 11]: “The MEF UNI is a reference point for all interactions between Subscribers of MEF defined services and the MEN Service Provider.

Hope it helps in the discussions,

Best Regards,

Oscar







Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx" rel="nofollow">http://www.tid.es/ES/PAGINAS/disclaimer.aspx


_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp