Re: [CCAMP] Overlay model framework and context

Daniele Ceccarelli <> Wed, 19 December 2012 10:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB10721F8801 for <>; Wed, 19 Dec 2012 02:56:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=0.873, 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 NbZ7fsFz1mX8 for <>; Wed, 19 Dec 2012 02:56:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C85A421F8821 for <>; Wed, 19 Dec 2012 02:56:34 -0800 (PST)
X-AuditID: c1b4fb30-b7f736d0000010de-90-50d19d619092
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 13.62.04318.16D91D05; Wed, 19 Dec 2012 11:56:33 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 11:56:33 +0100
From: Daniele Ceccarelli <>
To: Lou Berger <>
Thread-Topic: [CCAMP] Overlay model framework and context
Thread-Index: Ac3cSA0EmhmMt2XQR3eDsLDm5eAESgAPpvQAAFPqDzA=
Date: Wed, 19 Dec 2012 10:56:32 +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+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvjW7i3IsBBp9Wy1o8mXODxaKj+S2L A5PHkiU/mTw+bGpmC2CK4rJJSc3JLEst0rdL4MrYe+46S8GRwIovp+6yNTBudupi5OCQEDCR +LiQu4uRE8gUk7hwbz1bFyMXh5DAIUaJDf/PskM4SxglrvdeZgZpYBOwknhyyAekQURAUeLr x0VMIDazgJTE3VtdjCC2sICFxNq1BxkhaiwlmlZPZ4WwrSSe9b4Aq2cRUJV48PAAO4jNK+At sWzSYxYQW0ggVeLEnkPMIDangIpEx+UVbCA2o4CsxITdixghdolL3HoynwniaAGJJXvOM0PY ohIvH/9jhbAVJT6+2gdVrydxY+oUNghbW2LZwtfMEHsFJU7OfMIygVFsFpKxs5C0zELSMgtJ ywJGllWM7LmJmTnp5eabGIERcnDLb4MdjJvuix1ilOZgURLnDXe9ECAkkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qBUaR9DU+WQWWCMV9W1GVjpcxk94sfjv389Nr2T0vVxxu7jBIFo1MuZl6T eLs+faGVYdx3l/b6rOfVTwodkpy0ygqt7vqZ3Hh8a4Pzlz4Zi7+a+yUM9v6dse34g+klkZsm vZH4dfnzmauZviovvp3+WvX+bVJR7sIctgsGC7fc8p2duSik/UlvjhJLcUaioRZzUXEiAP7V nVdeAgAA
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 10:56:37 -0000

Hi Lou,

Plese find replies in line.


>-----Original Message-----
>From: Lou Berger [] 
>Sent: lunedì 17 dicembre 2012 20.45
>To: Daniele Ceccarelli
>Subject: Re: [CCAMP] Overlay model framework and context
>	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 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?

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

>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.

>Much thanks,
>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
>> This Communication is Confidential. We only send and receive 
>email on 
>> the basis of the term set out at
>> _______________________________________________
>> CCAMP mailing list