Re: [CCAMP] Overlay model framework and context

[Daniele Ceccarelli <[e-mail]>]

Hi Gert,

I'm working on it...in these days the list was not busy on the overlay but was on the OTN :-)

It will be available al latest tomorrow.

Ciao
Daniele

>-----Original Message-----
>From: Gert Grammel [mailto:[e-mail]] 
>Sent: martedì 15 gennaio 2013 17.29
>To: Daniele Ceccarelli; Lou Berger
>Cc: CCAMP
>Subject: RE: [CCAMP] Overlay model framework and context
>
>Hi Daniele,
>
>The list wasn't so busy anymore in 2013 as it was the year 
>before. Would you mind to summarize what is perceived the 
>wording/abbreviations we are converging to? This way we could 
>start updating the wording of the ENNI framework document.
>
>Best
>
>Gert
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Daniele Ceccarelli
>Sent: Donnerstag, 20. Dezember 2012 16:52
>To: Lou Berger
>Cc: CCAMP
>Subject: Re: [CCAMP] Overlay model framework and context
>
>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
>>>>>>
>>>>>
>>>>
>>> 
>>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp
>