Re: [CCAMP] Overlay model framework v2

[Dieter Beller <[e-mail]>]

Hi Gert, Snigdho, all,

I agree with the statement that:

"we need to keep client/server and customer/provider boundaries completely independent of each other"

At least the "customer-edge/provider-edge" terminology originally defined for VPNs does reflect
the fact that this is a horizontal interface as opposed to client/server in the multi-layer context.


Thanks,
Dieter

On 23.01.2013 00:51, Gert Grammel wrote:

Snigdho,

 

Not sure why you disagree, it rather seems we are saying the same thing. Client/server is *not* customer/provider. That’s why I am struggling to accept the notion of ‘Customer-Edge’ and ‘Provider-Edge’ for a relationship that has nothing to do with customers. As a consequence VPN wording (=customer/provider) as proposed by Lou has not the right semantic for an overlay network. Yet by just making such statements, we are no inch closer to an acceptable terminology. If you are not happy with client-Edge and provider-edge feel free to propose other terms. Eventually we have to come to a conclusion.

 

Best

 

Gert

 

From: Snigdho Bardalai [mailto:[e-mail]]
Sent: Mittwoch, 23. Januar 2013 00:06
To: Gert Grammel; Lou Berger; Daniele Ceccarelli
Cc: CCAMP
Subject: RE: [CCAMP] Overlay model framework v2

 

Hi Gert,

 

Sorry, but I have to disagree with your statement (BTW - are we going in circles – I thought we had already beaten this topic to death ☺). It is possible to have client-server relationships totally contained within a customer or provider network and not visible across the CE-PE or PE-PE interface. That is the reason why we need to keep client/server and customer/provider boundaries completely independent of each other.

 

Thanks

Snigdho

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Gert Grammel
Sent: Tuesday, January 22, 2013 2:34 PM
To: Lou Berger; Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

 

Hi Lou, Daniele,

 

Thanks for summarizing, seems we are converging. Related to terminology I still think that 'customer' and 'provider' give the wrong connotation for overlay networks. While a VPN can be seen as a service, hence both terms might have some justification, a Overlay-UNI/ENNI does not. It's simply a name for a control interface that can be used internally in a network without necessarily providing a customer with any new service. Having to choose between ‘Customer-Provider’ or ‘Client-Server’ terminology , the latter fits much better to what we call Overlay.  

 

To move on with terminology we may want to preserve the abbreviations by adding 'overlay':

1.       Overlay-Provider-edge (OPE) – at least it provides a topology to the client

2.       Overlay-Client-edge (OCE) - Note there is no customer here, it’s a client

 

About Virtual topology 3):

•         real-nodes vs. virtual nodes: from a OCE perspective there shall be no difference. In other words there shall be no difference between an OPE Network exposing virtual nodes and an equivalent OPE network where each virtual node is replaced by a real node of equal characteristic.

 

I would support the connotation of a UNI, an augmented UNI and an O(verlay)NNI (or OCE-OPE interface):

1.       UNI: signaling only, no topology information exchanged (targeted for a customer/provider interface where Client=customer)

2.       Augmented-UNI: signaling only, with post-provisioned topology information of LSPs

3.       ONNI: signaling and routing , where routing injects topology information independent of LSPs

 

Best

 

Gert

 

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Lou Berger
Sent: Montag, 21. Januar 2013 23:13
To: Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

 

Thanks Daniele, See below.

 

On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote:

> Hi Lou,

>

> Please find comments in line

>

> BR

> Daniele

>

>> -----Original Message-----

>> From: Lou Berger [mailto:[e-mail]]

>> Sent: venerdì 18 gennaio 2013 18.27

>> To: Daniele Ceccarelli

>> Cc: CCAMP

>> Subject: Re: [CCAMP] Overlay model framework v2

>> 

>> Daniele,

>>          Very nice summary.  Just catching up, so sorry for the

>> (2 day) late response.

>> 

>> I really like how the terminology has evolved and appreciate the

>> summary!

>> 

>> I have a few detail comments, but before I go there I'd like to cover

>> one more open issue that I think will have some

>> (minor) ripple effects on the details.

>> 

>> I think there's still the general issue of terminology to use when

>> referring to the entity that "uses an overlay" and the entity that

>> "instantiates the overlay".  In your mail and in discussion we have:

>> 

>> - client (service)/OC/CN/customer

>> 

>> and

>> 

>> - server(or service)/OE/EN/provider

>> 

>> I think we had discussed, and possibly agreed on, using VPN

>> terminology which would have us use the latter options, i.e.,

