Re: [CCAMP] Overlay model framework v2

[Lou Berger <[e-mail]>]

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.

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".

>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.

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.

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

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

> 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.

> 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...

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

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

> 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

> 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.

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

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]
> www.ericsson.com  
>