Re: [CCAMP] Overlay model framework v2

[Daniele Ceccarelli <[e-mail]>]

What you say is more than true but orthogonal to my point :-)

It's only a matter of terminology. We defined:

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

If we call it "Virtual Topology", the first thing that comes to the minds is: its only a collection of virtual links and virtual nodes.
Snigdho's proposal was to call it differently so to better identify the fact that it includes both virtual and real links/nodes, that's it.
The name he proposed, however, is again misleading, because calling it "provider topology" makes me (and you) thinking of just real links/nodes, doesn't it?

I would suggest not to use either of the terms as both are misleading. Maybe something like "exported topology", "CE-PE tology" or whatever.

Daniele 

>-----Original Message-----
>From: Igor Bryskin [mailto:[e-mail]] 
>Sent: giovedì 17 gennaio 2013 16.29
>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP
>Subject: RE: Overlay model framework v2
>
>Daniele,
>
>We want to separate a Virtual Topology advertised to the 
>clients (which is, generally speaking, different for different 
>sets of clients) from provider real topology, which must be 
>concealed from the clients.
>I disagree with Snigdho, when he is saying that a PE just has 
>multiple aliases (one from each client name space). There is 
>much more to this. The way I see it a PE contributes 
>differently to different Virtual Topologies (each time with a 
>different ID, sometimes as a whole, sometimes as split into 
>several VNs, sometimes as a part of a large VN, possibly with 
>a separate connectivity matrix. it also, depending on Virtual 
>Topology, presents itself as switch of a different layer 
>network, and so forth). Therefore, PE in the context of 
>Virtual Topology is always a Virtual Node, even when it is 
>mapped 1:1 onto real provider switch. In general, only VN can 
>terminate a VL.
>
>Igor
>
>-----Original Message-----
>From: Daniele Ceccarelli [mailto:[e-mail]]
>Sent: Thursday, January 17, 2013 9:53 AM
>To: Snigdho Bardalai; Igor Bryskin; CCAMP
>Subject: RE: Overlay model framework v2
>
>Igor, Snigdho,
>
>I agree with Snigdho. Why don't we call it provider topology 
>(or whatever) if it includes both virtual links/nodes and real 
>links/nodes? I don't think it has anything to deal with naming space.
>
>Further replies in line
>
>I'd like to have feedbacks from you and all on Open Issue 4. 
>That's an advertisement models draft issue but it's something 
>that i can't really understand yet.
>
>BR
>Daniele
>
>>-----Original Message-----
>>From: Snigdho Bardalai [mailto:[e-mail]]
>>Sent: giovedì 17 gennaio 2013 5.28
>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP
>>Subject: RE: Overlay model framework v2
>>
>>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.
>
>Yes, agree.
>
>>> 
>>> >  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.
>
>See above
>
>>> 
>>> >  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.
>
>We wanted to include also the possiblity of having multiple 
>provider domains.
>
>>> 
>>> >  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"?
>
>Oooops! Definitely.
>
>>> 
>>> >
>>> > + 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.
>
>Mmm, that's true. It MUST work with two different instances 
>but no one prevents it to work with a single one.
>
>>> 
>>> >  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.
>
>+1
>
>>> 
>>> >  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
>>
>