>> (overlay) customer/provider (edge).  This would mean eliminating any

>> references to client/server in the *generic

>> overlay* definitions.  Of course these terms may reemerge in other

>> contexts as they have before, e.g., rfc6215.

>

> Yes, i think we all agreed. If there are still terms different from

> customer/provider in the text it's because i missed them during the

> replacing.

>

 

Great!  Glad I didn't miss something over the holidays!

 

>> 

>> I like this approach as it is aligned with the much of IETF work on

>> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). 

>> Importantly, RFC 4847 even has quite a few concepts that can be

>> directly leveraged in this discussion.

>> 

>> I'd even go further and say that we should base the definitions and

>> resulting framework on RFC 4847.  For example, the definitions below

>> could start with something along the lines:

>> 

>>    The overlay service model, at a high level, follows Section

>>    7. of RFC 4847 as represented by:

>> 

>> 

>>                        +--------------------+

>>                  :     |                    |     :

>>                  :     |                    |     :

>>         +----+   :   +----+              +----+   :   +----+

>>         | CE |---:---| PE |              | PE |---:---| CE |

>>         +----+   :   +----+              +----+   :   +----+

>>                  :     |                    |     :

>>                  :     |                    |     :

>>                  :     +--------------------+     :

>>                  :     |                    |     :

>>                  :     |<-Provider network->|     :

>>             Customer                           Customer

>>             interface                          interface

>> 

>>                  Figure 7.2: Overlay Service Model

>> 

>>    In this model, the overlay is instantiated by an overlay

>>    "provider" and its provider edge (PE) nodes , and is used by

>>    the overlay "customer" which is connected to the provider via

>>    customer interfaces attached to customer edge (CE) nodes.

>> 

>>    ...

>> 

>> The definition below would need to be tweaked slightly, notably to

>> remove any references to client and server.  The resulting framework

>> can also refer back to RFC 4847 as needed.

>> 

>> See below for some additional comments.

>> 

>> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote:

>>> Dear overlayers,

>>> 

>>> Please find below a new version (v2) of the framework summary

>>> reflecting the latest discussions. Again i hope i've

>> captured all the

>>> comments around, sorry if anything is missing, in case just let me

>>> know what i missed.

>>> 

>>> BR

>>> 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 provider layer network

>> that is

>>> maintained/controlled in and by the provider 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.

>>> 

>> 

>> You say "potential path".  I this this should read  "potential or

>> instantiated path".

>> 

>

> Maybe we need to define also what "potential" stands for? At least two

> cases come to my mind (which might be included under the "potential"

> umbrella):

>

> 1. resources reserved via signaling but not instantiated

 

Sure.  Sounds like a RFC6001 soft FA.

 

> 2. resources not even signaled. In presence of a centralized entity

> managing the network (sort of PCE plus something) there is no need to

> reserve resources via signaling as the central entity is the only

> thing that can reserve or allocate resources. I'm thinking to an

> opening towards the integration with the SDN world.

>

 

Sure.  Sounds like a Virtual TE link (per RFC6001, 5212).

 

> Just loud thinking, does it make sense?

>

>>From my perspective, I think a node in the overlay really shouldn't

>> *directly* distinguish between the two -- now one may have a 

>>different metric/SRLG/weight/etc, but these are abstracted 

>>representations of the tradeoffs between use of the two, that  can be

>>provided by the underlying provider network, rather  than a direct

>>indication.

>> 

>>> 2.  Virtual Node: Virtual node is a collection of zero or more

>>> provider network domain nodes that are collectively

>> represented to the

>>> clients as a single node that exists in the customer layer

>> network and

>>> is capable of terminating of access, inter-domain and virtual links.

>>> 

>> 

>> I'm a little uncomfortable with the linkage of real nodes to virtual

>> nodes.  I think VN is a purely abstract concept that may be

>> instantiated using parts/whole/multiple/logical/real/etc nodes.

>

> Makes sense. What this definition adds to the one in RFC4847 is

> basically the fact that also parts of a node can be considered. What

> saying that it can be a real node i meant 1:1 correspondance between a

> real and a virtual node. Your definition covers that case also, that's

> fine.

>

>> 

>> How about something like:

>> Virtual Node: A virtual node is a representation of a collection of

>> provider resources that are interconnected via virtual (and customer)

>> links.  A virtual node may be collection of zero or more, including

>> portions of, provider nodes that are collectively represented to the

>> customer as a single node which is available in an overlay network.

>

> Works for me.

>

 

