Re: [CCAMP] Overlay model framework v2

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

Daniele, Hi!


> 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.
>

I (personally) don't see any confusion with using the term "Virtual
Topology" even if the topology includes VNs that represent fractions of a
real node. If there are still some strong reservations, I wouldn't want to
use the term "Provider Topology" as the alternative (look for other terms -
"Exported Provider Topology" (or) "Summarized Provider Topology" or
whatever).


>
> 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.
>
>
I think you have "CEs" and "PEs" mixed up in your example. If the notations
are interchanged, your example topology would look like the following:

                      ====VL1====
CE1-----PE1                         PE2-----CE2
                      ====VL2====

If you have just one access-link between each CE-PE pair, then it might be
ok for the PE node to advertise only the VL(s) that can be switched onto
from the single access-link (and hide all other VLs). But consider the case
where you have more than one access-link between each CE-PE pair as shown
below.

        ==AL1==         ====VL1====       ==AL3==
CE1                 PE1                          PE2               CE2
        ==AL2==         ====VL2====       ==AL4==

Say the connectivity constraints only allow the paths {AL1, VL2, AL3} and
{AL2, VL1,AL4} to be provisioned. For this particular exported provider
topology, advertising the "connectivity constraints" is a MUST.

But if the provider topology is exported to the client as shown below,
there wouldn't be a need to advertise the "connectivity constraints". Each
PE node is broken down into 2 Virtual entities.

        ==AL1==VN1====VL2====VN3==AL3==
CE1
 CE2
        ==AL2==VN2====VL1====VN4==AL4==

The manner in which the provider topology gets exported (operator choice)
to the client would determine what TE attributes get/don't get advertised.

Hope that helps,
-Pavan

>
> >-----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
>