Re: [CCAMP] Overlay model framework and context

Daniele Ceccarelli <> Wed, 19 December 2012 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E036721F859C for <>; Wed, 19 Dec 2012 08:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.35
X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.499, 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 vc27DpA3TY7x for <>; Wed, 19 Dec 2012 08:23:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DBEAC21F8449 for <>; Wed, 19 Dec 2012 08:23:53 -0800 (PST)
X-AuditID: c1b4fb25-b7fb26d000006129-75-50d1ea18aed3
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 24.AB.24873.81AE1D05; Wed, 19 Dec 2012 17:23:52 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 17:23:52 +0100
From: Daniele Ceccarelli <>
To: Lou Berger <>
Thread-Topic: [CCAMP] Overlay model framework and context
Thread-Index: Ac3cSA0EmhmMt2XQR3eDsLDm5eAESgAPpvQAAFPqDzAABwf3gAACrXmg///3AQD//+dnsA==
Date: Wed, 19 Dec 2012 16:23:50 +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+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvja7Eq4sBBvNWKVk8mXODxaKj+S2L A5PHkiU/mTw+bGpmC2CK4rJJSc3JLEst0rdL4Mr4e/I2W8G5rIotk3YzNjCeCuti5OSQEDCR WLLoCyOELSZx4d56ti5GLg4hgUOMErN+nGOEcJYwSsx9c5i5i5GDg03ASuLJIR+QBhEBRYmv HxcxgdjMAlISd291gQ0SFrCQWLv2ICNEjaVE0+rprCCtIgJhEt8vp4CYLAKqEpO2BXcxsnPw CnhLrLGG2LOUSeLTtHvsII2cAhoSzUc/MYPYjAKyEhN2L2KEWCQucevJfCaIiwUkluw5zwxh i0q8fPyPFcJWlNh5tp0Zol5P4sbUKWwQtrbEsoWvweK8AoISJ2c+YZnAKDYLydhZSFpmIWmZ haRlASPLKkb23MTMnPRyo02MwOg4uOW36g7GO+dEDjFKc7AoifOGu14IEBJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cC47ny76nx7MQ+1ZVUrOZumf4n4n9+gp/RsaUT0DguxZUcsDidN2RDd Fa6+5vipQy7arj43yjfM2tf77ML38ytS791UfxpdcNjv/z+PBXNkLvx4Zr8m9T/f148iPV3S 7NayDTUFCV1VTQl+j48+fpBpHXVG9vMM8SN8C/Oet32w0Z+x+Efn/sZgJZbijERDLeai4kQA 7r7qwFwCAAA=
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 16:23:57 -0000

Basically yes; being fussy i would say:

For the signaling+routing(normal case):
	LB) customer interface with signaling and routing
For the UNI case:
 	LB) customer interface with UNI


>-----Original Message-----
>From: Lou Berger [] 
>Sent: mercoledì 19 dicembre 2012 16.54
>To: Daniele Ceccarelli
>Subject: Re: [CCAMP] Overlay model framework and context
>	If ONI is a superset (i.e., covers all cases), what's 
>the difference.
>So the terminology options are:
>For the signaling+routing(normal case):
>	LB) customer interface with signaling and routing
>	DC) ONI with signaling and routing
>For the UNI case:
> 	LB) customer interface with UNI
>	DC) ONI with UNI
>On 12/19/2012 10:32 AM, Daniele Ceccarelli wrote:
>>  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 []
>>> 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 []
>>>>> 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 
>>>>> 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 
>>>>> 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