Re: [CCAMP] Overlay model framework v2

[Gert Grammel <[e-mail]>]

Daniele,Igor,

The discussion shows that the term 'provider' is confusing.
Daniele seems to associate the 'provider' term to a service provider that doesn't want to export topology. However this is a policy decision and is not defining the overlay model.

The term 'provider' in the overlay model refers to a control plane entity that provides topology information to a 'client'.
Note that I dislike terms (Client, provider) that are associated to an organizational relationship rather than a technical boundary.
So what about naming it 'exported virtual topology'?
The term 'virtual' shall indicate that a virtual entity MAY not have a physical correspondence. So if any, I propose to skip the term provider and use 'server' instead.


Gert
________________________________________
From: [e-mail] on behalf of Daniele Ceccarelli
Sent: Thursday, January 17, 2013 6:19:39 PM
To: Igor Bryskin; Snigdho Bardalai; CCAMP
Subject: Re: [CCAMP] 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
>>>>
>>>
>>
>
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp