Re: [CCAMP] Overlay model framework and context

[Gert Grammel <[e-mail]>]

Daniele,

I am not suggesting to use all of them. However in order to pick one, it would be handy to give each option a name so that we can speak about it in unambiguous terms. I am pretty sure that at this point my favorite is different from somebody else's favorite. So labeling the choices should help.

Gert

-----Original Message-----
From: Daniele Ceccarelli [mailto:[e-mail]] 
Sent: Montag, 17. Dezember 2012 16:03
To: Gert Grammel; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

I was suggesting to pick one of them :-)

Defining and using all of them would surely end up in a mess.

Cheers,
Daniele 

>-----Original Message-----
>From: Gert Grammel [mailto:[e-mail]]
>Sent: lunedì 17 dicembre 2012 15.34
>To: Daniele Ceccarelli; CCAMP
>Subject: Re: [CCAMP] Overlay model framework and context
>
>Honestly,
>
>If there are three ways of doing it, I first would like to define 3 
>unambiguous terms to name them.
>After that we can decide what makes most sense.
>A) doesn't look scalable
>B) is better but still creates tons of links
>C) scales best but connectivity needs to be taken into account.
>
>If we name A "virtual client link" VCL, then B could be a "virtual 
>attachment link" VAL and C a "virtual topological link" VTL.
>
>Gert
>
>
>
>________________________________________
>From: Daniele Ceccarelli
>Sent: Monday, December 17, 2012 3:13:14 PM
>To: Gert Grammel; CCAMP
>Subject: RE: [CCAMP] Overlay model framework and context
>
>Hi Gert,
>
>Excellent catch. I totally missed it.
>
>Then we have two options for Virtual links definition...but thinking a 
>little bit more of it, there are actually 3 of them.
>
>OC1                               OC2
>  \    +---+IF2       IF3+---+    /
>   \IF1|OE1|-------------|OE2|IF4/
>       +---+             +---+
>
>A) Virtual link is from OC1 to OC2
>B) Virtual link is from IF1 to IF4
>C) Virtual link is from IF2 to IF3
>
>Defining the virtual link as from IF2 to IF3 would need also to include 
>the connectivity matrices of OE1 and OE2, while from IF1 to IF4 would 
>remove the need for them as the information related to the connectivity 
>matrix is already implied into the virtual link. Am i missing 
>something?
>
>What would you suggest as the more reasonable definition?
>
>Cheers,
>Daniele
>
>
>>-----Original Message-----
>>From: Gert Grammel [mailto:[e-mail]]
>>Sent: lunedì 17 dicembre 2012 14.27
>>To: Daniele Ceccarelli; CCAMP
>>Subject: Re: [CCAMP] Overlay model framework and context
>>
>>Daniele,
>>
>>Thank you for summarizing the current state of discussion. To move 
>>forward and to encourage comments, let me point to some of the issues 
>>that are debated:
>>
>>1) Virtual Link: in the terminology statement a virtual link seems to 
>>connect two client elements. However later on the 3) virtual topology 
>>is composed of access links and virtual links. Hence. Virtual links 
>>connect server nodes, not client nodes. By doing so, segments (AL and
>>VL) are created.
>>2) The scalability consideration in the appendix for VL is based on 
>>terminology 1) rather than on virtual topology 3).
>>This way it doesn't describe then the  scalability of a virtual 
>>topology (which doesn't necessitate a full mesh) but rather that of a 
>>virtual node (which implies a full connectivity matrix).
>>
>>To sum up:
>>1) we have to come up with a crisp definition of a VL in a virtual 
>>topology that is different from a terminology 1) VL.
>>Here is a gap
>>2) A Model based on a vitual node or 'terminology 1) links'
>>create n**2 problems on client side and does not scale.
>>3) 'VNT'-virtual-links 3) and access links are supposed to
>address the
>>scaling problem. We need to clean up our terminology. 
>Otherwise we end
>>up associating limitations of terminology 1) links with
>VNT-links that
>>address those limitations.
>>
>>Now looking at the appendix it sadly reflects the terminology
>confusion
>>and jumps to assessment and conclusions. That's unfortunate:
>>
>>The first line says:
>>Some notes on the Virtual Node:
>>1.      Virtual Link Model along, sadly,
>>--> is it now about virtual nodes or virtual links or VNT links?
>>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
>>--> that's why access links are so useful. They end at server nodes 
>>--> which are connected via virtual links
>>3.      These intermediate nodes cannot be real server domain
>>switches, because, generally speaking:
>>--> in case of VNT-VLs no intermediate nodes are necessarily required
>>4.  --> No need to comment, this way doesn't scale anyway.
>>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
>>--> who is 'you' that computes? A client selects among VNT
>>virtual links based on exposed SRLGs, VLs are computed by the server 
>>with full knowledge of constraints. So what does an 'internal' SRLG 
>>mean to a server path computation?
>>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.
>>--> I suggest to model a complete network of say 5 nodes in a
>>single VN and compare it with the model of a single real node.
>>
>>--> The assessments made have used a terminology definition
>>that doesn't really capture the case made for VNT-VLs.
>>That's why I would have had appreciated to split definitions and work 
>>items agreed among a group from individual assessments in separate 
>>emails.
>>Nevertheless I consider the first part of your email (all except the
>>appendix) as a good starting point for further clarification.
>>
>>Gert
>>________________________________________
>>From: [e-mail] on behalf of Daniele Ceccarelli
>>Sent: Monday, December 17, 2012 12:17:08 PM
>>To: CCAMP
>>Subject: [CCAMP] Overlay model framework and context
>>
>>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
>>
>>
>>
>
>