Re: [CCAMP] Overlay model framework v2

[Snigdho Bardalai <[e-mail]>]

Agree with Daniele, there is no need to restrict the scope of the topology being exported or advertised by the provider. 

Regards
Snigdho

> -----Original Message-----
> From: Daniele Ceccarelli [mailto:[e-mail]]
> Sent: Thursday, January 17, 2013 9:20 AM
> 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
> >>>>
> >>>
> >>
> >