Subject: Re: [CCAMP] Overlay model framework and context

From: Gert Grammel <[email-masked]>
Date: Mon, 17 Dec 2012 13:27:01 +0000

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: [email-masked] 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 +390106002512
Mobile +393346725750
[email-masked]
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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 17 Dec 2012 14:13:14 +0000

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:[email-masked]] 
>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:
>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
>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
>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).
>
> 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.
> 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.
>    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?
>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
>  c)real switches individually may not have sufficient 
>resources to terminate virtual links (while a group of real 
>switches collectively will have)
>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.
>
>
>
>This Communication is Confidential. We only send and receive 
>email on the basis of the term set out at 
>www.ericsson.com/email_disclaimer
>
>
>

---

From: Gert Grammel <[email-masked]>
Date: Mon, 17 Dec 2012 14:34:27 +0000

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,

OC1                               OC2
  \    +---+IF2       IF3+---+    /

Cheers,
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 17 Dec 2012 15:03:23 +0000

I was suggesting to pick one of them :-)

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

Cheers,
Daniele 

>Sent: lunedì 17 dicembre 2012 15.34
>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
>
>
>
>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+---+    /
>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?
>
>>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
>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.
>>
>confusion 
>>and jumps to assessment and conclusions. That's unfortunate:
>>
>>The first line says:
>>having intermediate nodes interconnecting Virtual Links in the middle 
>>of the virtual topology
>>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
>>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?
>>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.
>>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
>>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).
>>
>> 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 
>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.
>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.
>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.
>> 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.
>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 
>the ONI (it 
>>falls under the UNI case as no routing adjacency is in place 
>between OC 
>>and OE).
>>
>>+ Open issues/questions
>>
>>because of N**2 problem. IP over ATM and single-segment PWs have the 
>>same issue, that's why people invented multi-segment PWs
>>having intermediate nodes interconnecting Virtual Links in the middle 
>>of the virtual topology
>>  c)real switches individually may not have sufficient resources to 
>>terminate virtual links (while a group of real switches collectively 
>>will have)
>>generally speaking, blocking switches and as such must expose their 
>>connectivity matrices
>>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
>>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.
>>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.
>>
>>
>>
>>This Communication is Confidential. We only send and receive email on 
>>the basis of the term set out at www.ericsson.com/email_disclaimer
>>
>>
>>
>
>

---

From: Gert Grammel <[email-masked]>
Date: Mon, 17 Dec 2012 15:07:59 +0000

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:[email-masked]] 
Sent: Montag, 17. Dezember 2012 16:03
To: Gert Grammel; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Cheers,
Daniele 

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

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 17 Dec 2012 20:11:42 +0000

Gert,

Please, see in line. I disagree with pretty much everything you say. 
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: Monday, December 17, 2012 8:27 AM
To: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

Daniele,

1) Virtual Link: in the terminology statement a virtual link seems to connect two client elements.
IB>> The definition says:
"1. Virtual Link: A virtual link is a potential path between two virtual or real network elements in a client layer", what makes you think that anyone ever applied that this is a path between client devices? The definition should say, though: " a potential path between two virtual or real server domain network 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.
IB>> see above

 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 

IB>> I completely disagree with this, see below

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:

IB>> It seems to me that you completely misunderstand current definitions

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?
IB>> Virtual Link Model includes access, inter-domain and virtual links but does not include virtual nodes

IB>> A combination of access and virtual links alone *does not address N**2 problem*.
Consider 1000 client devices connected via 1000 access links to the network that need to be fully interconnected. You will need 1000000 VLs to do so. You need to have one or more Virtual Nodes in the middle of the virtual topology to solve this issue. Overlay Network Topology is no different from real network topology, and real network topologies do include Ps, not just PEs 
 
3.      These intermediate nodes cannot be real server domain switches, because, generally speaking:
--> in case of VNT-VLs no intermediate nodes are necessarily required
IB>> See  above, IMO you are dead wrong

