Re: [CCAMP] Overlay model framework v2

[Daniele Ceccarelli <[e-mail]>]

I like the "MAY" part.

I'd add it to the definition.

Daniele 

>-----Original Message-----
>From: Igor Bryskin [mailto:[e-mail]] 
>Sent: giovedì 17 gennaio 2013 19.34
>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP
>Subject: RE: Overlay model framework v2
>
>Daniele,
>
>You say a real link/node COULD be a part of a Virtual 
>Topology. (==> How a real WDM link or ROADM could be a part of 
>ODUk Virtual Topology?) I say a real link/node MAY be 
>represented in it's entirety  in a Virtual Topology by a 
>virtual link/node which has 1:1 cardinality with the said real 
>link/node.
>In other words the representation you are talking about 
>according to my definition is just one of a variety of ways 
>real links/nodes could be presented in a Virtual Topology. I 
>think you are unnecessarily overcomplicating the model  by 
>distinguishing this private case.
>
>Igor
>
>-----Original Message-----
>From: Daniele Ceccarelli [mailto:[e-mail]]
>Sent: Thursday, January 17, 2013 12:20 PM
>To: Igor Bryskin; Snigdho Bardalai; CCAMP
>Subject: RE: Overlay model framework v2
>
>I think a virtual link COULD be a real link and a virtual node 
>COULD be a real node.
>
>Agree that no provider wants to export the full topology, but 
>there might be cases in which it could be useful to summarise 
>a domain in E.G. X virtual nodes plus Y real nodes (where Y 
>could be very small by !=0). I just wanted to include this case also.
>
>Daniele 
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:[e-mail]]
>>Sent: giovedì 17 gennaio 2013 18.11
>>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP
>>Subject: RE: Overlay model framework v2
>>
>>The reason I like term "Virtual Topology" is simply because it is 
>>entirely made up of virtual elements: nodes and links. If you agree 
>>with me that provider does not disclose any of its real network 
>>topology information, I don't see why the terms "Exported Provider 
>>Topology" or "Summarized Provider Topology"
>>are better/less confusing.
>>
>>-----Original Message-----
>>From: Daniele Ceccarelli [mailto:[e-mail]]
>>Sent: Thursday, January 17, 2013 12:04 PM
>>To: Igor Bryskin; Snigdho Bardalai; CCAMP
>>Subject: RE: Overlay model framework v2
>>
>>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
>>>>>
>>>>
>>>
>>
>