Re: [CCAMP] Overlay model framework and context

[Iftekhar Hussain <[e-mail]>]

Agree with the comments about reusing some of the L3VPN like terminology. Unless the existing terminology PE/CE does not suffice, reusing the existing terminology will be less confusing.

BR,
Iftekhar
-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Wednesday, December 19, 2012 7:09 AM
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:[e-mail]]
>> 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.
>>>
>>>
>>>  
>>> ===================================
>>> DANIELE CECCARELLI
>>> System & Technology - PDU Optical & Metro
>>>
>>> Via E.Melen, 77
>>> Genova, Italy
>>> Phone [phone]
>>> Mobile [phone]
>>> [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>
> 
> 
>