Re: [CCAMP] Overlay model framework v2

[Daniele Ceccarelli <[e-mail]>]

Does this mean: the topology passed from the PE to the CE? (hope this time i correctly used the acronims!!!) 

The new definition looks good to me if you're referring to the virtual links/nodes only, but doesn't consider real links/nodes any longer.

I prefer the old definition and call it as Pavan suggested: Exported Provider Topology" or "Summarized Provider Topology"

BR
Daniele

>-----Original Message-----
>From: Igor Bryskin [mailto:[e-mail]] 
>Sent: giovedì 17 gennaio 2013 17.23
>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP
>Subject: RE: Overlay model framework v2
>
>Daniele,
>
>What I was saying is that the definition:
>>  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.
>Is not correct. It should say IMO:
>3. Virtual Topology: Virtual topology is a collection of one 
>or more virtual nodes, supported by one or more provider 
>network domains, which exist in the  customer layer network 
>and are interconnected  via 0 or more virtual links, supported 
>by one or more provider network domains
>
>-----Original Message-----
>From: Daniele Ceccarelli [mailto:[e-mail]]
>Sent: Thursday, January 17, 2013 11:10 AM
>To: Igor Bryskin; Snigdho Bardalai; CCAMP
>Subject: RE: Overlay model framework v2
>
>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
>>>
>>
>