[CCAMP] R: R: Overlay model framework and context

"BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com> Wed, 19 December 2012 16:04 UTC

Return-Path: <sergio.belotti@alcatel-lucent.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B181021F8750 for <ccamp@ietfa.amsl.com>; Wed, 19 Dec 2012 08:04:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zWX3BIHiwEjy for <ccamp@ietfa.amsl.com>; Wed, 19 Dec 2012 08:04:28 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr []) by ietfa.amsl.com (Postfix) with ESMTP id 12C7021F86AC for <ccamp@ietf.org>; Wed, 19 Dec 2012 08:04:27 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com []) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBJG40Is004149 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Dec 2012 17:04:24 +0100
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([]) with mapi; Wed, 19 Dec 2012 17:04:09 +0100
From: "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>
To: Lou Berger <lberger@labn.net>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Date: Wed, 19 Dec 2012 17:04:08 +0100
Thread-Topic: R: [CCAMP] Overlay model framework and context
Thread-Index: Ac3eAT3mNvdtI0CaRt6+ssCD2aeTSgAAGexQ
Message-ID: <F050945A8D8E9A44A71039532BA344D822403FB364@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <4A1562797D64E44993C5CBF38CF1BE48042C3B@ESESSMB301.ericsson.se> <50CF764E.603@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045007@ESESSMB301.ericsson.se> <50D1D8A1.3060807@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045378@ESESSMB301.ericsson.se> <F050945A8D8E9A44A71039532BA344D822403FB33C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <50D1E347.2070602@labn.net>
In-Reply-To: <50D1E347.2070602@labn.net>
Accept-Language: it-IT, en-US
Content-Language: it-IT
acceptlanguage: it-IT, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on
Cc: CCAMP <ccamp@ietf.org>
Subject: [CCAMP] R: R: Overlay model framework and context
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: Wed, 19 Dec 2012 16:04:29 -0000


I misunderstood your assumption sorry, yes we agree in the definition for OE and OC but referring to PE and CE as helpful reference in the definition.


Belotti Sergio - System Architect
ALCATEL-LUCENT  Optics Division

