Re: [CCAMP] Overlay model framework and context

Daniele Ceccarelli <> Wed, 19 December 2012 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7973221F8696 for <>; Wed, 19 Dec 2012 07:32:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.267
X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, HELO_EQ_SE=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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6x-HhK3yqkmo for <>; Wed, 19 Dec 2012 07:32:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 869D221F8621 for <>; Wed, 19 Dec 2012 07:32:03 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-e3-50d1ddf20586
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id FF.3B.10459.2FDD1D05; Wed, 19 Dec 2012 16:32:02 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 16:32:02 +0100
From: Daniele Ceccarelli <>
To: Lou Berger <>
Thread-Topic: [CCAMP] Overlay model framework and context
Thread-Index: Ac3cSA0EmhmMt2XQR3eDsLDm5eAESgAPpvQAAFPqDzAABwf3gAACrXmg
Date: Wed, 19 Dec 2012 15:32:01 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: it-IT, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje6nuxcDDJb+07B4MucGi0VH81sW ByaPJUt+Mnl82NTMFsAUxWWTkpqTWZZapG+XwJVx6tpv1oLvcRU7Npxha2D87tPFyMkhIWAi MXHXa2YIW0ziwr31bF2MXBxCAocYJQ4+/sAM4SxhlDh6tQHI4eBgE7CSeHIIrFlEQFHi68dF TCA2s4CUxN1bXYwgtrCAhcTatQcZIWosJZpWT2eFsN0k5ne1sYHYLAKqEpPWHAFbzCvgLTFh zkdWiF1HGSUeXVgB1sApoCFx8/oGsAZGAVmJCbsXMUIsE5e49WQ+E8TVAhJL9pyH+kBU4uXj f6wQtqLEzrPtzBD1ehI3pk5hg7C1JZYtfA21WFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZ xciem5iZk15uuIkRGCUHt/zW3cF46pzIIUZpDhYlcd4w1wsBQgLpiSWp2ampBalF8UWlOanF hxiZODilGhg1/xjPFljQeeWrX6ZXTcnCDVqRb3SvSCy57Xt+s+Zaz19Pb7g2Xu0+mv1u7b1M aQkJKRWRc/23SjTvTZilYPZpvl/1eVHBzKbFXIrOlzg4HTK/rM+5y7Ik0NOUcS/z4/0NZioS 3kZcebEFl44penmL7VebkLhOy9g1oNVB4X190buth7J+GyixFGckGmoxFxUnAgCe3tQ0YAIA AA==
Cc: CCAMP <>
Subject: Re: [CCAMP] Overlay model framework and context
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Dec 2012 15:32:05 -0000

 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? :)


>-----Original Message-----
>From: Lou Berger [] 
>Sent: mercoledì 19 dicembre 2012 16.09
>To: Daniele Ceccarelli
>Subject: Re: [CCAMP] Overlay model framework and context
>	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 []
>>> 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.
>>> 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 
>>> 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 
>>> 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
>>>> This Communication is Confidential. We only send and receive
>>> email on
>>>> the basis of the term set out at
>>>> _______________________________________________
>>>> CCAMP mailing list