Re: [CCAMP] Overlay model framework v2

[Vishnu Pavan Beeram <[e-mail]>]

Daniele,
Just realized that your previous response was directed to Igor :)

Ignore my last email..
-Pavan


On Thu, Jan 17, 2013 at 11:23 AM, Vishnu Pavan Beeram <[e-mail]
> wrote:

> Daniele, Hi!
>
>
> >> What you say is more than true but orthogonal to my point :-)
>
> I'm not sure what is orthogonal to your point.
> I was trying to make 2 points.
> - One was with respect to the "Virtual Topology" definition and I think we
> are more or less in sync with that.
> - The second point (example) was an attempt (guess I failed) to address
> your open-issue-4. I guess you would need to elaborate a bit more on that
> issue. I don't see how you can change the definition of the VL to avoid
> advertising the "connectivity constraints".
>
> Regards,
> -Pavan
>
>
>> 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
>>
>
>