Great.  BTW I don't think 4847 precluded a single physical node being represented as multiple virtual nodes, but it doesn't hurt to make it explicit.

 

>> 

>>> 3. Virtual Topology: Virtual topology is a collection of one or more

>>> virtual or real provider network domain nodes that exist in the

>>> customer layer network and are interconnected via 0 or more virtual

>>> links.

>> 

>> How about:

>> Virtual Topology: A virtual topology is the collection of virtual

>> links and nodes advertised by a provider to a customer. The virtual

>> topology includes resources that are advertised as reachable within

>> an overlay network.

>> 

>> Do you mean to imply/allow for a VN which has no links?

>

> The case of "interconnected via 0 virtual links" implies the whole

> domain seen as a single node.

>

 

Ahh, fair enough.

 

>> 

>>> 4. Overlay topology:  is a superset of virtual topologies

>> provided by

>>> each of provider network domains, access and inter-domain links.

>>> 

>> 

>> Doesn't it also include any topology information advertised by the

>> customer/CE as well?

>

> Possibly. Do you mean advertised by the CE in the customer domain, right?

>

 

That's possible too, but I was thinking more of advertised by CE

(customer) to PE (provider).

 

>> 

>>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It

>>> can support any of the SCs supported by the GMPLS.

>>> 

>> 

>> If we adopt RFC 4847 terminology it should be "customer interface".

>> Also, I suspect you mean PE and CE.

>

> Mmm, yes but what if we want to manage it as a link? i.e. All

> TE-parameters that a link supports. Is it enough to call it interface

> only?

>

 

sure.  Per 4847, I'd say that "customer interface" is the connection between CE/PE while [virtual] TE links are what is advertised/represented in routing.

 

>> 

>>> 6. CE (customer Edge): Something like the CN in RFC4208

>> teminology but

>>> (i) receiving virtual topology from the provider network and

>>> requesting the set up of one of them or (ii) requesting the

>>> computation and establishment of a path accordingly to given

>>> constraints in the provider network and receiving the parameters

>>> characterizing such path. (ii) == UNI.

>>> 

>> 

>> humm, I'm inclined to stay away from UNI for the moment.  I also

>> suggest that we look to 4874 and even 4364 rather than 4208...

>

> Ok, we can refer to those RFC for what concerns terminology, but at

> the end of the day we must put the UNI under this framework. In the

> new terminology the UNI is a particular type of customer interface.

>

 

Fair enough.  But it is a form on an overlay "customer interface" not the definitive form.

 

>> 

>>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to

>>> deal with (i) and (ii) above.

>>> 

>> 

>> same comment WRT RFCs.

>> 

>>> 8. PE-CE interface (former ONI) : Interface allowing for

>> signaling and

>>> routing messages exchange between customer overlay and provider

>>> 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 CE to PE via signaling after the LSP

>> establishment

>>> in the core network or from CE to PE to be used as path computation

>>> constraints, fall under the definition of signaling info and not

>>> routing info).

>>> 

>> 

>> 

>>> 9. CE-CE (former O-NNI): Interface on the links between different

>>> provider networks in the overlay model environment. Same features of

>>> the CE-PE apply to this interface.

>>> 

>> 

>> you mean, PE-PE, right?

>

> You're not the first one that makes me notice i'm probably affected by

> dyslexia :-)

>

 

no problem, happens to the best of us!

 

>> 

>>> + Statements 1. In the context of overlay model we are aiming to

>>> build an overlay topology for the customer network domains

>>> 

>>>  2. The overlay topology is comprised of:

>>>     a) access links (links connecting client NEs to the

>> provider network domains).

>>>  They can be PSC or LSC.

>>>     b) inter-domain links (links interconnecting server

>> network domains)

>>>     c) virtual topology provided by the provider 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 CP instance for the

>> customer network

>>> and a separate instance for the provider network and in the CE-PE

>>> interface case the provider network also surreptitiously

>> participates

>>> in the customer network by injecting virtual topology

>> information into

>>> it.

>>> 

>> 

>> We should ensure we're allowing for some of the existing/augmented

>> models that permit the transport of overlay information within the

>> provider's CP, e.g., rfc4364, 5195 and 5252.

>

> I'd say they should be already covered, but will double check

>

 

great.

 

>> 

>>> 6. L1VPN (and LxVPN) in general is a type of service

>> provided over the

>>> CE-PE interface (it falls under the UNI case as no routing adjacency

>>> is in place between CE and PE).

>>> 

>>> 

