Re: [CCAMP] Overlay model framework v2

[Snigdho Bardalai <[e-mail]>]

Hi Igor,

Not sure if the case you are citing qualifies a real node or link to be called virtual. The client space name is simply an alias.

Regards
Snigdho

> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: Wednesday, January 16, 2013 3:04 PM
> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP
> Subject: RE: Overlay model framework v2
> 
> Snigdho,
> 
> >  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.
> 
> [SCB] Since the topology advertised by the provider network can contain
> real or virtual elements, why do we call it "virtual topology"? Should
> it simply be called "provider topology"? And then specify that it may
> contain both virtual or real elements.
> 
> Virtual topology includes only virtual nodes. Even when we are
> considering real PEs terminating VLs, we must treat the PEs in the
> context of Virtual Topology as VNs since they must be named from the
> client naming space.
> 
> Igor
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Snigdho Bardalai
> Sent: Wednesday, January 16, 2013 5:48 PM
> To: Daniele Ceccarelli; CCAMP
> Subject: Re: [CCAMP] Overlay model framework v2
> 
> Hi Daniele,
> 
> A few comments. Please see in-line.
> 
> Thanks
> Snigdho
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of Daniele Ceccarelli
> > Sent: Wednesday, January 16, 2013 7:33 AM
> > To: CCAMP
> > Subject: [CCAMP] Overlay model framework v2
> >
> > 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.
> >  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.
> 
> [SCB] Agree with Igor's comment - a virtual node can be a combination
> of multiple nodes or a part of the single node, but to the customer
> node this is transparent.
> 
> >  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.
> 
> [SCB] Since the topology advertised by the provider network can contain
> real or virtual elements, why do we call it "virtual topology"? Should
> it simply be called "provider topology"? And then specify that it may
> contain both virtual or real elements.
> 
> >  4. Overlay topology:  is a superset of virtual topologies provided
> by
> > each of  provider network domains, access and inter-domain links.
> 
> [SCB] A more concise definition for the overlay topology is - CE nodes
> + Access-links + provider topology as advertised by the provider
> network.
> 
> >  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. 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.
> >  7. PE (provider Edge): Something like the EN in RFC4208 but able to
> > deal with (i) and (ii) above.
> >  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.
> 
> [SCB] Is this "PE-PE" instead of "CE-CE"?
> 
> >
> > + 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.
> 
> [SCB] Specific implementations may or may not have a single instance
> for the provider and the overlay.
> 
> >  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.
> > 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.
> >
> > + Open issues/questions
> >  1. PCE-PCEP - do we need to include considerations about PCE and
> PCEP
> > into the overlay framework context?
> 
> [SCB] IMO - this should be described in the overlay framework document
> to establish the 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.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
> >
> > 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