4.  --> No need to comment, this way doesn't scale anyway.
IB>> ONTs with virtual nodes scale no worse that real network topologies

IB>> You is the client path computer. If the two paths are going through the same node, they may overlap inside the node, which means they can be brought down by a single network failure. That's why you need to expose  node's internal SRLGs or try to find node disjoint paths (which may not be available)

IB>> Please, do that

Gert

Dear CCAMPers,

Thanks,
Daniele

+ Disclaimer:

+ Terminology:

+ 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

+ Appendix:

Via E.Melen, 77
Genova, Italy
Phone +390106002512
Mobile +393346725750

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 19 Dec 2012 14:52:53 +0000

Hi Igor,

Just focusing on the virtual links for a while; i must admit that i'm a bit confused by your last mail. Let's pick the figure i sent.

>   \IF1|OE1|-------------|OE2|IF4/

According to the definition given:
"A virtual link is a potential path between two virtual or real network elements in a client layer" 
I would say that a virtual link is from OC1 to OC2, which is A).

Then, from your latest definition:
" a potential path between two virtual or real server domain network elements"
I would say that a virtual link can be either B) or C).

Then you speak about access links, which implies that the link between OC1 and OE1 has its own dignity and hence that the virtual link is C) in picture above. Now i have 2 questions:

Q1: can you confirm that a virtual link is C)? Then we need to update the definition of a virtual link removing any misleading reference to client/server domain Network elements and speak about OCs and OEs.  

Q2: if on the other side we considered the virtual link being B) (i.e. From IF1 to IF4 hence with an "implicit" node connectivity matrix) which would be the drawbacks of this solution?

Thanks
Daniele

>From: Igor Bryskin [mailto:[email-masked]] 
>Sent: lunedì 17 dicembre 2012 21.12
>To: Gert Grammel; Daniele Ceccarelli; CCAMP
>seems to connect two client elements.
>"1. Virtual Link: A virtual link is a potential path between 
>two virtual or real network elements in a client layer", what 
>makes you think that anyone ever applied that this is a path 
>between client devices? The definition should say, though: " a 
>potential path between two virtual or real server domain 
>network 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.
>IB>> see above
>
>based on terminology 1) rather than on virtual topology 
>
>3). This way it doesn't describe then the  scalability of a 
>IB>> It seems to me that you completely misunderstand current 
>IB>> definitions
>
>IB>> Virtual Link Model includes access, inter-domain and 
>virtual links 
>IB>> but does not include virtual nodes
>
>Consider 1000 client devices connected via 1000 access links 
>to the network that need to be fully interconnected. You will 
>need 1000000 VLs to do so. You need to have one or more 
>Virtual Nodes in the middle of the virtual topology to solve 
>this issue. Overlay Network Topology is no different from real 
>network topology, and real network topologies do include Ps, 
>not just PEs 
> 
>IB>> You is the client path computer. If the two paths are 
>going through 
>IB>> the same node, they may overlap inside the node, which means they 
>IB>> can be brought down by a single network failure. That's why you 
>IB>> need to expose  node's internal SRLGs or try to find node 
>disjoint 
>IB>> paths (which may not be available)
>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 19 Dec 2012 17:03:04 +0000

Daniele,
Please, see in line.

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Wednesday, December 19, 2012 9:53 AM
To: Igor Bryskin; Gert Grammel; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Hi Igor,

>   \IF1|OE1|-------------|OE2|IF4/

IB>> My understanding of your picture is this:

OC1------If1:OE1                                     OE2:IF4---------OC2
                       OE1:If2----------------- If3:OE2
My answer : is neither a), b) nor c)

OC1------If1:OE1  ===== VL ======= OE2:IF4---------OC2
                       OE1:If2----------------- If3:OE2

VL is between OE1 and OE 2, potential server trail is between IF2 and IF3

IB>> See above

IB>> See above

Then you speak about access links, which implies that the link between OC1 and OE1 has its own dignity and hence that the virtual link is C) in picture above. 

IB>> Links OC1- OE1 and OC2-OE2 are access links