>>> + Advertisement models (to be detailed in dedicated

>>> + document/documents)

>>> The CE-PE interface in the overlay model context foresees

>> two types of

>>> advertisement models.(names still to be agreed)

>>> 

>>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and

>> augmented by

>>> a number of actived draft (references to various drafts to

>> be added).

>>> The Augmented UNI is a particular type of CE-PE interface where only

>>> signaling messages are exchanged between CE and PE.

>>> Messages from CE to PE can include a set of parameters to be used by

>>> the PE as path computation constraints when computing a path in the

>>> provider domain network, while messages from PE to CE can include a

>>> set of parameters qualifying the LSP being established, like for

>>> example SRLG, delay, loss etc.

>>> 

>> 

>> again, we can leverage 4874 terminology if we so choose, i.e., "basic

>> mode" and "enhanced mode" UNI|NNI

>

> Don would be happy about that :-). I'd say yes. The goal was to cover

> the L1VPN work (enhanced mode),  all the drafts-ali recently polled

> for wg adoption (basic mode?) and the actual ENNI (enhanced mode).

 

> Is my mapping in brackets correct?

>

 

Not sure f I'd break it down they way you are.  I'd say basic mode is closer to the typical UNI and enhance mode is UNI+routing or perhaps even an ENNI.

 

>

>> 

>>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply

>>> called with the general CE-PE interface term?) allowing the

>>> establishment of signaling and routing adjacency between CE and PE.

>>> Routing info passed from PE to CE comprise overlay topology

>>> information including (but not limited to) virtual links,

>> connectivity

>>> matrices and access links with parameters qualifying each of them in

>>> terms of e.g. SRLG, loss, delay etc. Signaling information and

>>> procedures are compliant with RFC4208.

>>> 

>> 

>> so this is just and 4874 "enhanced mode" interface, right.

>

> Good question: the enhanced mode supports signaling and routing, so

> i'd say yes, but reading section 7.3 it talks about "limited exchange

> of information between the control planes.

>

>    "permits limited exchange of

>    information between the control planes of the provider and the

>    customer to help such functions as discovery of customer network

>    routing information (i.e., reachability or TE information in remote

>    customer sites), or parameters of the part of the provider's network

>    dedicated to the customer."

>

> Would you say this includes what we want? (i.e. Virtual links, virtual

> nodes, connectivity matrices, SRLG, delay, loss, etc) If yes we're

> done, otherwise an option could be the denition of a third VPN service

> model.

>

 

humm, need to think about this.  Perhaps the best thing is to document the two different cases and then decide if we have something new or

(two) more detailed forms of something old.

 

>> 

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

>>> 4. Virtual links: wouldn't a different definition of virtual links

>>> avoid the advertisement of connectivity matrices (this is out of the

>>> fwk scope but within the advertisement models one)?

>>> 

>> 

>>> Take this example:

>>> PE1-----CE1               CE2-----PE2

>>>         CE1======VL1======CE2

>>>         CE1======VL2======CE2

>> 

>> I think you've reversed CE and PE here...

>

> Yes, once again.

>

> No comment on my foolish proposal?

>

 

Which one?  I liked your summary overall.

 

Lou

 

>

>> 

>> Much thanks!

>> 

>> Lou

>> (hatless...)

>> 

>>> i.e. There are 2 VL connecting CE1 and CE2 that could be

>> available for

>>> PE1 and PE2 to set up an adjacency in the customer domain.

>> CE1 and/or

>>> CE2 can be blocking nodes so VL1 and/or VL2 are available only

>>> depending on the connectivity matrices of CE1 and CE2. Hence

>> PEs need

>>> to be aware of both VL and connectivity matrices. My point

>> is: if CE1

>>> advertises to PE1 only the VL that his connectivity matrix allows to

>>> be connected to PE1 (e.g. VL1 only) and not all of them, it

>> should be

>>> possible to avoid the connectivity matrices advertisement.

>>> 

>> 

>>> 

>>> ===================================

>>> DANIELE CECCARELLI

>>> System & Technology - PDU Optical & Metro

>>> 

>>> Via E.Melen, 77

>>> Genova, Italy

>>> Phone [phone]

>>> Mobile [phone]

>>> [e-mail]

>>> http://www.ericsson.com" rel="nofollow">www.ericsson.com

>>> 

>> 

>

>

>

_______________________________________________

CCAMP mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/ccamp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp

 

--

DIETER BELLER

ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: [phone]
Mobil: [phone]

[e-mail]

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub · Dr. Rainer Fechner · Andreas Gehe

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.