Re: [CCAMP] Overlay model framework and context

[Snigdho Bardalai <[e-mail]>]

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:[e-mail]]
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,

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] 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,

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] 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,
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:[e-mail]]
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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
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 -

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 <[e-mail]<mailto:[e-mail]>> 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]<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]> [mailto:[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]> [mailto:[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]<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]<tel:%2B390106002512>
>>>> Mobile [phone]<tel:%2B393346725750>
>>>> [e-mail]<mailto:[e-mail]>
>>>> www.ericsson.com<http://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<http://www.ericsson.com/email_disclaimer>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> [e-mail]<mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
>_______________________________________________
>CCAMP mailing list
>[e-mail]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/ccamp
>
_______________________________________________
CCAMP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ccamp