Subject: [CCAMP] Overlay model framework and context

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

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: Lou Berger <[email-masked]>
Date: Mon, 17 Dec 2012 14:45:18 -0500

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"?

- So what's a "server layer network" in this context?  Perhaps you mean
OE or "(overlay) provider layer"?

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

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

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?)...

Much thanks,
Lou

On 12/17/2012 6:17 AM, Daniele Ceccarelli wrote:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 19 Dec 2012 10:56:32 +0000

Hi Lou,

Plese find replies in line.

BR
Daniele 

>-----Original Message-----
>From: Lou Berger [mailto:[email-masked]] 
>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.

>> 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
>> 3.      These intermediate nodes cannot be real server 
>domain switches, because, generally speaking:
>>   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: Lou Berger <[email-masked]>
Date: Wed, 19 Dec 2012 10:09:21 -0500

Daniele,
	see below.

On 12/19/2012 5:56 AM, Daniele Ceccarelli wrote:
> 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).

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 19 Dec 2012 15:32:01 +0000

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

>Sent: mercoledì 19 dicembre 2012 16.09
>To: Daniele Ceccarelli
>Cc: CCAMP
>>> 	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"?
>> 
>>> - So what's a "server layer network" in this context?  Perhaps you 
>>> mean OE or "(overlay) provider layer"?
>> 
>> Again correct
>> 
>>>
>> 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
>> 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).
>
>>>
>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
>>> 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?
>> 
>>> 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
>>>
>>> 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.
>>>>
>>> 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).
>>>>
>>> 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.
>>> 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.
>>> 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.
>>> 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.
>>> signaling and routing messages exchange between Overlay and  Core 
>>>network. Routing information consists on virtual topology  
>>> 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).
>>> 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
>>> 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.
>>> 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.
>>> the ONI (it falls under the UNI case as no routing adjacency is in 
>>> place between OC and OE).
>>>>
>>>> + Open issues/questions
>>>>  
>have the 
>>> same issue, that's why people invented multi-segment PWs
>>> by having intermediate nodes interconnecting Virtual Links in the 
>>> middle of the virtual topology
>switches are, 
>>> generally speaking, blocking switches and as such must expose their 
>>> connectivity matrices
>>> 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.
>>> understand the connectivity matrices advertised by the border nodes 
>>> describing connectivity constraints between access links 
>and virtual 
>>> links they terminate.
>>>>
>>>>
>>>>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 19 Dec 2012 16:46:48 +0100

Hi Daniele,

Thanks a lot for your effort to summarize mail exchange.

About the content and definitions , I would support the Lou position.
I think that in this context many of the concepts and definitions have been proposed , are already present in the IETF document.

ONI definition and OE and OC definitions surely does not help to clarify scenarios that has been already debated in the VPN context .

I support UNI only definition without to complicate proliferating with other interface definitions, and the usage of CE ,PE for nodes.
Moreover I have also perplexity about the definition of Virtual Link and Virtual Topology.

What are the difference and the added values to have very similar definitions to what already well defined in the MRN context ?

Thanks again for your effort.

Ciao
Sergio

Belotti Sergio - System Architect
ALCATEL-LUCENT  Optics Division

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Daniele Ceccarelli
Inviato: mercoledì 19 dicembre 2012 16.32
A: Lou Berger
Cc: CCAMP
Oggetto: Re: [CCAMP] Overlay model framework and context

Why should is say: 

BR
Daniele

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Dec 2012 10:53:50 -0500

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

Right?

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Dec 2012 10:54:47 -0500

Sergio,
	I'm not sure we're in agreement.  I'm fine with the OE/OC terminology.
 (which shouldn't be too surprising...)

Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 19 Dec 2012 17:04:08 +0100

Lou,

I misunderstood your assumption sorry, yes we agree in the definition for OE and OC but referring to PE and CE as helpful reference in the definition.

Sergio

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]] 
Inviato: mercoledì 19 dicembre 2012 16.55
A: BELOTTI, SERGIO (SERGIO)
Cc: Daniele Ceccarelli; CCAMP
Oggetto: Re: R: [CCAMP] Overlay model framework and context

Sergio,

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 19 Dec 2012 16:23:50 +0000

Basically yes; being fussy i would say:

	DC) ONI
	DC) UNI

BR
Daniele

>Sent: mercoledì 19 dicembre 2012 16.54
>To: Daniele Ceccarelli
>Cc: CCAMP
>> "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"
>> 
>>> I have no idea what this means.  I suspect it relates to comments 
>>> below, so will discuss there.
>>>
>>>> I would
>>> An OC is analogous to an L3VPN CE, and an OE is analogous 
>to an L3VPN 
>>> PE (with a provider based VPN).
>>>
>>>>>
>provide the 
>represented 
>inter-domain

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 19 Dec 2012 16:47:59 +0000

Hi Sergio,

A VPN is one of the many things (services) that can be done in an overlay context and my proposal was to call such nodes OE and OC when generally referring to them withing the overlay context. If in such context you are proving a VPN, then the OE is a PE and the OC is a CE, but only for the VPN. They are not a PE and a CE for every other service going through them that is not a VPN.

Take for example the "kilt". You don't call "kilt" every skirt. When you're in the context of traditional scottish male clothing you call it "kilt", otherwise it's generally called skirt. (apologies for the example but a better one didn't come to my mind).

Wrt the MRN what is your proposal? Calling the virtual te-links just VNT?

Ciao
Daniele

>From: BELOTTI, SERGIO (SERGIO) 
>[mailto:[email-masked]] 
>Sent: mercoledì 19 dicembre 2012 17.04
>To: Lou Berger; Daniele Ceccarelli
>Cc: CCAMP
>Subject: R: R: [CCAMP] Overlay model framework and context
>
>Lou,
>
>I misunderstood your assumption sorry, yes we agree in the 
>definition for OE and OC but referring to PE and CE as helpful 
>reference in the definition.
>
>Sergio
>
>> I think that in this context many of the concepts and 
>definitions have been proposed , are already present in the 
>IETF document.
>> 
>> ONI definition and OE and OC definitions surely does not 
>help to clarify scenarios that has been already debated in the 
>VPN context .
>> 
>> I support UNI only definition without to complicate 
>proliferating with other interface definitions, and the usage 
>of CE ,PE for nodes.
>> What are the difference and the added values to have very 
>similar definitions to what already well defined in the MRN context ?
>>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 19 Dec 2012 17:58:16 +0100

Ciao Daniele,

See in line

Thanks
Sergio

-----Messaggio originale-----
Da: Daniele Ceccarelli [mailto:[email-masked]]
Inviato: mercoledì 19 dicembre 2012 17.48
A: BELOTTI, SERGIO (SERGIO); Lou Berger
Cc: CCAMP
Oggetto: RE: R: [CCAMP] Overlay model framework and context

Hi Sergio,

SB> In the context of L1VPN , Overlay  stands for a Service Model, here it seems as though we change in the opposite in which you have a network topology and VPN is a service on that. This creates some confusion in my mind .

SB> Very good example

SB> Just taken the definition that are already there . So just reference them.

Ciao
Daniele

---

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

Lou, please see my answers to your questions

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, December 19, 2012 5:57 AM
To: Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

Hi Lou,

BR
Daniele 

>OC or "(overlay) customer layer"?

IB>> Client layer is where Overlay Network topology exists. It includes:
a) access links (connecting OCs to OEs)
b) virtual links (connecting OE / OVNs (Overlay Virtual Nodes) within a given server domain)
c) inter-domain links (connecting OE to OE that belong to neighboring server domains)
All three categories exist in the same client layer and named from the same naming space

>OE or "(overlay) provider layer"?

IB>> It is the layer where the UNT (Underlay Network Topology) exists (which may be in the same, lower or higher layer network than of the ONT)

Again correct

>likewise to a PE for an OE, is helpful context.
IB>> agree

>difference between a virtual and real node
IB>> Agree 

 (and presumably link as 
>form of a UNI or include both signaling and routing (i.e., a peer/I-NNI 
>or

IB>> As long as it allows for both or either signaling and/or routing exchanges

>
>I think this same comment probably holds for the O-NNI (e.g., what's 

IB>> I like "access links" and "inter-domain links" better. Note also that a "link" and "node" are TE topology concepts and orthogonal to CP interfaces (which are Signaling/Routing speakers). If you mean by "internal" and "external" links the CP connectivity, than I agree with you.

>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.
>> 
>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.
>or more virtual or real server network domain nodes that exist in the 
>teminology  but (i) receiving virtual topology from the core network 
>computation and establishment of a path accordingly to gien constraints 
>in the core network and receiving the parameters characterizing such 
>path. (ii) == UNI.
>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).
>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
>(with a set of parameters e.g. SRLG, optical impairments, delay etc for 
>each entry) describing connectivity between access links and virtual 
>links.
>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.
>because of N**2 problem. IP over ATM and single-segment PWs have the 
>resources to terminate virtual links (while a group of real switches 
>collectively will have)
>node, you need to keep in mind that real server domain switches are, 
>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
>switches, you will understand that there is absolutely no difference 
>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.
>> 
>> 
>>

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Dec 2012 12:38:33 -0500

Okay. This helps .so to simplify even further, we have the following 
alternatives:
ONI = overlay customer interface.

Right?

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Dec 2012 18:07:36 -0500

Igor,

You said:
IB>> I like "access links" and "inter-domain links" better.

This works for me.

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 20 Dec 2012 01:44:24 +0000

Hi all,

Support.

People are more familiar with the existing things like "access links" and "inter-domain links" (or E-NNI links).

Best Regards

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2012年12月20日 7:08
收件人: Igor Bryskin
抄送: CCAMP
主题: Re: [CCAMP] Overlay model framework and context

Igor,

You said:

This works for me.

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 20 Dec 2012 02:31:05 +0000

Hi Daniele and all,

Thanks for your useful information.

I agree with Sergio that it is better to use the existing terms to avoid confusion if there are no significant differences between the new terms and the existing ones. 

I would like to discuss the terms with you guys.

(1) ONI & O-NNI vs (UNI & E-NNI)

Is there any inconvenience if we use E-NNI to replace O-NNI? I don't see any difference between them.

Regarding ONI, the difference between UNI and ONI from your text is that routing is allowed to exchange over ONI because it is assumed that only signaling is allowed over UNI. I checked UNI definition in G.8080, it does say that " Note, there is no routing function associated with the UNI reference point.", but G.8080 allows resource discovery can be allowed over UNI. However, if this is the only difference between ONI and UNI, can we extend the UNI definition to allow routing over UNI? We know that discovery (LMP) could be allowed in OIF UNI 1.0R2 (is LMP signaling?). Can we simply regard routing here as resource discovery? :-)

(2) OC&OE vs (CE&PE)

I more like CE&PE than OC&OE, because CE&PE are so friendly for people. I just checked Y.1311 to see the definition of CE&PE. Actually, CE&PE are just abbreviations. I think CE&PE are generic enough to fit overlay context. How about to re-define CE&PE in the simliar way in RFC4847 even though CE&PE is not suitable for overlay context?

I don't see the fundamental difference between the figure in the slide and Figure 1 in RFC4208 besides these new terms.

(3) Virtual link

I see the definition in RFC4847, it says " Virtual link: A provider network Traffic Engineering (TE) link advertised to customers in routing information for purposes that include path computation. A direct data link may or may not exist between the two end points of a virtual link." 

Is this not accurate?

(4) I think we can get more useful information from the existing IETF drafts (LiVPN RFC/drafts) and ITU-T recommendations such as G.8080, Y.1311, Y.1312....

Best Regards

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 BELOTTI, SERGIO (SERGIO)
发送时间: 2012年12月20日 0:58
收件人: Daniele Ceccarelli
抄送: CCAMP
主题: [CCAMP] R: R: Overlay model framework and context

Ciao Daniele,

See in line

Thanks
Sergio

-----Messaggio originale-----
Da: Daniele Ceccarelli [mailto:[email-masked]]
Inviato: mercoledì 19 dicembre 2012 17.48
A: BELOTTI, SERGIO (SERGIO); Lou Berger
Cc: CCAMP
Oggetto: RE: R: [CCAMP] Overlay model framework and context

Hi Sergio,

SB> Very good example

Ciao
Daniele

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 20 Dec 2012 09:19:04 +0100

Why do not use OCI ..
ONI sounds more close to optical network interface that is not the case.

OCI--> Overlay Customer Interface

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
Inviato: mercoledì 19 dicembre 2012 18.39
A: Daniele Ceccarelli
Cc: CCAMP
Oggetto: Re: [CCAMP] Overlay model framework and context

Right?

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 20 Dec 2012 10:22:46 +0000

I prefer using reference points instead of links.
Access link and inter-domain links means tens of things in different contexts, while e.g. UNI means one single thing and clearly identifies the context. BTW it's just a preference, I don't mind how we'll finally call it.

There's one thing I would rather like to clarify and it's the relationship with VPNs. We have two options:

1) Is a VPN a particular case of the overlay model?
or
2) Is the overlay model a particular case of VPN?

I think this can help a lot with terminology. I've always assumed 1) but from what I read I tend to see that 2) has several supporters.

BR
Daniele

>From: Fatai Zhang [mailto:[email-masked]] 
>Sent: giovedì 20 dicembre 2012 2.44
>To: Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO); 
>Daniele Ceccarelli
>Cc: CCAMP
>Subject: 答复: [CCAMP] Overlay model framework and context
>
>Hi all,
>
>Support.
>
>People are more familiar with the existing things like "access 
>links" and "inter-domain links" (or E-NNI links).
>
>
>
>
>Best Regards
>
>Fatai
>
>-----邮件原件-----
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>> Of Daniele Ceccarelli
>> b) virtual links (connecting OE / OVNs (Overlay Virtual 
>Nodes) within 
>> a given server domain)
>> c) inter-domain links (connecting OE to OE that belong to 
>neighboring 
>> server domains) All three categories exist in the same client layer 
>> and named from the same naming space
>> 
>> IB>> It is the layer where the UNT (Underlay Network 
>Topology) exists 
>> IB>> (which may be in the same, lower or higher layer 
>network than of 
>> IB>> the ONT)
>> 
>> Again correct
>> 
>>>
>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?
>> 
>>>
>>> no difference between a virtual and real node
>> IB>> Agree
>> 
>>  (and presumably link as
>> IB>> As long as it allows for both or either signaling 
>and/or routing 
>> IB>> exchanges
>> 
>>>
>Note also that a "link" and "node" are TE topology concepts 
>and orthogonal to CP interfaces (which are Signaling/Routing 
>speakers). If you mean by "internal" and "external" links the 
>CP connectivity, than I agree with you.
>> 
>>>
>>> Much thanks,
>>> Lou
>>>
>>> below so to progress the discussions into a single thread 
>on the WG ML.
>>>>
>>> being
>related to 
>>> path carachteristics, e.g. TE-metrics, collected SRLG, path delay

---

From: Lou Berger <[email-masked]>
Date: Thu, 20 Dec 2012 09:39:28 -0500

Daniele,

Just my opinion, but I see overlays as the (much) more generic term.  I
think LxVPNs are types of overlays, as are traditional layered networks,
as are the technologies that match/will result from discussions taking
place in the NVO3 context.

Lou

On 12/20/2012 5:22 AM, Daniele Ceccarelli wrote:
> Access link and inter-domain links means tens of things in different
> contexts, while e.g. UNI means one single thing and clearly
> identifies the context. BTW it's just a preference, I don't mind how
> we'll finally call it.
> 
> There's one thing I would rather like to clarify and it's the
> relationship with VPNs. We have two options:
> 
> I think this can help a lot with terminology. I've always assumed 1)
> but from what I read I tend to see that 2) has several supporters.
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 20 Dec 2012 15:32:02 +0000

Excellent,

So you'd agree with the general overlay definitions of OC and OE. (which in the case of VPNs will be called CE and PE).

What about an analogous approach when we move from nodes to interfaces/links. A general name for the overlay most general case where specific exisitng names can be places (the famous umbrella).

- In the more generic case of overlay: the nodes are called OC and OE and the interface between OC and OE is called (ONI, OI, OCI, xxxlink or whatever)
- In the case of interface supporting signaling only: The (ONI, OI, OCI, xxxlink or whatever) is a particular case of (ONI, OI, OCI or whatever) and is called UNI, and the nodes at its ends are called CN and EN (RFC4208)
- In the case of VPNs: the (ONI, OI, OCI, xxxlink or whatever) is called access link and the nodes are called CE and PE.

I see no other way of putting some order among all the already existing terms.

BR
Daniele

>Sent: giovedì 20 dicembre 2012 15.39
>To: Daniele Ceccarelli
>Cc: Fatai Zhang; Igor Bryskin; BELOTTI, SERGIO (SERGIO); CCAMP
>Just my opinion, but I see overlays as the (much) more generic 
>term.  I think LxVPNs are types of overlays, as are 
>traditional layered networks, as are the technologies that 
>match/will result from discussions taking place in the NVO3 context.
>
>Lou
>
>identifies 
>> the context. BTW it's just a preference, I don't mind how we'll 
>> finally call it.
>> 
>>> To: Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele 
>>> Ceccarelli
>>> Cc: CCAMP
>>> People are more familiar with the existing things like 
>"access links" 
>>> and "inter-domain links" (or E-NNI links).
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>> Fatai
>>>
>>> -----邮件原件-----
>>> Customer and Overlay Edge and in the particular case of 
>VPNs they are 
>>> the CE and PE respectively. What about that?
>>>>
>>>>>
>>> Note also that a "link" and "node" are TE topology concepts and 
>>> orthogonal to CP interfaces (which are Signaling/Routing speakers). 
>>> If you mean by "internal" and "external" links the CP connectivity, 
>>> than I agree with you.
>>>>
>>>>>
>>>>> Much thanks,
>>>>> Lou
>>>>>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 20 Dec 2012 15:33:31 +0000

Fatai,
You said:
     (3) Virtual link

IB>> It is not accurate because in the context of this discussion there is no direct (1:1) correlation between the virtual link advertised to the customer and the provider link. Generally speaking:
a) virtual link exists in a different layer network;
b) virtual link may be mapped to a chain of provider (existing or not yet existing) links
c)virtual link may be mapped to a hierarchy (stack) of provider links.
In short, virtual link is decoupled from provider links.

Furthermore, the definition does not say what terminates virtual link. In our definition it can be terminated either by OE (overlay edge) or VN (virtual node). Virtual link (as well as VN) is named from the customer name space which is independent from provider (underlay) space.

Cheers,
Igor

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]] 
Sent: Wednesday, December 19, 2012 9:31 PM
To: Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: CCAMP
Subject: 答复: [CCAMP] R: R: Overlay model framework and context

Hi Daniele and all,

(2) OC&OE vs (CE&PE)

(3) Virtual link

Is this not accurate?

Best Regards

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 BELOTTI, SERGIO (SERGIO)
发送时间: 2012年12月20日 0:58
收件人: Daniele Ceccarelli
抄送: CCAMP
主题: [CCAMP] R: R: Overlay model framework and context

Ciao Daniele,

See in line

Thanks
Sergio

-----Messaggio originale-----
Da: Daniele Ceccarelli [mailto:[email-masked]]
Inviato: mercoledì 19 dicembre 2012 17.48
A: BELOTTI, SERGIO (SERGIO); Lou Berger
Cc: CCAMP
Oggetto: RE: R: [CCAMP] Overlay model framework and context

Hi Sergio,

SB> Very good example

Ciao
Daniele

>I misunderstood your assumption sorry, yes we agree in the definition 
>for OE and OC but referring to PE and CE as helpful reference in the 
>definition.
>
>Sergio
>
>definitions have been proposed , are already present in the IETF 
>document.
>>
>help to clarify scenarios that has been already debated in the VPN 
>context .
>>
>proliferating with other interface definitions, and the usage of CE ,PE 
>for nodes.
>overlay model context supporting both signaling and routing message 
>exchange that is called UNI when only signaling is supported"
>>
>>> An OC is analogous to an L3VPN CE, and an OE is analogous to an 
>>> L3VPN PE (with a provider based VPN).
>>>
>>>>>
>on the WG
>>>>>>  2. BGP-LS needs to be considered  3. Should potentials be 
>>>>>> included? E.g. I2RS?
>>>>>>
>>>>>> + Appendix:

---

From: Lou Berger <[email-masked]>
Date: Thu, 20 Dec 2012 10:42:25 -0500

Daniele,

The piece that's missing from your mail is that your "vpn" terms have
wider scope than just VPNs.  For example CEs, PEs, access
interfaces|links, inter-domain interfaces|links have scope well beyond
VPNs.

An alternate conclusion (which you have me now leaning towards) is that
we should just use CE and PE in place of OE and OC.

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 20 Dec 2012 15:51:41 +0000

You thought the world was grey, I spent half an hour to write an email trying to convince you that world is white and now you're convinced that the world is black!!!  :)

>Sent: giovedì 20 dicembre 2012 16.42
>To: Daniele Ceccarelli
>The piece that's missing from your mail is that your "vpn" 
>terms have wider scope than just VPNs.  For example CEs, PEs, access
>An alternate conclusion (which you have me now leaning 
>towards) is that we should just use CE and PE in place of OE and OC.
>
>Lou
>
>> So you'd agree with the general overlay definitions of OC 
>and OE. (which in the case of VPNs will be called CE and PE).
>> 
>> What about an analogous approach when we move from nodes to 
>interfaces/links. A general name for the overlay most general 
>case where specific exisitng names can be places (the famous umbrella).
>> 
>> - In the more generic case of overlay: the nodes are called 
>OC and OE 
>> and the interface between OC and OE is called (ONI, OI, OCI, xxxlink 
>> or whatever)
>> - In the case of interface supporting signaling only: The (ONI, OI, 
>> OCI, xxxlink or whatever) is a particular case of (ONI, OI, OCI or 
>> whatever) and is called UNI, and the nodes at its ends are called CN 
>> and EN (RFC4208)
>> - In the case of VPNs: the (ONI, OI, OCI, xxxlink or 
>whatever) is called access link and the nodes are called CE and PE.
>> 
>>> Just my opinion, but I see overlays as the (much) more 
>generic term.  
>>> I think LxVPNs are types of overlays, as are traditional layered 
>>> networks, as are the technologies that match/will result from 
>>> discussions taking place in the NVO3 context.
>>>
>>> Lou
>>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 20 Dec 2012 11:00:00 -0500

Think of it this way.  Are the overlays we're talking about here any
different from the other overlays being talked about at the IETF?  (See
threads in MPLS or NVO3, for example.)

(a) If yes, then we should probably figure out how they differ, and
ensure are terminology is aligned with this 'uniqueness'.

(b) If no, then we should be using the terminology already in use in the
broader discussion or be prepared to drive the terminology into the
wider discussion.  -- I personally have no problem with the latter if
the existing terminology really is insufficient.

Whether intended or not, your mail pointed out to me that we're in
situation (b).  Do you disagree?

Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 20 Dec 2012 17:31:48 +0100

Hi Igor,

See in line

Thanks

Cheers

Sergio

-----Messaggio originale-----
Da: Igor Bryskin [mailto:[email-masked]]
Inviato: giovedì 20 dicembre 2012 16.34
A: Fatai Zhang; Lou Berger; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: CCAMP
Oggetto: RE: [CCAMP] R: R: Overlay model framework and context

Fatai,
You said:
     (3) Virtual link

SB> as in MRN

SB> as in MRN

SB> it is possible to route a higher-layer LSP into a lower layer
   on the assumption that proper hierarchical LSPs in the lower layer
   will be dynamically created (triggered) as needed.

 what is the difference in this definition of Virtual TE-link in MRN context?

SB> I think for Fatai as for me the difference of your concept of virtual link is what already defined in IETF (MRN, L1VPN ) is not so clear to justify a new definition.

Cheers,
Igor

Cheers

Sergio

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, December 19, 2012 9:31 PM
To: Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: CCAMP
Subject: 答复: [CCAMP] R: R: Overlay model framework and context

Hi Daniele and all,

(2) OC&OE vs (CE&PE)

(3) Virtual link

Is this not accurate?

Best Regards

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 BELOTTI, SERGIO (SERGIO)
发送时间: 2012年12月20日 0:58
收件人: Daniele Ceccarelli
抄送: CCAMP
主题: [CCAMP] R: R: Overlay model framework and context

Ciao Daniele,

See in line

Thanks
Sergio

-----Messaggio originale-----
Da: Daniele Ceccarelli [mailto:[email-masked]]
Inviato: mercoledì 19 dicembre 2012 17.48
A: BELOTTI, SERGIO (SERGIO); Lou Berger
Cc: CCAMP
Oggetto: RE: R: [CCAMP] Overlay model framework and context

Hi Sergio,

SB> Very good example

Ciao
Daniele

---

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

Sergio,

1. According to MRN/MLN is it possible to name a virtual link  from an independent naming space, if yes, please, provide the quote; 

2. According to MRN/MLN is it possible to terminate a virtual link by a virtual node? What is relationship between VNs and VLs? How MLN/MRN solves the O(N**2) problem presented by VNT made of VLs?
How MLN/MRN address the blocking nature of nodes that terminate VLs and access links? Please, provide the quote

3. How MLN/MRN addresses the situation when VL with non-existing data link is advertised, and 3 sec later some service takes a resource, making impossible to provision the data link when it is needed? In other words, how MLN/MRN guarantees that the advertised virtual link is actually useful? Please, provide the quote

4. How MLN/MRN addresses the mutual exclusive nature of multiple VLs mapped onto the same physical provider network resource? Please, provide the quote. 

You also said:

Is it possible according to MLN/MRN to route a client LSP into *higher or the same layer* provider LSP?
According to the framework we are discussing it is possible, because we are not talking about network layers, rather, overlays/underlays, which have arbitrary layer relationship.

Cheers,
Igor 

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 11:32 AM
To: Igor Bryskin; Fatai Zhang; Gert Grammel
Cc: CCAMP; Lou Berger; Daniele Ceccarelli
Subject: R: [CCAMP] R: R: Overlay model framework and context

Hi Igor,

See in line

Thanks

Cheers

Sergio

-----Messaggio originale-----
Da: Igor Bryskin [mailto:[email-masked]]
Inviato: giovedì 20 dicembre 2012 16.34
A: Fatai Zhang; Lou Berger; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: CCAMP
Oggetto: RE: [CCAMP] R: R: Overlay model framework and context

Fatai,
You said:
     (3) Virtual link

SB> as in MRN

SB> as in MRN

Cheers,
Igor

Cheers

Sergio

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, December 19, 2012 9:31 PM
To: Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: CCAMP
Subject: 答复: [CCAMP] R: R: Overlay model framework and context

Hi Daniele and all,

(2) OC&OE vs (CE&PE)

(3) Virtual link

Is this not accurate?

Best Regards

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 BELOTTI, SERGIO (SERGIO)
发送时间: 2012年12月20日 0:58
收件人: Daniele Ceccarelli
抄送: CCAMP
主题: [CCAMP] R: R: Overlay model framework and context

Ciao Daniele,

See in line

Thanks
Sergio

-----Messaggio originale-----
Da: Daniele Ceccarelli [mailto:[email-masked]]
Inviato: mercoledì 19 dicembre 2012 17.48
A: BELOTTI, SERGIO (SERGIO); Lou Berger
Cc: CCAMP
Oggetto: RE: R: [CCAMP] Overlay model framework and context

Hi Sergio,

SB> Very good example

Ciao
Daniele

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 20 Dec 2012 10:08:54 -0800

Regarding the question about overlay and VPNs -

The current discussions have been mostly around the customer and provider
interface and so the question that arises is whether the provider to
provider interface is in the scope of this work. IMO - overlay would fit
perfectly to address the customer and provider interface, but I am not so
sure if we can use the term overlay for an provider to provider interface.

So the question is - will the term VPN apply in a more generic sense to
address both interfaces?

Regards
Snigdho

On Thu, Dec 20, 2012 at 2:22 AM, Daniele Ceccarelli <
[email-masked]> wrote:

> contexts, while e.g. UNI means one single thing and clearly identifies the
> context. BTW it's just a preference, I don't mind how we'll finally call it.
>
> I think this can help a lot with terminology. I've always assumed 1) but
> from what I read I tend to see that 2) has several supporters.
>
> BR
> Daniele
>
>
>
>

---

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

Snigdho,

We do consider multi-domain scenario where multiple server network domains are interconnected via inter-domain links (which are no different from access links). Each such domain contributes to a single Overlay Network Topology (ONT) provided to a given set of clients by exposing its own virtual topology made of VNs and VLs.

Igor

From: Snigdho Bardalai [mailto:[email-masked]]
Sent: Thursday, December 20, 2012 1:09 PM
To: Daniele Ceccarelli
Cc: Fatai Zhang; Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO); CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

The current discussions have been mostly around the customer and provider interface and so the question that arises is whether the provider to provider interface is in the scope of this work. IMO - overlay would fit perfectly to address the customer and provider interface, but I am not so sure if we can use the term overlay for an provider to provider interface.

So the question is - will the term VPN apply in a more generic sense to address both interfaces?

Regards
Snigdho
On Thu, Dec 20, 2012 at 2:22 AM, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>> wrote:
I prefer using reference points instead of links.
Access link and inter-domain links means tens of things in different contexts, while e.g. UNI means one single thing and clearly identifies the context. BTW it's just a preference, I don't mind how we'll finally call it.

BR
Daniele

>From: Fatai Zhang [mailto:[email-masked]<mailto:[email-masked]>]
>发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] 代表
>Lou Berger
>发送时间: 2012年12月20日 7:08
>收件人: Igor Bryskin
>抄送: CCAMP
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
>On Behalf
>> Of Daniele Ceccarelli
>>> From: Lou Berger [mailto:[email-masked]<mailto:[email-masked]>]
>>>> [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]>
>> [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: John E Drake <[email-masked]>
Date: Thu, 20 Dec 2012 19:00:01 +0000

Igor,

I think the definition in RFC4847 is correct for our purposes:  

"Virtual link: A provider network Traffic Engineering (TE) link advertised to customers in routing information for purposes that include path computation. A direct data link may or may not exist between the two end points of a virtual link."

Irrespectively Yours,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Igor Bryskin
> Sent: Thursday, December 20, 2012 9:06 AM
> To: BELOTTI, SERGIO (SERGIO); Fatai Zhang; Gert Grammel
> Cc: CCAMP
> Subject: Re: [CCAMP] R: R: Overlay model framework and context
> 
> Sergio,
> 
> 1. According to MRN/MLN is it possible to name a virtual link  from an
> independent naming space, if yes, please, provide the quote;
> 
> 2. According to MRN/MLN is it possible to terminate a virtual link by a
> virtual node? What is relationship between VNs and VLs? How MLN/MRN
> solves the O(N**2) problem presented by VNT made of VLs?
> 3. How MLN/MRN addresses the situation when VL with non-existing data
> link is advertised, and 3 sec later some service takes a resource,
> making impossible to provision the data link when it is needed? In
> other words, how MLN/MRN guarantees that the advertised virtual link is
> actually useful? Please, provide the quote
> 
> 4. How MLN/MRN addresses the mutual exclusive nature of multiple VLs
> mapped onto the same physical provider network resource? Please,
> provide the quote.
> 
> You also said:
> According to the framework we are discussing it is possible, because we
> are not talking about network layers, rather, overlays/underlays, which
> have arbitrary layer relationship.
> 
> Cheers,
> Igor
> 
> 
>          I see the definition in RFC4847, it says " Virtual link: A
> provider network Traffic Engineering (TE) link    advertised to
> customers in routing information for purposes that include path
> computation. A direct data link may or may not exist between the two
> end points of a virtual link."
> 
> IB>> It is not accurate because in the context of this discussion there
> is no direct (1:1) correlation between the virtual link advertised to
> the customer and the provider link. Generally speaking:
> Furthermore, the definition does not say what terminates virtual link.
> In our definition it can be terminated either by OE (overlay edge) or
> VN (virtual node). Virtual link (as well as VN) is named from the
> customer name space which is independent from provider (underlay)
> space.
> 
> SB> I think for Fatai as for me the difference of your concept of
> virtual link is what already defined in IETF (MRN, L1VPN ) is not so
> clear to justify a new definition.
> 
> 
> 
> Cheers,
> Igor
> 
> Cheers
> 
> Sergio
> 
> 
> I agree with Sergio that it is better to use the existing terms to
> avoid confusion if there are no significant differences between the new
> terms and the existing ones.
> 
> Regarding ONI, the difference between UNI and ONI from your text is
> that routing is allowed to exchange over ONI because it is assumed that
> only signaling is allowed over UNI. I checked UNI definition in G.8080,
> it does say that " Note, there is no routing function associated with
> the UNI reference point.", but G.8080 allows resource discovery can be
> allowed over UNI. However, if this is the only difference between ONI
> and UNI, can we extend the UNI definition to allow routing over UNI? We
> know that discovery (LMP) could be allowed in OIF UNI 1.0R2 (is LMP
> signaling?). Can we simply regard routing here as resource discovery?
> :-)
> 
> (2) OC&OE vs (CE&PE)
> 
> I more like CE&PE than OC&OE, because CE&PE are so friendly for people.
> I just checked Y.1311 to see the definition of CE&PE. Actually, CE&PE
> are just abbreviations. I think CE&PE are generic enough to fit overlay
> context. How about to re-define CE&PE in the simliar way in RFC4847
> even though CE&PE is not suitable for overlay context?
> 
> I don't see the fundamental difference between the figure in the slide
> and Figure 1 in RFC4208 besides these new terms.
> 
> (3) Virtual link
> 
> I see the definition in RFC4847, it says " Virtual link: A provider
> network Traffic Engineering (TE) link advertised to customers in
> routing information for purposes that include path computation. A
> direct data link may or may not exist between the two end points of a
> virtual link."
> 
> Is this not accurate?
> 
> (4) I think we can get more useful information from the existing IETF
> drafts (LiVPN RFC/drafts) and ITU-T recommendations such as G.8080,
> Y.1311, Y.1312....
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> -----邮件原件-----
> A VPN is one of the many things (services) that can be done in an
> overlay context and my proposal was to call such nodes OE and OC when
> generally referring to them withing the overlay context. If in such
> context you are proving a VPN, then the OE is a PE and the OC is a CE,
> but only for the VPN. They are not a PE and a CE for every other
> service going through them that is not a VPN.
> 
> SB> In the context of L1VPN , Overlay  stands for a Service Model, here
> it seems as though we change in the opposite in which you have a
> network topology and VPN is a service on that. This creates some
> confusion in my mind .
> 
> Take for example the "kilt". You don't call "kilt" every skirt. When
> you're in the context of traditional scottish male clothing you call it
> "kilt", otherwise it's generally called skirt. (apologies for the
> example but a better one didn't come to my mind).
> 
> SB> Very good example
>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 20 Dec 2012 19:24:29 +0000

John,

We define virtual link as:
> 1. Virtual Link: is a potential path between two virtual or real 
> server domain 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 

This definition is noticeably different from the one you mention and IMO suits our goals better because it requires maintaining a state for each resource that the VL depends upon even when the underlying data link is not provisioned. The said resource can be shared with other VLs but cannot be de-provisioned  or taken by some unrelated service. This is important because:
a) it allows for determining fate sharing information for VLs with non-existing underlying data link;
b) provides some reasonable guarantee that VL can be committed (data link will be created) at the time when it is needed
c) the fate sharing information will not change after the VL is committed, i.e. the network planning can be performed before the VL is committed 
d) etc.

Cheers,
Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 2:00 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Fatai Zhang; Gert Grammel
Cc: CCAMP
Subject: RE: [CCAMP] R: R: Overlay model framework and context

Igor,

Irrespectively Yours,

John

> 2. According to MRN/MLN is it possible to terminate a virtual link by 
> a virtual node? What is relationship between VNs and VLs? How MLN/MRN 
> How MLN/MRN address the blocking nature of nodes that terminate VLs 
> and access links? Please, provide the quote
> 
> other words, how MLN/MRN guarantees that the advertised virtual link 
> is actually useful? Please, provide the quote
> 
> According to the framework we are discussing it is possible, because 
> we are not talking about network layers, rather, overlays/underlays, 
> which have arbitrary layer relationship.
> 
> Cheers,
> Igor
> 
> 
> IB>> It is not accurate because in the context of this discussion 
> IB>> there
> avoid confusion if there are no significant differences between the 
> new terms and the existing ones.
> 
> that routing is allowed to exchange over ONI because it is assumed 
> that only signaling is allowed over UNI. I checked UNI definition in 
> G.8080, it does say that " Note, there is no routing function 
> associated with the UNI reference point.", but G.8080 allows resource 
> discovery can be allowed over UNI. However, if this is the only 
> difference between ONI and UNI, can we extend the UNI definition to 
> allow routing over UNI? We know that discovery (LMP) could be allowed 
> in OIF UNI 1.0R2 (is LMP signaling?). Can we simply regard routing here as resource discovery?
> :-)
> 
> (2) OC&OE vs (CE&PE)
> 
> are just abbreviations. I think CE&PE are generic enough to fit 
> overlay context. How about to re-define CE&PE in the simliar way in 
> RFC4847 even though CE&PE is not suitable for overlay context?
> 
> SB> In the context of L1VPN , Overlay  stands for a Service Model, 
> SB> here
> you're in the context of traditional scottish male clothing you call 
> it "kilt", otherwise it's generally called skirt. (apologies for the 
> >>>> 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
> >>>>> (and as such cannot transport any traffic/data and protected 
> >>>>> from being de-provisioned) and which can be instantiated in the
> >>> data plane
> >>>>> network and is capable of terminating of access, inter-domain 
> >>>>> and virtual links.
> >>>>> client layer network and are interconnected via 0 or more 
> >>>>> virtual links.
> >>>>>> [email-masked] www.ericsson.com
> >>>>>>

---

From: John E Drake <[email-masked]>
Date: Thu, 20 Dec 2012 19:36:32 +0000

Igor,

I don't actually see any substantive difference between the two definitions and the additional points you raise are not part of the new defintion.

Irrespectively Yours,

John

> From: Igor Bryskin [mailto:[email-masked]]
> Sent: Thursday, December 20, 2012 11:24 AM
> To: John E Drake; BELOTTI, SERGIO (SERGIO); Fatai Zhang; Gert Grammel
> Cc: CCAMP
> This definition is noticeably different from the one you mention and
> IMO suits our goals better because it requires maintaining a state for
> each resource that the VL depends upon even when the underlying data
> link is not provisioned. The said resource can be shared with other VLs
> but cannot be de-provisioned  or taken by some unrelated service. This
> is important because:
> b) provides some reasonable guarantee that VL can be committed (data
> link will be created) at the time when it is needed
> c) the fate sharing information will not change after the VL is
> committed, i.e. the network planning can be performed before the VL is
> committed
> d) etc.
> 
> Cheers,
> Igor
> 
> "Virtual link: A provider network Traffic Engineering (TE) link
> advertised to customers in routing information for purposes that
> include path computation. A direct data link may or may not exist
> between the two end points of a virtual link."
> 
> Irrespectively Yours,
> 
> John
> 
> 
> > Is it possible according to MLN/MRN to route a client LSP into
> *higher
> > or the same layer* provider LSP?
> definition
> Core

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 20 Dec 2012 20:08:06 +0000

The point is that the new definition explicitly requires maintaining CP state for server resources of the data link that has not been provisioned yet. This changes a lot of things.

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 2:37 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Fatai Zhang; Gert Grammel
Cc: CCAMP
Subject: RE: [CCAMP] R: R: Overlay model framework and context

Igor,

Irrespectively Yours,

John

> link is not provisioned. The said resource can be shared with other 
> VLs but cannot be de-provisioned  or taken by some unrelated service. 
> This is important because:
> a) it allows for determining fate sharing information for VLs with 
> non- existing underlying data link;
> > 2. According to MRN/MLN is it possible to terminate a virtual link 
> > by a virtual node? What is relationship between VNs and VLs? How 
> > MLN/MRN solves the O(N**2) problem presented by VNT made of VLs?
> > 3. How MLN/MRN addresses the situation when VL with non-existing 
> > data link is advertised, and 3 sec later some service takes a 
> > resource, making impossible to provision the data link when it is 
> > needed? In other words, how MLN/MRN guarantees that the advertised 
> > virtual link is actually useful? Please, provide the quote
> >
> > is no direct (1:1) correlation between the virtual link advertised 
> > to the customer and the provider link. Generally speaking:
> > In our definition it can be terminated either by OE (overlay edge) 
> > or VN (virtual node). Virtual link (as well as VN) is named from the 
> > associated with the UNI reference point.", but G.8080 allows 
> > resource discovery can be allowed over UNI. However, if this is the 
> > only difference between ONI and UNI, can we extend the UNI 
> > definition to allow routing over UNI? We know that discovery (LMP) 
> > could be allowed in OIF UNI 1.0R2 (is LMP signaling?). Can we simply 
> > regard routing
> here as resource discovery?
> > :-)
> >
> > (2) OC&OE vs (CE&PE)
> >
> > I just checked Y.1311 to see the definition of CE&PE. Actually, 
> > CE&PE are just abbreviations. I think CE&PE are generic enough to 
> > fit overlay context. How about to re-define CE&PE in the simliar way 
> > in
> > direct data link may or may not exist between the two end points of 
> > a virtual link."
> >
> > Is this not accurate?
> >
> > (4) I think we can get more useful information from the existing 
> > IETF drafts (LiVPN RFC/drafts) and ITU-T recommendations such as 
> > G.8080, Y.1311, Y.1312....
> >
> >
> > Best Regards
> >
> > Fatai
> >
> >
> > -----邮件原件-----
> > overlay context and my proposal was to call such nodes OE and OC 
> > when generally referring to them withing the overlay context. If in 
> > such context you are proving a VPN, then the OE is a PE and the OC 
> > is a
> CE,
> > >for OE and OC but referring to PE and CE as helpful reference in 
> > >the definition.
> > >
> > >Sergio
> > >
> > >> Belotti Sergio - System Architect ALCATEL-LUCENT  Optics Division
> > >>
> > >>>>> the name of the interface between providers which support 
> > >>>>> L3VPN handoffs?)...
> > >>>>
> > >>>>> to the clients as a single node that exists in the client 
> > >>>>> layer network and is capable of terminating of access, 
> > >>>>> 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.

---

From: John E Drake <[email-masked]>
Date: Thu, 20 Dec 2012 20:12:44 +0000

We disagree.

Irrespectively Yours,

John

> Sent: Thursday, December 20, 2012 12:08 PM
> The point is that the new definition explicitly requires maintaining CP
> state for server resources of the data link that has not been
> provisioned yet. This changes a lot of things.
> 
> I don't actually see any substantive difference between the two
> definitions and the additional points you raise are not part of the new
> defintion.
> 
> Irrespectively Yours,
> 
> John
> 
> 
> > >  what is the difference in this definition of Virtual TE-link in
> MRN
> > > context?
> > >
> > > Is there any inconvenience if we use E-NNI to replace O-NNI? I
> don't
> > > see any difference between them.
> > >
> > > Wrt the MRN what is your proposal? Calling the virtual te-links
> just
> > > VNT?
> > >
> > > >proliferating with other interface definitions, and the usage of
> CE
> > > ,PE
> > > >for nodes.
> > > >similar definitions to what already well defined in the MRN
> context
> > ?
> > > >>
> message

---

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

As always :=).

Irrespectively Yours,

Igor

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, December 20, 2012 3:13 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Fatai Zhang; Gert Grammel
Cc: CCAMP
Subject: RE: [CCAMP] R: R: Overlay model framework and context

We disagree.

Irrespectively Yours,

John

> The point is that the new definition explicitly requires maintaining 
> CP state for server resources of the data link that has not been 
> definitions and the additional points you raise are not part of the 
> new defintion.
> 
> Irrespectively Yours,
> 
> John
> 
> 
> > > 1. According to MRN/MLN is it possible to name a virtual link  
> > > from
> > an
> > > How MLN/MRN address the blocking nature of nodes that terminate 
> > > VLs and access links? Please, provide the quote
> > >
> > > avoid confusion if there are no significant differences between 
> > > the new terms and the existing ones.
> > >
> > > Regarding ONI, the difference between UNI and ONI from your text 
> > > is that routing is allowed to exchange over ONI because it is 
> > > assumed that only signaling is allowed over UNI. I checked UNI 
> > > definition
> in
> > > resource discovery can be allowed over UNI. However, if this is 
> > > the only difference between ONI and UNI, can we extend the UNI 
> > > computation. A direct data link may or may not exist between the 
> > > two end points of a virtual link."
> > >
> > > Is this not accurate?
> > >
> > > when generally referring to them withing the overlay context. If 
> > > in such context you are proving a VPN, then the OE is a PE and the 
> > > OC is a
> > CE,
> > > >>>> apply the same method: those nodes are called Overlay 
> > > >>>> they are the
> > > >>>>> 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
> > > >>>>> client network by injecting virtual topology information 
> > > >>>>> into
> > it.
> > > >>>>> by having intermediate nodes interconnecting Virtual Links 
> > > >>>>> in the middle of the virtual topology
> > > >>>>> could potentially go through a real server domain switch, 
> > > >>>>> the latter's connectivity matrix must expose "internal"
> > > >SRLGs, so that

---

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

Igor

I agree that we should include the multiple network domain scenario. The
question is how would the inter-domain link or provider to provider
interface be any different from cases where there is no overlay customer
network? If there is no different then why use the term overlay in the
terminology (e.g. OC, OE or ONI etc,)?

Regards
Snigdho

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

>  Snigdho,****
>
> ** **
>
> We do consider multi-domain scenario where multiple server network domains
> are interconnected via inter-domain links (which are no different from
> access links). Each such domain contributes to a single Overlay Network
> Topology (ONT) provided to a given set of clients by exposing its own
> virtual topology made of VNs and VLs.****
>
> ** **
>
> Igor****
>
> ** **
>
> *From:* Snigdho Bardalai [mailto:[email-masked]]
> *Sent:* Thursday, December 20, 2012 1:09 PM
> *To:* Daniele Ceccarelli
> *Cc:* Fatai Zhang; Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO);
> CCAMP
>
> *Subject:* Re: [CCAMP] Overlay model framework and context****
>
> ** **
>
> Regarding the question about overlay and VPNs -****
>
> ** **
>
> ****
> ** **
> address both interfaces?****
>
> ** **
>
> Regards****
>
> Snigdho****
>
> [email-masked]> wrote:****
>
> Daniele****
> >Cc: CCAMP****
> >Topology) exists****
> >> IB>> the ONT)****
> >and/or routing****
> >> IB>> exchanges****
> https://www.ietf.org/mailman/listinfo/ccamp****
>
> ** **
>

---

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

Snigdho,
The goal of this framework is to provide an ONT to the clients interconnected via potentially multiple server network domains. Each such domain contributes to the ONT (but does not use it!) the same way as in case of single network domain scenario. How or whether the server network domains talk to each other is irrelevant. They may, for example, not communicate with each other at all, rather, publish their virtual topologies directly on the client PCE. Alternatively, they can use a common instance of a routing protocol to flood its own virtual topology as well as virtual topologies of other domains to the client. An important difference is that unlike, say, in case of ENNI, the server domains are contributors but not users of such  routing information.

Cheers,
Igor
From: Snigdho Bardalai [mailto:[email-masked]]
Sent: Thursday, December 20, 2012 4:05 PM
To: Igor Bryskin
Cc: Daniele Ceccarelli; Fatai Zhang; Lou Berger; BELOTTI, SERGIO (SERGIO); CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

Igor

I agree that we should include the multiple network domain scenario. The question is how would the inter-domain link or provider to provider interface be any different from cases where there is no overlay customer network? If there is no different then why use the term overlay in the terminology (e.g. OC, OE or ONI etc,)?

Regards
Snigdho

On Thu, Dec 20, 2012 at 10:21 AM, Igor Bryskin <[email-masked]<mailto:[email-masked]>> wrote:
Snigdho,

Igor

From: Snigdho Bardalai [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 20, 2012 1:09 PM
To: Daniele Ceccarelli
Cc: Fatai Zhang; Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO); CCAMP

Regards
Snigdho

BR
Daniele

>>>> Phone +390106002512<tel:%2B390106002512>
>>>> Mobile +393346725750<tel:%2B393346725750>

---

From: Snigdho Bardalai <[email-masked]>
Date: Fri, 21 Dec 2012 00:45:35 +0000

Igor,

I think we have 2 possible approaches –

Paths are computed by the client or customer network entities in which case there has to be sufficient knowledge available about the server or provider networks to be able to compute optimal TE paths. The more information available in the client or customer network the more optimized will be the TE paths, which means that there has to be a compromise between optimality and scalability.

The other approach is for the customer network entities to request the provider network (can be a single or multiple domain) to compute the paths using a path computation request and limit the information that is pushed into the customer network. This approach can actually produce highly optimal results without compromising scalability.

I am coming from the mindset of the 2nd approach where I see the inter-domain network problem being independent from the overlay network problem.

Thanks
Snigdho

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

Snigdho,

Cheers,
Igor

Igor

Regards
Snigdho

Igor

Regards
Snigdho

BR
Daniele

---

From: John E Drake <[email-masked]>
Date: Fri, 21 Dec 2012 00:54:47 +0000

Snigdho,

Some time ago we had a discussion on exactly this topic.

We had said that the ONI (or whatever it is currently called), could have signaling, routing, and PCE adjacencies.  Depending upon which of these were enabled one would get an ONI with different operational characteristics.  In your email, the first approach has the routing adjacency enabled and the PCE adjacency disabled, while your second approach has the PCE adjacency enabled and the routing adjacency disabled.

Irrespectively Yours,

John

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

Igor,

Thanks
Snigdho

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

Snigdho,

Cheers,
Igor

Igor

Regards
Snigdho

Igor

Regards
Snigdho

BR
Daniele

---

From: Snigdho Bardalai <[email-masked]>
Date: Fri, 21 Dec 2012 01:01:17 +0000

Hi John,

Yes, we did and a similar idea could apply to the inter-domain case as well without an overlay  client or customer network.

Regards
Snigdho

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

Snigdho,

Irrespectively Yours,

John

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

Igor,

Thanks
Snigdho

Snigdho,

Cheers,
Igor

Igor

Regards
Snigdho

Igor

Regards
Snigdho

BR
Daniele

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 21 Dec 2012 09:24:55 +0100

Igor,

I answered to your mail pointing out there is already virtual link definition matching the three pseudo-req you mentioned in the answer to Fatai.

Obviously if you list further requirements to justify what MRN can do or not today like naming from another space, I can answer no, MRN actually can not do that. But we have a parallel work to improve MRN wrt new requirements , without introducing new definitions of virtual link btw.

The other seems to be like implementation problems like third one that surely I do not need to solve for you . There is no quote for that since they are implementations details. We can talk , if you want off line. I'm happy to do that in that case.

Again, the definition from RFC 4847 does not justify any needs for the  introduction of new concept.

Cheers

Sergio

-----Messaggio originale-----
Da: Igor Bryskin [mailto:[email-masked]]
Inviato: giovedì 20 dicembre 2012 18.06
A: BELOTTI, SERGIO (SERGIO); Fatai Zhang; Gert Grammel
Cc: CCAMP; Lou Berger; Daniele Ceccarelli
Oggetto: RE: [CCAMP] R: R: Overlay model framework and context

Sergio,

You also said:

Cheers,
Igor

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]]
Sent: Thursday, December 20, 2012 11:32 AM
To: Igor Bryskin; Fatai Zhang; Gert Grammel
Cc: CCAMP; Lou Berger; Daniele Ceccarelli
Subject: R: [CCAMP] R: R: Overlay model framework and context

Hi Igor,

See in line

Thanks

Cheers

Sergio

-----Messaggio originale-----
Da: Igor Bryskin [mailto:[email-masked]]
Inviato: giovedì 20 dicembre 2012 16.34
A: Fatai Zhang; Lou Berger; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: CCAMP
Oggetto: RE: [CCAMP] R: R: Overlay model framework and context

Fatai,
You said:
     (3) Virtual link

SB> as in MRN

SB> as in MRN

Cheers,
Igor

Cheers

Sergio

-----Original Message-----
From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, December 19, 2012 9:31 PM
To: Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli
Cc: CCAMP
Subject: 答复: [CCAMP] R: R: Overlay model framework and context

Hi Daniele and all,

(2) OC&OE vs (CE&PE)

(3) Virtual link

Is this not accurate?

Best Regards

Fatai

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 BELOTTI, SERGIO (SERGIO)
发送时间: 2012年12月20日 0:58
收件人: Daniele Ceccarelli
抄送: CCAMP
主题: [CCAMP] R: R: Overlay model framework and context

Ciao Daniele,

See in line

Thanks
Sergio

-----Messaggio originale-----
Da: Daniele Ceccarelli [mailto:[email-masked]]
Inviato: mercoledì 19 dicembre 2012 17.48
A: BELOTTI, SERGIO (SERGIO); Lou Berger
Cc: CCAMP
Oggetto: RE: R: [CCAMP] Overlay model framework and context

Hi Sergio,

SB> Very good example

Ciao
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 21 Dec 2012 15:22:49 +0000

Snigdho.
Please, see in line

Igor

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

Igor,

IB>> I disagree that the more client knows the better. The client needs to work with an abstracted topology that provides just enough information for the client’s needs. For example, consider IP/MPLS clients connected via WDM server network domain. If the client wants his services to be routed diverse from each other, he needs to know about link metrics, SRLGs, bandwidth, colors, etc.  – basically the same stuff he knows about its own links, but he does not need to know about transponders, regenerators, ROADMs, optical impairments, etc. The latter things must be taken care internally when setting up virtual links and nodes advertised to the clients

IB>> I agree with the caveat that the provider’s PCE will work with ONT rather than real physical topologies.
In other words, the client with this option just outsources the path computation job to the provider’s PCE (rather than using its own PCE), but in any case the PCE will have to work on ONT rather than real physical topologies. It may sound strange, but let me give some reasons for that:

1.      Real server domain topology has no knowledge about the client nodes and access links terminated on the client nodes, hence they cannot compute end-to-end paths

2.      In multi-domain scenario server domains do not have full information about inter-domain links;

3.      In multi-domain scenario the client would have to ask each domain separately or orchestrate multiple PCEs working on the same path computation request, which is very difficult to accomplish;

4.      Computing paths on real topologies does not guarantee success, thus totally unpredictable. For example, if a stock broker company  wants to add several more links via server provider in the last 5 min of a trading day, asking provider PCE to compute paths on real provider topology (especially with diversity constarints) may fail.  At the same time ONT VLs are potential paths that have CP state, thus, give you much higher probability of success. Additionally VLs give you a possibility for network pre-planning (e.g. in terms of diverse routing)

5.      Etc.

Trust me, we went through all these options. Having said that, using provider PCE working on ONT (rather than real topologies) is a valuable option, primarily because, as I said once to John, the clients won’t have to be upgraded every time we introduce a new ONT virtualization trick.

Cheers,
Igor

Thanks
Snigdho

Snigdho,

Cheers,
Igor

Igor

Regards
Snigdho

Igor

Regards
Snigdho

BR
Daniele

---

From: Snigdho Bardalai <[email-masked]>
Date: Sat, 22 Dec 2012 01:23:21 +0000

Igor

Please see in-line.

Regards
Snigdho

From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 21, 2012 7:23 AM
To: Snigdho Bardalai; John E Drake; Snigdho Bardalai
Cc: CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Snigdho.
Please, see in line

Igor

Igor,

IB>> I disagree that the more client knows the better. The client needs to work with an abstracted topology that provides just enough information for the client’s needs. For example, consider IP/MPLS clients connected via WDM server network domain. If the client wants his services to be routed diverse from each other, he needs to know about link metrics, SRLGs, bandwidth, colors, etc.  – basically the same stuff he knows about its own links, but he does not need to know about transponders, regenerators, ROADMs, optical impairments, etc. The latter things must be taken care internally when setting up virtual links and nodes advertised to the clients
[SCB] What I meant by “sufficient knowledge” is not about the type of information. I agree that it is the same TE information template. What I am referring to has to do with the knowledge lost with abstraction and in order to overcome the loss the server or provider network will have to advertise more information (e.g. mesh of VLs between VNs) and depending on the size of the provider network this could cause scalability issues.

1.       Real server domain topology has no knowledge about the client nodes and access links terminated on the client nodes, hence they cannot compute end-to-end paths
[SCB] This is easily solved by creating a routing adjacency between the client or customer edge nodes and the server or provider edge nodes.

2.       In multi-domain scenario server domains do not have full information about inter-domain links;
[SCB] This again can be solved by inter-domain TE using PCE techniques such as hierarchical PCE or BRPC.

3.       In multi-domain scenario the client would have to ask each domain separately or orchestrate multiple PCEs working on the same path computation request, which is very difficult to accomplish;
[SCB] That is why the server or provider network should solve its own path computation problem without requiring such tight coupling with the customer or client network.

4.       Computing paths on real topologies does not guarantee success, thus totally unpredictable. For example, if a stock broker company  wants to add several more links via server provider in the last 5 min of a trading day, asking provider PCE to compute paths on real provider topology (especially with diversity constarints) may fail.  At the same time ONT VLs are potential paths that have CP state, thus, give you much higher probability of success. Additionally VLs give you a possibility for network pre-planning (e.g. in terms of diverse routing)
[SCB] Not sure if I agree with this. How would computing with a real topology be worse than computing with a virtual topology? Also, in your example if the resources do not exist how will the virtual links get the resources when it is time to convert these to real LSPs?

5.       Etc.

Trust me, we went through all these options. Having said that, using provider PCE working on ONT (rather than real topologies) is a valuable option, primarily because, as I said once to John, the clients won’t have to be upgraded every time we introduce a new ONT virtualization trick.
[SCB] This is a good point, but working on the ONT or real topology should be decided on how the provider network is structured, for example is it necessary to have an ONT if the provider network is a single IGP area?. BTW – I believe advertising a virtual topology may be applicable to some cases (e.g. PCE solution is not available etc.) and hence it would make sense to have both options available.

Cheers,
Igor

Thanks
Snigdho

Snigdho,

Cheers,
Igor

Igor

Regards
Snigdho

Igor

Regards
Snigdho

BR
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 24 Dec 2012 15:38:24 +0000

Snigdho,
Merry Cliffmas to you and all CCAMPers.

Please, see in line

IB>> True, provider needs to advertise virtual topology instead of real topology. It is expected that VLs and VNs will advertise the same standardized set of attributes as the client links and nodes, so that the client path computation function could treat them the same way. The real server network link and node complexities will be taken care of internally while preparing the virtual topology, so the clients will not have to deal with them. The virtual topology will scale no worse than the real topology

IB>> True, but I hope you agree that the client nodes and access links could be named from an independent naming space (different from the naming space used to name provider nodes and links). Also access links, generally speaking, will exist in a different layer network compared to the provider real (physical) network topology (usually higher, but may be in the same or even lower layer). The point is that the access links do not really fit into the same network topology as the real provider network topology. I mean, you cannot just expand the provider network by one hop  in diameter to be able to compute end-to-end path between the client nodes across the provider domain. Rather, access links (as well as inter-domain links) belong to a separate topology. They can be interconnected across the provider domain(s) by links and nodes existing in the sane layer and named from the same naming space. And this is exactly the goal of virtual topologies.

IB>> Please, see above. Also I know many folks will disagree with me (Dan, when you see me in Orlando, please, do not shoot me) but I don’t believe much in either PCE hierarchies or PCE federations or any other inter- PCE relationships created for the purpose  of a cooperative work on a given path computation request. Here are some reasons for that:

a)      An assumption of universal naming space for all nodes and links in every domain. This assumption has to be made for a construct like federation of PCEs to work;

b)      An assumption that an unreserved network resource in any domain is equally available for any network client as well as for domain internal network building/maintenance;

c)      Sheer level of difficulty, impracticality and poor scalability quality of orchestrating multiple PCEs working on the same path computation request in a multi-domain network, especially one that has significant number of inter-domain links;

d)      Etc.

I do believe, though, in a hierarchy of overlays (Overlay Network Topologies, ONTs), each of each:

a)      Exists in a single domain/single layer network;

b)      Its links and nodes are named from its own network space;

c)      Has its own slice of provider physical network resources (dedicated or sharable with some or all other ONTs according to the provider policies)

d)      Has a separate PCE that performs path computation within the ONT in question ( for the purpose of redundancy and load-balancing, of course, there could be several PCEs, but all of them will work on the same topology, so, conceptually, there will be one PCE per ONT)

Note, that the presence of the PCE (albeit very desirable) is not mandatory. Because ONT is always mapped exactly onto one domain with the full TE visibility for every ONT member, client nodes will be able to compute end-to-end paths on their own. So in a way, ONTs will provide an alternative (to PCE architecture) solution for inter-domain traffic engineering.

IB>> Computing end-to-end paths is the problem of a client, not provider. It is the client who wants his two services be placed diverse form each other, for example

IB>> This is a Christmas miracle! :=) You see, unreserved real network resources (e.g. in PCE architecture) is up for grabbing by anyone at any time. Advertised virtual links, on the other hand, will have a state for each of resources they depend on, so that said resources will not be de-provisioned or taken by some services unrelated to VL. This state will also will govern (through the internal policies) how the resources are shared between mutually exclusive VLs. For example, a client can be presented with a virtual topology that may include mutually exclusive VLs (this fact is indicated via the MELG mechanism) but it may be arranged that the VLs will not share resources with VLs advertised to other clients. In other words, the client will know that the VL resources are all his, and it is up to the client to decide how to use them.

5.      Etc.

Trust me, we went through all these options. Having said that, using provider PCE working on ONT (rather than real topologies) is a valuable option, primarily because, as I said once to John, the clients won’t have to be upgraded every time we introduce a new ONT virtualization trick.
[SCB] This is a good point, but working on the ONT or real topology should be decided on how the provider network is structured, for example is it necessary to have an ONT if the provider network is a single IGP area?.

IB>> Yes, as long as it happens in the overlay model

BTW – I believe advertising a virtual topology may be applicable to some cases (e.g. PCE solution is not available etc.) and hence it would make sense to have both options available.

IB>> Agree

Cheers,
Igor

Thanks
Snigdho

Snigdho,

Cheers,
Igor

Igor

Regards
Snigdho

Igor

Regards
Snigdho

BR
Daniele

---

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

Thanks for a very comprehensive summary.

Couple of comments.
a) "6. Overlay Customer (OC): Something like the CN in RFC4208 ..." Do you mean EN instead of CN? It appears to be a typo unless I am mistaken.
b) " 7. Overlay Edge (OE): Something like the EN in RFC4208 .."  Do you mean CN instead of EN?
c) "does not scale because of N**2 problem. IP over ATM and single-segment PWs have the same issue, ..."  So does this mean this "intermediate" node needs to be redundant?

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

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

This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Iftekhar Hussain <[email-masked]>
Date: Tue, 25 Dec 2012 00:08:41 +0000

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:[email-masked]] 
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:
> In the case of the interface we generally define the ONI as an overlay 

I have no idea what this means.  I suspect it relates to comments below, so will discuss there.

> Overlay Edge and in the particular case of VPNs they are the CE and PE 

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 

> 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

>> people, some others to a set a viable options, some others to totally 
>> being de-provisioned) and which can be instantiated in the data plane 
>>to path carachteristics, e.g. TE-metrics, collected  SRLG, path delay 
>>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).
>> 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
>> integration  5. The overlay model assumes one instance for the client 
>> network and a separate instance for the server network and in the ONI 
>> describing connectivity constraints between access links and virtual 
>> links they terminate.
>>>
>>>
>>>

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 27 Dec 2012 19:02:00 +0000

Igor,

A very happy holiday greetings to you and everybody on the list.

My responses are below in green.

Regards
Snigdho

From: Igor Bryskin [mailto:[email-masked]]
Sent: Monday, December 24, 2012 7:38 AM
To: Snigdho Bardalai; John E Drake; Snigdho Bardalai
Cc: CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Snigdho,

Please, see in line

IB>> True, provider needs to advertise virtual topology instead of real topology. It is expected that VLs and VNs will advertise the same standardized set of attributes as the client links and nodes, so that the client path computation function could treat them the same way. The real server network link and node complexities will be taken care of internally while preparing the virtual topology, so the clients will not have to deal with them. The virtual topology will scale no worse than the real topology
[SCB] Not so sure if the virtual topology scales the same as a real topology. The virtual topology advertised to one client edge node scales with the square of the number of VNs instead of number of real-nodes. Depending on the characteristic of the PE nodes a VN could be 1:1 with an access-link (assuming here a VN is used to address connectivity restrictions vs a connectivity matrix, either approach will require the exact same amount of information) . This means in the worst-worst case the virtual topology scales with the square of the number of access links. Additionally, there may be multiple paths within the provider network which will add to the amount of TE information.

IB>> True, but I hope you agree that the client nodes and access links could be named from an independent naming space (different from the naming space used to name provider nodes and links). Also access links, generally speaking, will exist in a different layer network compared to the provider real (physical) network topology (usually higher, but may be in the same or even lower layer). The point is that the access links do not really fit into the same network topology as the real provider network topology. I mean, you cannot just expand the provider network by one hop  in diameter to be able to compute end-to-end path between the client nodes across the provider domain. Rather, access links (as well as inter-domain links) belong to a separate topology. They can be interconnected across the provider domain(s) by links and nodes existing in the sane layer and named from the same naming space. And this is exactly the goal of virtual topologies.
[SCB] Agree, there has to be a separate naming space for the client elements and access links. This does not mean the provider network has to advertise a virtual topology – at a minimum the PE nodes has to be able to route the signaling message correctly within the provider network. This is clearly described in RFC 4208.

IB>> Please, see above. Also I know many folks will disagree with me (Dan, when you see me in Orlando, please, do not shoot me) but I don’t believe much in either PCE hierarchies or PCE federations or any other inter- PCE relationships created for the purpose  of a cooperative work on a given path computation request.
[SCB] Agree, cross network PCE hierarchies or federations may be difficult to achieve. On the other hand it may be possible to create a PCE adjacency (John D came up with this term) between the customer and provider edge. How the PCE request messages are handled within each network is completely hidden. For example, there may be multiple PCEs or a hierarchy of PCEs within the provider network that is not known to the customer network.

Here are some reasons for that:

a)      An assumption of universal naming space for all nodes and links in every domain. This assumption has to be made for a construct like federation of PCEs to work;
[SCB] A PCE adjacency concept could address this.

b)      An assumption that an unreserved network resource in any domain is equally available for any network client as well as for domain internal network building/maintenance;
[SCB] If the provider computes the path then all the necessary policies can be easily applied.

c)       Sheer level of difficulty, impracticality and poor scalability quality of orchestrating multiple PCEs working on the same path computation request in a multi-domain network, especially one that has significant number of inter-domain links;
[SCB] Multi-domain TE is a complex problem and an approach with many layers of virtual topologies has its own set of disadvantages. Some are listed below:

i)                    Diverse path computation is inherently inefficient since it is not possible to carry out simultaneous computations

ii)                  Scale vs accuracy – in order to address scale it will be necessary to eliminate details

iii)                Maintaining the virtual topology in real-time will add to the processing requirements

Not saying the PCE approach is perfect either and hence my opinion is that both will be required even co-exist in the same deployment.
Etc.

d)      Has a separate PCE that performs path computation within the ONT in question ( for the purpose of redundancy and load-balancing, of course, there could be several PCEs, but all of them will work on the same topology, so, conceptually, there will be one PCE per ONT)
[SCB] At least one PCE per ONT makes sense. That is exactly what I am saying as well.

IB>> Computing end-to-end paths is the problem of a client, not provider. It is the client who wants his two services be placed diverse form each other, for example
[SCB] Agree, but the diverse requirement applies to the provider network and the client will not have full details of the provider network. The ONT can potentially provide that information but there is a cost associated with it, additionally will providers really want to expose this information to multiple customers?

IB>> This is a Christmas miracle! :=) You see, unreserved real network resources (e.g. in PCE architecture) is up for grabbing by anyone at any time. Advertised virtual links, on the other hand, will have a state for each of resources they depend on, so that said resources will not be de-provisioned or taken by some services unrelated to VL. This state will also will govern (through the internal policies) how the resources are shared between mutually exclusive VLs. For example, a client can be presented with a virtual topology that may include mutually exclusive VLs (this fact is indicated via the MELG mechanism) but it may be arranged that the VLs will not share resources with VLs advertised to other clients. In other words, the client will know that the VL resources are all his, and it is up to the client to decide how to use them.
[SCB] Sorry don’t buy it ☺ - the advertised VL states are only at the edges not necessarily in the middle of the network and hence unreserved network resources are still up for grabs. On the other hand the VLs could be established as FAs but then the overall network connectivity is reduced since bandwidth is pre-committed between specific edges.

5.       Etc.

IB>> Yes, as long as it happens in the overlay model
[SCB] As mentioned in the comment above RFC 4208 describes a method that can avoid a virtual topology to be pre-existing.

IB>> Agree

Cheers,
Igor

Thanks
Snigdho

Snigdho,

Cheers,
Igor

Igor

Regards
Snigdho

Igor

Regards
Snigdho

BR
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 28 Dec 2012 15:22:51 +0000

Snigdho,

Please, see in line. We have a few disconnects.

Igor

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

IB>> Network topology (real or virtual) scale depends on number of links rather than nodes. In fact, the more you put multi-degree nodes in the topology the better, because for the same connectivity requirements across the topology it would take less links. For example, if the topology is made of N PEs it requires O(N**2)  links to fully interconnect them. But if you put N-degree P in the middle of the topology, the same full connectivity would take just N links. Virtual Nodes will normally require connectivity constraint matrix advertising, However, a single VN can represent a piece or even entire domain. Besides, VNs can be arbitrarily and in an unlimited way nested within each other (Russian dolls). This means much better scaling options than, say, offered  by multi-area IGP-TE.

IB>> 4208 says nothing about TE routing and path computation in the multi-space environments

IB>> PCEs use PCEP to communicate. PCEP (unlike RSVP and OSPF) is TCP based protocol and as such does not require adjacencies, rather, TCP sessions (just like BGP or LDP). So, I do not understand the concept of PCE adjacency nor how it can help
Here are some reasons for that:

IB>> How ?

IB>> How ?

i)                 Diverse path computation is inherently inefficient since it is not possible to carry out simultaneous computations
IB>> ONTs will contain sufficient information for diverse computations within the VNT

IB>> ONTs will contain sufficient information for all client needs yet abstracted from details, say, of transport network technologies

IB>> True, but this is done in background

IB>> BTW, one thing I forgot to mention. Because ONTs are logical, independent and isolated, there will be no need to play spy games with keys and encrypted EROs, as multi-domain PCE approach suggests

Etc.

IB>> I disagree with you here, VLs as any other TE links, will advertise SRLGs, so the diverse path computation will be possible for the client. VLs unlike real links will have no problem to be disclosed to the clients

IB>> I think you are missing the point here. When I say VLs have a state for every network resource they depend on, I mean *all resources* not just on the edges. Each such resource will have a small state allowing the resource to be sharable between a set of VLs, but protecting the resource to be taken away by other services or from being de-provisioned. I know that this is possible to achieve in a very scalable way, because, we’ve done just that already.

5.      Etc.

IB>> 4208 makes clients completely TE blind, so it is irrelovent in this discussion

IB>> Agree

Cheers,
Igor

Thanks
Snigdho

Snigdho,

Cheers,
Igor

Igor

Regards
Snigdho

Igor

Regards
Snigdho

BR
Daniele

---

From: Snigdho Bardalai <[email-masked]>
Date: Mon, 31 Dec 2012 17:23:48 +0000

Igor,

IB>> 4208 says nothing about TE routing and path computation in the multi-space environments
[SCB] True, but I am referring to the signaling specification which does not require a virtual topology to be pre-existing.

IB>> PCEs use PCEP to communicate. PCEP (unlike RSVP and OSPF) is TCP based protocol and as such does not require adjacencies, rather, TCP sessions (just like BGP or LDP). So, I do not understand the concept of PCE adjacency nor how it can help
[SCB] PCE adjacency is nothing special; a client or customer PCC talks to a provider PCE. The only requirement here has to do with the communication between the PCC and PCE, without impacting the separation of customer and provider naming spaces.

IB>> VLs as any other TE links, will advertise SRLGs, so the diverse path computation will be possible for the client. VLs unlike real links will have no problem to be disclosed to the clients
Agree, VLs can have SRLGs and the clients will have no issues using this information. When it comes to maintaining diverse VLs, each VL will need one or more partnering diverse VLs (not necessarily between the same pair of customer or client edge nodes). This will require the provider network to explicitly create these VLs and reserve the necessary resources upfront.

IB>> When I say VLs have a state for every network resource they depend on, I mean *all resources* not just on the edges. Each such resource will have a small state allowing the resource to be sharable between a set of VLs, but protecting the resource to be taken away by other services or from being de-provisioned. I know that this is possible to achieve in a very scalable way, because, we’ve done just that already.
[SCB] The issue of first-come first serve still exists whether the resources are shared between a set of VLs or is open to be shared between any VL.

Regards
Snigdho

From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, December 28, 2012 7:23 AM
To: Snigdho Bardalai; John E Drake; Snigdho Bardalai
Cc: CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Snigdho,

Igor

Etc.

5.       Etc.

IB>> Agree

Cheers,
Igor

Thanks
Snigdho

Snigdho,

Cheers,
Igor

Igor

Regards
Snigdho

Igor

Regards
Snigdho

BR
Daniele