[CCAMP] 答复: Overlay model framework and context

[Fatai Zhang <[e-mail]>]

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 (which may be in the same, lower or higher layer network than of 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 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