Now i have 2 questions:

IB>>  VL cannot start on a customer facing interface. OE is a (blocking) switch between access and virtual TE links

Thanks
Daniele

>connect two client elements.
>"1. Virtual Link: A virtual link is a potential path between two 
>virtual or real network elements in a client layer", what makes you 
>think that anyone ever applied that this is a path between client 
>devices? The definition should say, though: " a potential path between 
>two virtual or real server domain network 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.
>IB>> see above
>
>terminology 1) rather than on virtual topology
>
>3). This way it doesn't describe then the  scalability of a virtual 
>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 
>Now looking at the appendix it sadly reflects the terminology confusion 
>Consider 1000 client devices connected via 1000 access links to the 
>network that need to be fully interconnected. You will need 1000000 VLs 
>to do so. You need to have one or more Virtual Nodes in the middle of 
>the virtual topology to solve this issue. Overlay Network Topology is 
>no different from real network topology, and real network topologies do 
>include Ps, not just PEs
> 
>services traversing the switch will not simultaneously fail if a single 
>sort of agreemet among a small group of people, some others to a set a 
>maintained/controlled in and by the server domain control plane (and as 
> 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 
> 4. Overlay topology:  is a superset of virtual topologies provided by 
> 6. Overlay Customer (OC): Something like the CN in RFC4208 teminology  
>but (i) receiving virtual topology from the core network and requesting 
>network and receiving the parameters characterizing such path. (ii) == 
>UNI.
>and routing messages exchange between Overlay and Core network. Routing 
>no routing adjacency across the interface it is equivalent to the GMPLS 
>UNI defined in 4208.
>path carachteristics, e.g. TE-metrics, collected SRLG, path delay etc, 
>between different core networks in the overlay model environment, i.e. 
>    c) virtual topology provided by the server network domains. Virtual 
>peripheral at best, it is all about horizontal network integration  5. 
>separate instance for the server network and in the ONI case the server 
> 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
>
>services traversing the switch will not simultaneously fail if a single

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 20 Dec 2012 09:40:57 +0000

Hi Igor,

Unfortunately your drawing is totally misaligned, is this a correct re-drawing?

answer : is neither a), b) nor c)

OC1------If1:OE1========== VL =========== OE2:IF4---------OC2
             OE1:If2----------------- If3:OE2 

With respect to Q2:

>Q2: if on the other side we considered the virtual link being 
>B) (i.e. From IF1 to IF4 hence with an "implicit" node 
>connectivity matrix) which would be the drawbacks of this solution?
>
>IB>>  VL cannot start on a customer facing interface. OE is a 
>(blocking) 
>IB>> switch between access and virtual TE links

I still believe the tranffic matrix can be implicitely advertised as part of the VL. Consider this:

OC3------If5:OE1========== VL1 =========== OE2:IF6---------OC4
OC1------If1:OE1========== VL2 =========== OE2:IF4---------OC2
             OE1:If2-------------------If3:OE2 

OE1 is a blocking node because only allows OC3 to be connected to VL1 and OC1 to VL2. But if you just advertise VL1 to OC3 (not VL2) and VL2 to OC1 (not VL1) aren't you implicitely hiding the blocking nature of OE1?

Cheers,
Daniele

>Sent: mercoledì 19 dicembre 2012 18.03
>To: Daniele Ceccarelli; Gert Grammel; CCAMP
>Just focusing on the virtual links for a while; i must admit 
>that i'm a bit confused by your last mail. Let's pick the 
>figure i sent.
>
>>OC1                               OC2
>>  \    +---+IF2       IF3+---+    /
>                       OE1:If2----------------- If3:OE2 My 
>answer : is neither a), b) nor c)
>
>Then you speak about access links, which implies that the link 
>between OC1 and OE1 has its own dignity and hence that the 
>virtual link is C) in picture above. 
>
>Q1: can you confirm that a virtual link is C)? Then we need to 
>update the definition of a virtual link removing any 
>misleading reference to client/server domain Network elements 
>and speak about OCs and OEs.  
>
>Q2: if on the other side we considered the virtual link being 
>B) (i.e. From IF1 to IF4 hence with an "implicit" node 
>connectivity matrix) which would be the drawbacks of this solution?
>
>IB>>  VL cannot start on a customer facing interface. OE is a 
>(blocking) 
>IB>> switch between access and virtual TE links
>
>
>Thanks
>Daniele
>
>
>
>
>
>>From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>>Of Gert Grammel

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 20 Dec 2012 16:01:17 +0000

Daniele,
It seems we have a disconnect here.

OC1-----OE1======VL1======OE2-----OC2
OC3-----OE1======VL2======OE2-----OC4

Generally speaking OEs are blocking switches, and the connectivity matrices need to be advertised by OEs, so that the client path computer will know , for example, that OC1-OE1 access link can be switched to VL1 (but not to VL2). One way to alleviate the client path computation from dealing with connectivity matrices is by presenting OEs as sets of independent fully symmetrical Virtual Nodes:

OC1-----VN1======VL1======VN3-----OC2
OC3-----VN2======VL2======VN4-----OC4 

Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 4:41 AM
To: Igor Bryskin; Gert Grammel; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Hi Igor,

Cheers,
Daniele

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 20 Dec 2012 13:33:47 -0800

Igor,

I think depending on what the capabilities of the OE are there may be many
possibilities. Expanding on your VN examples.

Another example could be:

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6

Since virtual-links are potential links the topology would have to be a
mesh between the VNs. The other question that is applicable here is whether
hair-pinning is allowed in a VN?

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6
            VN1======VL3======VN4
            VN1======VL4======VN5
           VN2======VL5======VN5
           VN2======VL6======VN3

Regards
Snigdho

On Thu, Dec 20, 2012 at 8:01 AM, Igor Bryskin <[email-masked]>wrote:

> Generally speaking OEs are blocking switches, and the connectivity
> matrices need to be advertised by OEs, so that the client path computer
> will know , for example, that OC1-OE1 access link can be switched to VL1
> (but not to VL2). One way to alleviate the client path computation from
> dealing with connectivity matrices is by presenting OEs as sets of
> independent fully symmetrical Virtual Nodes:
>
> OE1 is a blocking node because only allows OC3 to be connected to VL1 and
> OC1 to VL2. But if you just advertise VL1 to OC3 (not VL2) and VL2 to OC1
> (not VL1) aren't you implicitely hiding the blocking nature of OE1?
>
> Cheers,
> Daniele
>
>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 20 Dec 2012 21:47:26 +0000

Define the "hair-pinning", please

From: Snigdho Bardalai [mailto:[email-masked]]
Sent: Thursday, December 20, 2012 4:34 PM
To: Igor Bryskin
Cc: Daniele Ceccarelli; Gert Grammel; CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

Igor,

I think depending on what the capabilities of the OE are there may be many possibilities. Expanding on your VN examples.

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6

Since virtual-links are potential links the topology would have to be a mesh between the VNs. The other question that is applicable here is whether hair-pinning is allowed in a VN?

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6
            VN1======VL3======VN4
            VN1======VL4======VN5

Regards
Snigdho

On Thu, Dec 20, 2012 at 8:01 AM, Igor Bryskin <[email-masked]<mailto:[email-masked]>> wrote:
Daniele,
It seems we have a disconnect here.

Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 20, 2012 4:41 AM
To: Igor Bryskin; Gert Grammel; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Hi Igor,

Cheers,
Daniele

>From: Igor Bryskin [mailto:[email-masked]<mailto:[email-masked]>]
>From: Daniele Ceccarelli [mailto:[email-masked]<mailto:[email-masked]>]
>>From: Igor Bryskin [mailto:[email-masked]<mailto:[email-masked]>]
>>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
>On Behalf
>>Of Gert Grammel
>>From: [email-masked]<mailto:[email-masked]> on behalf of Daniele Ceccarelli
>>[email-masked]<mailto:[email-masked]>
>>www.ericsson.com<http://www.ericsson.com>
>>
>>the basis of the term set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
>>
>>
>>[email-masked]<mailto:[email-masked]>
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 20 Dec 2012 21:50:43 +0000

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6
            VN1======VL3======VN4
            VN1======VL4======VN5

Consider the picture above, by hair-pining I am referring to a path such as OC1-VN1-VL3-VN4-VL2-VN2-OC3, of course assuming bandwidth is available.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, December 20, 2012 1:47 PM
To: Snigdho Bardalai
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

Igor,

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6
            VN1======VL3======VN4
            VN1======VL4======VN5

Regards
Snigdho

Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 20, 2012 4:41 AM
To: Igor Bryskin; Gert Grammel; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Hi Igor,

Cheers,
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 20 Dec 2012 22:03:02 +0000

You are correct in saying that the virtual topology presented to the client is an arbitrary mesh of VNs interconnected via VLs. VN can be mapped onto exactly one, several, a fraction or multiple fractions of real server domain NEs. VN (just like a real node) can be blocking or non-blocking. In the latter case the connectivity matrix advertisement is not required. The client path computer will determine a path in a form such as OC1-VN1-VL3-VN4-VL2-VN2-OC3. How server domains translate such paths into real provisioning is their internal matter. It is important, though, that VLs advertise accurate information about fate sharing, delay characteristics, bandwidth, etc. so that client could have enough information for the computation.

Igor

From: Snigdho Bardalai [mailto:[email-masked]]
Sent: Thursday, December 20, 2012 4:51 PM
To: Igor Bryskin; Snigdho Bardalai
Cc: CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6
            VN1======VL3======VN4
            VN1======VL4======VN5

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, December 20, 2012 1:47 PM
To: Snigdho Bardalai
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

Igor,

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6
            VN1======VL3======VN4
            VN1======VL4======VN5

Regards
Snigdho

Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 20, 2012 4:41 AM
To: Igor Bryskin; Gert Grammel; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Hi Igor,

Cheers,
Daniele

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 20 Dec 2012 22:49:28 +0000

Agree, the VN can advertise a connectivity matrix or the VN can be formed such that it consists of the set of VL or access-links that can be connected in a non-blocking manner.

Snigdho

From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, December 20, 2012 2:03 PM
To: Snigdho Bardalai; Snigdho Bardalai
Cc: CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Igor

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6
            VN1======VL3======VN4
            VN1======VL4======VN5

Igor,

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6
            VN1======VL3======VN4
            VN1======VL4======VN5

Regards
Snigdho

Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 20, 2012 4:41 AM
To: Igor Bryskin; Gert Grammel; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Hi Igor,

Cheers,
Daniele

---

From: Iftekhar Hussain <[email-masked]>
Date: Mon, 24 Dec 2012 23:50:19 +0000

For C " scales best but connectivity ...", by connectivity do you mean OEs interconnectivity? 

BR,
Iftekhar
-----Original Message-----
From: Gert Grammel [mailto:[email-masked]] 
Sent: Monday, December 17, 2012 6:34 AM
To: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

Honestly,

Gert

Hi Gert,

OC1                               OC2
  \    +---+IF2       IF3+---+    /

Cheers,
Daniele

---

From: Gert Grammel <[email-masked]>
Date: Tue, 25 Dec 2012 11:37:02 +0000

Yes,

I meant OE connectivity in the edge node. It doesn't matter in most switching technologies, but for wavelength switching there may be some ugly constraints to consider.

Gert
________________________________________
From: Iftekhar Hussain
Sent: Tuesday, December 25, 2012 12:50:19 AM
To: Gert Grammel; Daniele Ceccarelli; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

BR,
Iftekhar
-----Original Message-----
From: Gert Grammel [mailto:[email-masked]]
Sent: Monday, December 17, 2012 6:34 AM
To: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

Honestly,

Gert

Hi Gert,

OC1                               OC2
  \    +---+IF2       IF3+---+    /

Cheers,
Daniele