Re: [CCAMP] Overlay model framework and context

[Daniele Ceccarelli <[e-mail]>]

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!!!  :)


>-----Original Message-----
>From: Lou Berger [mailto:[e-mail]] 
>Sent: giovedì 20 dicembre 2012 16.42
>To: Daniele Ceccarelli
>Cc: Fatai Zhang; Igor Bryskin; BELOTTI, SERGIO (SERGIO); CCAMP
>Subject: Re: [CCAMP] Overlay model framework and context
>
>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
>
>On 12/20/2012 10:32 AM, Daniele Ceccarelli wrote:
>> 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
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Lou Berger [mailto:[e-mail]]
>>> Sent: giovedì 20 dicembre 2012 15.39
>>> To: Daniele Ceccarelli
>>> Cc: Fatai Zhang; Igor Bryskin; BELOTTI, SERGIO (SERGIO); CCAMP
>>> Subject: Re: [CCAMP] Overlay model framework and context
>>>
>>> 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:
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Fatai Zhang [mailto:[e-mail]]
>>>>> 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
>>>>>
>>>>> -----邮件原件-----
>>>>> 发件人: [e-mail] [mailto:[e-mail]] 代表
>>>>> Lou Berger
>>>>> 发送时间: 2012年12月20日 7:08
>>>>> 收件人: Igor Bryskin
>>>>> 抄送: CCAMP
>>>>> 主题: Re: [CCAMP] Overlay model framework and context
>>>>>
>>>>> Igor,
>>>>>
>>>>> You said:
>>>>> IB>> I like "access links" and "inter-domain links" better.
>>>>>
>>>>> This works for me.
>>>>>
>>>>> Lou
>>>>>
>>>>> On 12/19/2012 12:27 PM, Igor Bryskin wrote:
>>>>>> Lou, please see my answers to your questions
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] [mailto:[e-mail]]
>>>>> 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,
>>>>>>
>>>>>> Plese find replies in line.
>>>>>>
>>>>>> BR
>>>>>> Daniele
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lou Berger [mailto:[e-mail]]
>>>>>>> Sent: lunedì 17 dicembre 2012 20.45
>>>>>>> To: Daniele Ceccarelli
>>>>>>> Cc: CCAMP
>>>>>>> Subject: Re: [CCAMP] Overlay model framework and context
>>>>>>>
>>>>>>>
>>>>>>> Daniele,
>>>>>>> 	Thanks for getting this on-list discussion 
>going.  I have some 
>>>>>>> comments and questions:
>>>>>>>
>>>>>>> - So what's a "client layer network" in this context?  
>>> Perhaps you
>>>>>>> mean OC or "(overlay) customer layer"?
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> 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"?
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>>
>>>>>>> - 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.
>>>>>> IB>> agree
>>>>>>
>>>>>> 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
>>>>>> IB>> Agree
>>>>>>
>>>>>>  (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?
>>>>>>
>>>>>> IB>> As long as it allows for both or either signaling
>>>>> and/or routing
>>>>>> IB>> exchanges
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>>
>>>>>>> Much thanks,
>>>>>>> Lou
>>>>>>>
>>>>>>> On 12/17/2012 6:17 AM, Daniele Ceccarelli wrote:
>>>>>>>> Dear CCAMPers,
>>>>>>>>
>>>>>>>> In the last weeks several off-line discussions on the
>>>>>>> Overlay model framework and related works took place. Some 
>>>>>>> discussions led to some sort of agreemet among a small group of 
>>>>>>> people, some others to a set a viable options, some others
>>>>> to totally
>>>>>>> open issues. I tried to summarize the output of such 
>discussions 
>>>>>>> below so to progress the discussions into a single thread
>>>>> on the WG ML.
>>>>>>>>
>>>>>>>> Please note that the aim of this mail is not to present a
>>>>>>> well shaped and conclusive idea to the WG but rather to
>>> provide the
>>>>>>> basis for starting a discussion from a barely shaped idea
>>> (step 1)
>>>>>>> instead of starting it from scratch (step 0).
>>>>>>>>
>>>>>>>> In addition you can find attached a slide depicting a
>>>>>>> proposal of the overlay scenario.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Daniele
>>>>>>>>
>>>>>>>> + Disclaimer:
>>>>>>>>  1. Packet opto integration is often considered but the work
>>>>>>> can be extented to any type of SC. Eg. TDM over LSC.
>>>>>>>>
>>>>>>>> + Terminology:
>>>>>>>>
>>>>>>>>  1. Virtual Link: A virtual link is a potential path between
>>>>>>> two virtual or real network elements in a client layer
>>>>> network  that
>>>>>>> is maintained/controlled in and by the server domain
>>> control plane
>>>>>>> (and as such cannot transport any traffic/data and 
>protected from 
>>>>>>> being
>>>>>>> de-provisioned) and which can be instantiated in the data
>>>>> plane (and
>>>>>>> then can carry/transport/forward traffic/data) preserving
>>>>> previously
>>>>>>> advertised attributes such as fate sharing information.
>>>>>>>>  2.  Virtual Node: Virtual node is a collection of zero or
>>>>>>> more server network  domain nodes that are collectively
>>> represented
>>>>>>> to the clients as a single node that exists in the client layer 
>>>>>>> network and is capable of terminating of access, 
>inter-domain and 
>>>>>>> virtual links.
>>>>>>>>  3.Virtual Topology: Virtual topology is a collection of one
>>>>>>> or more virtual or real server network domain nodes that
>>>>> exist in the
>>>>>>> client layer network and are interconnected via 0 or 
>more virtual 
>>>>>>> links.
>>>>>>>>  4. Overlay topology:  is a superset of virtual topologies
>>>>>>> provided by each of server network domains, access and
>>> inter-domain
>>>>>>> links.
>>>>>>>>  5. Access Link: Link between OC and OE. GMPLS runs on that
>>>>>>> link. It can support any of the SCs supported by the GMPLS.
>>>>>>>>  6. Overlay Customer (OC): Something like the CN in RFC4208
>>>>>>> teminology  but (i) receiving virtual topology from the
>>>>> core network
>>>>>>> and requesting the set up of one of them or (ii) requesting the 
>>>>>>> computation and establishment of a path accordingly to gien 
>>>>>>> constraints in the core network and receiving the parameters 
>>>>>>> characterizing such path. (ii) == UNI.
>>>>>>>>  7. Overlay Edge (OE): Something like the EN in RFC4208 but
>>>>>>> able to deal with (i) and (ii) above.
>>>>>>>>  8. ONI : Overlay network interface: Interface allowing for
>>>>>>> signaling and routing messages exchange between Overlay 
>and Core 
>>>>>>> network. Routing information consists on virtual topology 
>>>>>>> advertisement. When there is no routing adjacency across the 
>>>>>>> interface it is equivalent to the GMPLS UNI defined in 4208.
>>>>>>> Signaling messages are compliant with RFC4208. Information
>>>>> related to
>>>>>>> path carachteristics, e.g. TE-metrics, collected SRLG, 
>path delay 
>>>>>>> etc, either passed from OE to OC via signaling after the LSP 
>>>>>>> establishment in the core network or from OC to OE to be
>>>>> used as path
>>>>>>> computation constraints, fall under the definition of
>>>>> signaling info
>>>>>>> and not routing info).
>>>>>>>>  9. O-NNI (name to be found,maybe reused): Interface on the
>>>>>>> links between different core networks in the overlay model 
>>>>>>> environment, i.e. Between border OEs. Same features of the
>>>>> ONI apply
>>>>>>> to this interface. Could it be an E-NNI? A ONI? A new name
>>>>> is needed?
>>>>>>>>
>>>>>>>> + Statements
>>>>>>>>  1. In the context of overlay model we are aiming to build
>>>>>>> an overlay
>>>>>>>> topology for the client network domains  2. The overlay
>>>>>>> topology is comprised of:
>>>>>>>>     a) access links (links connecting client NEs to the
>>>>>>> server network domains). They can be PSC or LSC.
>>>>>>>>     b) inter-domain links (links interconnecting server
>>>>>>> network domains)   
>>>>>>>>     c) virtual topology provided by the server network
>>>>>>> domains. Virtual Links + Virtual Nodes (TBD) +
>>> Connectivity Matrix
>>>>>>> (with a set of parameters e.g. SRLG, optical impairments,
>>> delay etc
>>>>>>> for each entry) describing connectivity between access 
>links and 
>>>>>>> virtual links.
>>>>>>>>  3. In the context of overlay model we manage  hierarchy
>>>>> of overlay
>>>>>>>> topologies with overlay/underlay relationships  4. In the
>>>>> context of
>>>>>>>> overlay model multi-layering and inter-layer relationships
>>>>>>> are peripheral at best, it is all about horizontal network 
>>>>>>> integration 5. The overlay model assumes one instance for
>>>>> the client
>>>>>>> network and a separate instance for the server network and
>>>>> in the ONI
>>>>>>> case the server network also surreptitiously 
>participates in the 
>>>>>>> client network by injecting virtual topology 
>information into it.
>>>>>>>>  6. L1VPN (and LxVPN) in general is a service provided over
>>>>>>> the ONI (it falls under the UNI case as no routing
>>> adjacency is in
>>>>>>> place between OC and OE).
>>>>>>>>
>>>>>>>> + Open issues/questions
>>>>>>>>  
>>>>>>>>  1. PCE-PCEP - do we need to include considerations about
>>>>>>> PCE and PCEP into the overlay framework context?
>>>>>>>>  2. BGP-LS needs to be considered  3. Should potentials be 
>>>>>>>> included? E.g. I2RS?
>>>>>>>>
>>>>>>>> + Appendix:
>>>>>>>> Some notes on the Virtual Node:
>>>>>>>> 1.      Virtual Link Model along, sadly, does not scale 
>>>>>>> because of N**2 problem. IP over ATM and single-segment PWs
>>>>> have the
>>>>>>> same issue, that's why people invented multi-segment PWs
>>>>>>>> 2.      The only way to avoid full-mesh of Virtual Links is 
>>>>>>> by having intermediate nodes interconnecting Virtual 
>Links in the 
>>>>>>> middle of the virtual topology
>>>>>>>> 3.      These intermediate nodes cannot be real server 
>>>>>>> domain switches, because, generally speaking:
>>>>>>>>   a)Real switches belong to different layer network;
>>>>>>>>   b)Real switches are named from different naming space
>>>>>>>>   c)real switches individually may not have sufficient
>>>>>>> resources to terminate virtual links (while a group of real
>>>>> switches
>>>>>>> collectively will have)
>>>>>>>>   d)Presenting a group of real switches as a single virtual
>>>>>>> node have better scalability qualities
>>>>>>>> 4.      Even if you map a virtual node on a single real 
>>>>>>> node, you need to keep in mind that real server domain
>>>>> switches are,
>>>>>>> generally speaking, blocking switches and as such must
>>> expose their
>>>>>>> connectivity matrices
>>>>>>>> 5.      If you want to compute SRLG-disjoint paths that 
>>>>>>> could potentially go through a real server domain switch, the 
>>>>>>> latter's connectivity matrix must expose "internal"
>>> SRLGs, so that
>>>>>>> the two services traversing the switch will not
>>> simultaneously fail
>>>>>>> if a single internal element shared by the services fails
>>>>>>>> 6.      If you walk through all cases that need to be 
>>>>>>> addressed when you are traffic engineering topologies
>>> with blocking
>>>>>>> switches, you will understand that there is absolutely no
>>>>> difference
>>>>>>> between a virtual node and real blocking real node.
>>>>>>>> 7.      Even in case of pure VL model, client NEs connected 
>>>>>>> to server network domain must be upgraded so that they could 
>>>>>>> understand the connectivity matrices advertised by the
>>> border nodes
>>>>>>> describing connectivity constraints between access links
>>>>> and virtual
>>>>>>> links they terminate.
>>>>>>>>
>>>>>>>>
>>>>>>>>  
>>>>>>>> ===================================
>>>>>>>> DANIELE CECCARELLI
>>>>>>>> System & Technology - PDU Optical & Metro
>>>>>>>>
>>>>>>>> Via E.Melen, 77
>>>>>>>> Genova, Italy
>>>>>>>> Phone [phone]
>>>>>>>> Mobile [phone]
>>>>>>>> [e-mail]
>>>>>>>> www.ericsson.com
>>>>>>>>
>>>>>>>> This Communication is Confidential. We only send and receive
>>>>>>> email on
>>>>>>>> the basis of the term set out at
>>> www.ericsson.com/email_disclaimer
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> CCAMP mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>
>>>
>> 
>