-----Messaggio originale-----
Da: Lou Berger [mailto:lberger@labn.net] 
Inviato: mercoledì 19 dicembre 2012 16.55
Cc: Daniele Ceccarelli; CCAMP
Oggetto: Re: R: [CCAMP] Overlay model framework and context

	I'm not sure we're in agreement.  I'm fine with the OE/OC terminology.
 (which shouldn't be too surprising...)


On 12/19/2012 10:46 AM, BELOTTI, SERGIO (SERGIO) wrote:
> Hi Daniele,
> Thanks a lot for your effort to summarize mail exchange.
> About the content and definitions , I would support the Lou position.
> I think that in this context many of the concepts and definitions have been proposed , are already present in the IETF document.
> ONI definition and OE and OC definitions surely does not help to clarify scenarios that has been already debated in the VPN context .
> I support UNI only definition without to complicate proliferating with other interface definitions, and the usage of CE ,PE for nodes.
> Moreover I have also perplexity about the definition of Virtual Link and Virtual Topology.
> What are the difference and the added values to have very similar definitions to what already well defined in the MRN context ?
> Thanks again for your effort.
> Ciao
> Sergio
> Belotti Sergio - System Architect
> ALCATEL-LUCENT  Optics Division
> -----Messaggio originale-----
> Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Daniele Ceccarelli
> Inviato: mercoledì 19 dicembre 2012 16.32
> A: Lou Berger
> Oggetto: Re: [CCAMP] Overlay model framework and context
>  Lou, it's just a matter of convenience.
> Why should is say: 
> "customer interface/link between an OE and an OC in the overlay model context supporting both signaling and routing message exchange that is called UNI when only signaling is supported"
> ...when i could simply say: ONI? :)
> BR
> Daniele
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net] 
>> Sent: mercoledì 19 dicembre 2012 16.09
>> To: Daniele Ceccarelli
>> Cc: CCAMP
>> Subject: Re: [CCAMP] Overlay model framework and context
>> Daniele,
>> 	see below.
>> On 12/19/2012 5:56 AM, Daniele Ceccarelli wrote:
>>> Hi Lou,
>>> Plese find replies in line.
>>> BR
>>> Daniele
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: lunedì 17 dicembre 2012 20.45
>>>> To: Daniele Ceccarelli
>>>> Cc: CCAMP
>>>> Subject: Re: [CCAMP] Overlay model framework and context
>>>> Daniele,
>>>> 	Thanks for getting this on-list discussion going.  I have some 
>>>> comments and questions:
>>>> - So what's a "client layer network" in this context?  Perhaps you 
>>>> mean OC or "(overlay) customer layer"?
>>> Yes. The terms client layer and server layer are 
>> reminescences to be corrected.
>>>> - So what's a "server layer network" in this context?  Perhaps you 
>>>> mean OE or "(overlay) provider layer"?
>>> Again correct
>>>> - For OC, I'd thing referring back to a CE in the VPN context, and 
>>>> likewise to a PE for an OE, is helpful context.
>>> In the case of the interface we generally define the ONI as 
>> an overlay 
>>> interface that in a particular case is called UNI.
>> I have no idea what this means.  I suspect it relates to 
>> comments below, so will discuss there.
>>> I would
>>> apply the same method: those nodes are called Overlay Customer and 
>>> Overlay Edge and in the particular case of VPNs they are the 
>> CE and PE 
>>> respectively. What about that?
>> How about:
>> An OC is analogous to an L3VPN CE, and an OE is analogous to 
>> an L3VPN PE (with a provider based VPN).
>>>> - As you mention in the Appendix, (from the OC perspective) 
>> there is 
>>>> no difference between a virtual and real node (and 
>> presumably link as 
>>>> well).  Given this and your comment in 8, that the ONI can take the 
>>>> form of a UNI or include both signaling and routing (i.e., a 
>>>> peer/I-NNI or
>>>> E-NNI) what value is there in introducing the ONI term?  
>> Said another 
>>>> way, there's no specific term for the interface between a CE and PE 
>>>> in L3VPNs, so why do we need to introduce one in this context?
>>> We gave a name to the UNI, why don't giving to the ONI?
>> Because redundant/unnecessary terminology only obfuscates.
>> Why not customer interface/link? This has been sufficient for L3VPNs.
>>>> I think this same comment probably holds for the O-NNI 
>> (e.g., what's 
>>>> the name of the interface between providers which support L3VPN 
>>>> handoffs?)...
>>> I would suggest giving a name to that interface also in 
>> order to distinguish between an "internal" and an "external" 
>> link when multiple overlay provider network domains are present.
>> How about inter-provider interface/link? Again, this has been 
>> sufficient for L3VPNs.
>> Lou
>>>> Much thanks,
>>>> Lou
>>>> On 12/17/2012 6:17 AM, Daniele Ceccarelli wrote:
>>>>> Dear CCAMPers,
>>>>> In the last weeks several off-line discussions on the
>>>> Overlay model framework and related works took place. Some 
>>>> discussions led to some sort of agreemet among a small group of 
>>>> people, some others to a set a viable options, some others 
>> to totally 
>>>> open issues. I tried to summarize the output of such discussions 
>>>> below so to progress the discussions into a single thread on the WG 
>>>> ML.
>>>>> Please note that the aim of this mail is not to present a
>>>> well shaped and conclusive idea to the WG but rather to provide the 
>>>> basis for starting a discussion from a barely shaped idea (step 1) 
>>>> instead of starting it from scratch (step 0).
>>>>> In addition you can find attached a slide depicting a
>>>> proposal of the overlay scenario.
>>>>> Thanks,
>>>>> Daniele
>>>>> + Disclaimer:
>>>>>  1. Packet opto integration is often considered but the work
>>>> can be extented to any type of SC. Eg. TDM over LSC.
>>>>> + Terminology:
>>>>>  1. Virtual Link: A virtual link is a potential path between
>>>> two virtual or real network elements in a client layer network that 
>>>> is maintained/controlled in and by the server domain control plane 
>>>> (and as such cannot transport any traffic/data and protected from 
>>>> being de-provisioned) and which can be instantiated in the 
>> data plane 
>>>> (and then can carry/transport/forward traffic/data) preserving 
>>>> previously advertised attributes such as fate sharing information.
>>>>>  2.  Virtual Node: Virtual node is a collection of zero or
>>>> more server network  domain nodes that are collectively represented 
>>>> to the clients as a single node that exists in the client layer 
>>>> network and is capable of terminating of access, inter-domain and 
>>>> virtual links.
>>>>>  3.Virtual Topology: Virtual topology is a collection of one
>>>> or more virtual or real server network domain nodes that 
>> exist in the 
>>>> client layer network and are interconnected via 0 or more virtual 
>>>> links.
>>>>>  4. Overlay topology:  is a superset of virtual topologies
>>>> provided by each of server network domains, access and inter-domain 
>>>> links.
>>>>>  5. Access Link: Link between OC and OE. GMPLS runs on that
>>>> link. It can support any of the SCs supported by the GMPLS.
>>>>>  6. Overlay Customer (OC): Something like the CN in RFC4208
>>>> teminology  but (i) receiving virtual topology from the 
>> core network 
>>>> and requesting the set up of one of them or (ii) requesting the 
>>>> computation and establishment of a path accordingly to gien 
>>>> constraints in the core network and receiving the parameters 
>>>> characterizing such path. (ii) == UNI.
>>>>>  7. Overlay Edge (OE): Something like the EN in RFC4208 but
>>>> able to deal with (i) and (ii) above.
>>>>>  8. ONI : Overlay network interface: Interface allowing for
>>>> signaling and routing messages exchange between Overlay and  Core 
>>>> network. Routing information consists on virtual topology  
>>>> advertisement. When there is no routing adjacency across the  
>>>> interface it is equivalent to the GMPLS UNI defined in 4208.
>>>> Signaling messages are compliant with RFC4208. Information  related 
>>>> to path carachteristics, e.g. TE-metrics, collected  SRLG, 
>> path delay 
>>>> etc, either passed from OE to OC via  signaling after the LSP 
>>>> establishment in the core network or from OC to OE to be 
>> used as path 
>>>> computation constraints, fall  under the definition of 
>> signaling info 
>>>> and not routing info).
>>>>>  9. O-NNI (name to be found,maybe reused): Interface on the
>>>> links between different core networks in the overlay model 
>>>> environment, i.e. Between border OEs. Same features of the 
>> ONI apply 
>>>> to this interface. Could it be an E-NNI? A ONI? A new name 
>> is needed?
>>>>> + Statements
>>>>>  1. In the context of overlay model we are aiming to build
>>>> an overlay
>>>>> topology for the client network domains  2. The overlay
>>>> topology is comprised of:
>>>>>     a) access links (links connecting client NEs to the
>>>> server network domains). They can be PSC or LSC.
>>>>>     b) inter-domain links (links interconnecting server
>>>> network domains)   
>>>>>     c) virtual topology provided by the server network
>>>> domains. Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix 
>>>> (with a set of parameters e.g. SRLG, optical impairments, delay etc 
>>>> for each entry) describing connectivity between access links and 
>>>> virtual links.
>>>>>  3. In the context of overlay model we manage  hierarchy  
>> of overlay 
>>>>> topologies with overlay/underlay relationships  4. In the 
>> context of 
>>>>> overlay model multi-layering and inter-layer relationships
>>>> are peripheral at best, it is all about horizontal network 
>>>> integration  5. The overlay model assumes one instance for 
>> the client 
>>>> network and a separate instance for the server network and 
>> in the ONI 
>>>> case the server network also surreptitiously participates in the 
>>>> client network by injecting virtual topology information into it.
>>>>>  6. L1VPN (and LxVPN) in general is a service provided over
>>>> the ONI (it falls under the UNI case as no routing adjacency is in 
>>>> place between OC and OE).
>>>>> + Open issues/questions
>>>>>  1. PCE-PCEP - do we need to include considerations about
>>>> PCE and PCEP into the overlay framework context?
>>>>>  2. BGP-LS needs to be considered
>>>>>  3. Should potentials be included? E.g. I2RS?
>>>>> + Appendix:
>>>>> Some notes on the Virtual Node:
>>>>> 1.      Virtual Link Model along, sadly, does not scale 
>>>> because of N**2 problem. IP over ATM and single-segment PWs 
>> have the 
>>>> same issue, that's why people invented multi-segment PWs
>>>>> 2.      The only way to avoid full-mesh of Virtual Links is 
>>>> by having intermediate nodes interconnecting Virtual Links in the 
>>>> middle of the virtual topology
>>>>> 3.      These intermediate nodes cannot be real server 
>>>> domain switches, because, generally speaking:
>>>>>   a)Real switches belong to different layer network;
>>>>>   b)Real switches are named from different naming space
>>>>>   c)real switches individually may not have sufficient
>>>> resources to terminate virtual links (while a group of real 
>> switches 
>>>> collectively will have)
>>>>>   d)Presenting a group of real switches as a single virtual
>>>> node have better scalability qualities
>>>>> 4.      Even if you map a virtual node on a single real 
>>>> node, you need to keep in mind that real server domain 
>> switches are, 
>>>> generally speaking, blocking switches and as such must expose their 
>>>> connectivity matrices
>>>>> 5.      If you want to compute SRLG-disjoint paths that 
>>>> could potentially go through a real server domain switch, the 
>>>> latter's connectivity matrix must expose "internal" SRLGs, so that 
>>>> the two services traversing the switch will not simultaneously fail 
>>>> if a single internal element shared by the services fails
>>>>> 6.      If you walk through all cases that need to be 
>>>> addressed when you are traffic engineering topologies with blocking 
>>>> switches, you will understand that there is absolutely no 
>> difference 
>>>> between a virtual node and real blocking real node.
>>>>> 7.      Even in case of pure VL model, client NEs connected 
>>>> to server network domain must be upgraded so that they could 
>>>> understand the connectivity matrices advertised by the border nodes 
>>>> describing connectivity constraints between access links 
>> and virtual 
>>>> links they terminate.
>>>>> ===================================
>>>>> System & Technology - PDU Optical & Metro
>>>>> Via E.Melen, 77
>>>>> Genova, Italy
>>>>> Phone +390106002512
>>>>> Mobile +393346725750
>>>>> daniele.ceccarelli@ericsson.com
>>>>> www.ericsson.com
>>>>> This Communication is Confidential. We only send and receive
>>>> email on
>>>>> the basis of the term set out at www.ericsson.com/email_disclaimer
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> CCAMP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp