Subject: Re: [CCAMP] Overlay model framework v2

From: Gert Grammel <[email-masked]>
Date: Wed, 16 Jan 2013 20:14:51 +0000

Agree with Igor :-)

Gert
________________________________________
From: [email-masked] on behalf of Igor Bryskin
Sent: Wednesday, January 16, 2013 6:49:41 PM
To: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Daniel,
One correction:
VN may represent a fraction of a real node. This makes possible for the network to advertise a blocking PE as a set of non-blocking PE and thus alleviate the client path computer from dealing with blocking PEs.

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, January 16, 2013 10: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.
 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.
 4. Overlay topology:  is a superset of virtual topologies provided by each of  provider network domains, access and inter-domain links.
 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.

+ 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.
 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?
 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 +390106002512
Mobile +393346725750
[email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Gert Grammel <[email-masked]>
Date: Thu, 17 Jan 2013 17:38:03 +0000

Daniele,Igor,

The discussion shows that the term 'provider' is confusing.
Daniele seems to associate the 'provider' term to a service provider that doesn't want to export topology. However this is a policy decision and is not defining the overlay model.

The term 'provider' in the overlay model refers to a control plane entity that provides topology information to a 'client'.
Note that I dislike terms (Client, provider) that are associated to an organizational relationship rather than a technical boundary.
So what about naming it 'exported virtual topology'?
The term 'virtual' shall indicate that a virtual entity MAY not have a physical correspondence. So if any, I propose to skip the term provider and use 'server' instead.

Gert
________________________________________
From: [email-masked] on behalf of Daniele Ceccarelli
Sent: Thursday, January 17, 2013 6:19:39 PM
To: Igor Bryskin; Snigdho Bardalai; CCAMP
Subject: Re: [CCAMP] 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

>From: Igor Bryskin [mailto:[email-masked]]
>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.
>
>From: Daniele Ceccarelli [mailto:[email-masked]]
>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
>
>>From: Igor Bryskin [mailto:[email-masked]]
>>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
>>
>>From: Daniele Ceccarelli [mailto:[email-masked]]
>>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
>>
>>>From: Igor Bryskin [mailto:[email-masked]]
>>>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
>>>
>>>From: Daniele Ceccarelli [mailto:[email-masked]]
>>>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
>>>
>>>>From: Snigdho Bardalai [mailto:[email-masked]]
>>>>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
>>>>
>>>>> From: Igor Bryskin [mailto:[email-masked]]
>>>>> 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
>>>>>
>>>>>
>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>On Behalf
>>>>> Of Snigdho Bardalai
>>>>> Sent: Wednesday, January 16, 2013 5:48 PM
>>>>> Hi Daniele,
>>>>> A few comments. Please see in-line.
>>>>>
>>>>> Thanks
>>>>> Snigdho
>>>>>
>>>>> > From: [email-masked] [mailto:[email-masked]] On
>>>>> Behalf
>>>>> > Of Daniele Ceccarelli
>>>>> > Sent: Wednesday, January 16, 2013 7:33 AM
>>>>> > To: CCAMP
>>>>> > 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.
>>>>> >     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.
>>>>> >
>>>>> >
>>>>> > This Communication is Confidential. We only send and
>>>receive email
>>>>> > on the basis of the term set out at
>>>>> > www.ericsson.com/email_disclaimer
>>>>> >