Re: [CCAMP] Overlay model framework v2

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

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
>