Re: [CCAMP] Overlay model framework v2

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

Snipped..

>          ==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.
>   [[DC]] in this case why don't just advertising VL2 on AL1 and AL3 and
> VL1 on AL2 and AL4?
>
> Are you proposing the use of a new TE construct under the Link TLV to
advertise the constraints specific to a link (instead of using the
"Connectivity Matrix" which is a node-scope construct)?

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