Re: [CCAMP] Overlay model framework and context

[Daniele Ceccarelli <[e-mail]>]

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