Subject: [CCAMP] Overlay model framework v2

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 16 Jan 2013 15:33:11 +0000

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

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 16 Jan 2013 17:49:41 +0000

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,

BR
Daniele

+ Disclaimer:

+ 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

Via E.Melen, 77
Genova, Italy
Phone +390106002512
Mobile +393346725750

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Dieter Beller <[email-masked]>
Date: Wed, 16 Jan 2013 23:21:20 +0100

Hi Igor,

On 16.01.2013 18:49, Igor Bryskin
wrote:

Daniel,
One correction:

why do you prefer to use the term Virtual Node for the non-blocking
sub-nodes that compose

a larger blocking node. Representing the sub-nodes in the
topological view is IMHO more the

representation of the real entities rather than virtual ones and
provides a white box view of that

node instead of a black box view.

Thanks,

Dieter

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,

BR
Daniele

+ Disclaimer:

+ Terminology:

+ Statements

+ Open issues/questions

Via E.Melen, 77
Genova, Italy
Phone +390106002512
Mobile +393346725750

--

DIETER
BELLER

ALCATEL-LUCENT
DEUTSCHLAND AG

PROJECT MANAGER ASON/GMPLS CONTROL PLANE

CORE NETWORKS BUSINESS DIVISION

OPTICS BU, SWITCHING R&D

Lorenzstrasse 10

70435 Stuttgart, Germany

Phone: +49 711 821 43125

Mobil: +49 175 7266874

[email-masked]

Alcatel-Lucent
Deutschland AG

Domicile of the Company: Stuttgart · Local Court Stuttgart HRB
4026

Chairman of the Supervisory Board: Michael Oppenhoff

Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg
Daub · Dr. Rainer Fechner · Andreas Gehe

This e-mail and its attachments, if any, may contain
confidential information.

If you have received this e-mail in error, please notify us and
delete or destroy the e-mail and its attachments, if any,
immediately.

If you have received this e-mail in error, you must not forward
or make use of the e-mail and its attachments, if any.

---

From: Snigdho Bardalai <[email-masked]>
Date: Wed, 16 Jan 2013 22:47:35 +0000

Hi Daniele,

A few comments. Please see in-line.

Thanks
Snigdho

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

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

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

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

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

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

>  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

[SCB] IMO - this should be described in the overlay framework document to establish the context.

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

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 16 Jan 2013 22:55:20 +0000

Dieter,

I like the term Virtual Node to distinguish it from the real provider network node. The Virtual Topology presented by the provider network to the clients is comprised of Virtual Nodes (interconnected via Virtual Links) because:

a)      The nodes/links exist in the client layer;

b)      The nodes/links are named from the client naming space
Whether a given VN represents multiple provider real nodes, exactly one real node, a fraction of one node or 5.75 nodes is immaterial.
Furthermore, VN associated with a non-blocking part of a blocking switch is a representation of the said non-blocking part in a Virtual Topology. Because Virtual Topologies are, generally speaking, different for different set of clients, the VNs representing the same non-blocking part of a real provider switch is also different in different Virtual Topologies.

Igor

From: Dieter Beller [mailto:[email-masked]]
Sent: Wednesday, January 16, 2013 5:21 PM
To: Igor Bryskin
Cc: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Hi Igor,
On 16.01.2013 18:49, Igor Bryskin wrote:

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.
why do you prefer to use the term Virtual Node for the non-blocking sub-nodes that compose
a larger blocking node. Representing the sub-nodes in the topological view is IMHO more the
representation of the real entities rather than virtual ones and provides a white box view of that
node instead of a black box view.

Thanks,
Dieter

Igor

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli

To: CCAMP

Dear overlayers,

BR

Daniele

+ Disclaimer:

+ Terminology:

+ Statements

 They can be PSC or LSC.

+ Open issues/questions

Take this example:

PE1-----CE1               CE2-----PE2

        CE1======VL1======CE2

        CE1======VL2======CE2

DANIELE CECCARELLI

Via E.Melen, 77

Genova, Italy

Phone +390106002512

Mobile +393346725750

[email-masked]<mailto:[email-masked]>

www.ericsson.com<http://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<http://www.ericsson.com/email_disclaimer>

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

--
DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874
[email-masked]<mailto:[email-masked]>

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub · Dr. Rainer Fechner · Andreas Gehe

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 16 Jan 2013 23:04:16 +0000

Snigdho,

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: [email-masked] [mailto:[email-masked]] 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,

Thanks
Snigdho

> comments around, sorry if anything is missing, in case just let me 
> know what i missed.
> 
> BR
> Daniele
> 
> 
> + Disclaimer:
> maintained/controlled in and by the provider  domain control plane 
> (and as such cannot transport any traffic/data and protected from 
> being
> 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.

> accordingly to given constraints  in the provider network and 
> receiving the parameters characterizing such path. (ii) == UNI.
>  8. PE-CE interface (former ONI) : Interface allowing for signaling 
> and routing messages  exchange between customer overlay and provider 

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

> 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

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 17 Jan 2013 04:28:13 +0000

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,
> 
> [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 Daniele Ceccarelli
> [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.
> 
> [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.
> 
> [SCB] A more concise definition for the overlay topology is - CE nodes
> + Access-links + provider topology as advertised by the provider
> network.
> 
> 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?
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Jan 2013 14:38:36 +0000

Ok, sounds good.

BR
Daniele 

>Sent: mercoledì 16 gennaio 2013 18.50
>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
>
>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  
> 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  
> 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
> 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:
>    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
> 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).
>
>
> 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?
> 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  
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Jan 2013 14:52:39 +0000

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
>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
>
>> >  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.
>> 
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>> Of Snigdho Bardalai
>> > 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:
>> >  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.

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

>> + Access-links + provider topology as advertised by the provider

We wanted to include also the possiblity of having multiple provider domains.

>teminology 
>> >  7. PE (provider Edge): Something like the EN in RFC4208 
>but able to 
>> > deal with (i) and (ii) above.
>signaling 
>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling 
>> > messages are compliant with  RFC4208. Information related to path 
>> > 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 
>> > provider networks  in the overlay model environment. Same features 
>> > of the CE-PE apply to this interface.
>> 

Oooops! Definitely.

>> > overlay topology for  the customer network domains  2. The overlay 
>> > topology
>> is
>> > comprised of:
>> > topologies  with overlay/underlay relationships  4. In the context 
>> > of overlay model multi-layering and inter-layer relationships  are 

Mmm, that's true. It MUST work with two different instances but no one prevents it to work with a single one.

>> >  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
>> [SCB] IMO - this should be described in the overlay 
>framework document 
>> to establish the context.

+1

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

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 17 Jan 2013 15:29:23 +0000

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:[email-masked]] 
Sent: Thursday, January 17, 2013 9:53 AM
To: Snigdho Bardalai; Igor Bryskin; CCAMP
Subject: RE: Overlay model framework v2

Igor, Snigdho,

Further replies in line

BR
Daniele

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

Yes, agree.

See above

Oooops! Definitely.

+1

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 17 Jan 2013 11:09:03 -0500

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Jan 2013 16:10:19 +0000

What you say is more than true but orthogonal to my point :-)

> the customer layer network and are interconnected  via 0 or more 

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 

>Sent: giovedì 17 gennaio 2013 16.29
>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP
>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
>
>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
>
>link to be 
>>> > virtual or real network  elements in a provider layer 
>network  that
>>> is
>>> >  4. Overlay topology:  is a superset of virtual 
>topologies provided
>>> by
>different 
>>> [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.
>
>>>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 17 Jan 2013 16:23:12 +0000

Daniele,

> customer layer network and are interconnected  via 0 or more virtual 
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:[email-masked]] 
Sent: Thursday, January 17, 2013 11:10 AM
To: Igor Bryskin; 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: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 17 Jan 2013 11:23:59 -0500

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

> 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: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 17 Jan 2013 11:30:51 -0500

Daniele,
Just realized that your previous response was directed to Igor :)

Ignore my last email..
-Pavan

On Thu, Jan 17, 2013 at 11:23 AM, Vishnu Pavan Beeram <[email-masked]

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Jan 2013 16:32:25 +0000

Hi Pavan,

please see in line

BR
Daniele

________________________________
From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: giovedì 17 gennaio 2013 17.09
To: Daniele Ceccarelli
Cc: Snigdho Bardalai; Igor Bryskin; CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Daniele, Hi!

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).
[[DC]] It has already caused misunderstanding, i would suggest to change and agree with you that "provider topology" is an unlucky term.

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:
[[DC]] It's the third time a mix them, i'm starting to think it's dyslexia
                      ====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.

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?
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.
[[DC]] agree, it works, but still don't see why it's more efficient than my proposal above.

CE1                                                                          CE2

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

>From: Snigdho Bardalai [mailto:[email-masked]<mailto:[email-masked]>]
>> From: Igor Bryskin [mailto:[email-masked]<mailto:[email-masked]>]
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
>On Behalf
>> Of Snigdho Bardalai
>> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>> Behalf
>> > Of Daniele Ceccarelli

Yes, agree.

See above

Oooops! Definitely.

+1

>> > Phone +390106002512<tel:%2B390106002512>
>> > Mobile +393346725750<tel:%2B393346725750>
>> > www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
>> >

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 17 Jan 2013 11:58:15 -0500

Snipped..

>  Say the connectivity constraints only allow the paths {AL1, VL2, AL3}
> and {AL2, VL1,AL4} to be provisioned. For this particular exported provider
> 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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Jan 2013 17:04:11 +0000

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

>Sent: giovedì 17 gennaio 2013 17.23
>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
>
>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 
>
>clients (which 
>multiple 
>>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
>>
>>That's an advertisement models draft issue but it's something that i 
>>can't really understand yet.
>>
>>BR
>>Daniele
>>
>>>> > network and is capable of terminating of access,  
>inter-domain and
>>>> virtual links.
>>>> 
>>>> > Virtual Links  + Virtual Nodes (TBD) + Connectivity 
>Matrix (with a
>>>> set
>>>> > peripheral at best, it is all about horizontal network 
>integration
>>>> 5.
>>>> > The overlay model assumes one CP instance for the 
>customer network
>>>> and
>available
>>>> for

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Jan 2013 17:07:46 +0000

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

Yes, or better, put it as an option on the table and see if it performs better than the existing one. 
If it does we can consider adding it, if it doesn't we've dropped it with a valid reason.

BR
Daniele

	From: Vishnu Pavan Beeram [mailto:[email-masked]] 
	Sent: giovedì 17 gennaio 2013 17.58
	To: Daniele Ceccarelli
	Cc: Snigdho Bardalai; Igor Bryskin; CCAMP
	Subject: Re: [CCAMP] Overlay model framework v2

	Snipped.. 

			

	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

				Yes, agree.

				See above

				Oooops! Definitely.

				+1

				>> > Phone +390106002512 <tel:%2B390106002512> 
				>> > Mobile +393346725750 <tel:%2B393346725750>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 17 Jan 2013 17:11:19 +0000

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:[email-masked]] 
Sent: Thursday, January 17, 2013 12:04 PM
To: Igor Bryskin; Snigdho Bardalai; CCAMP
Subject: RE: Overlay model framework v2

BR
Daniele

>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
>
>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.
>"provider topology" makes me (and you) thinking of just real 
>links/nodes, doesn't it?
>
>>>> >  2. BGP-LS needs to be considered  3. Should potentials be 
>>>> > included? E.g. I2RS?

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 17 Jan 2013 17:19:39 +0000

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 

>Sent: giovedì 17 gennaio 2013 18.11
>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.
>
>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
>
>identify the 
>calling it 
>misleading. 
>>>>> >     a) access links (links connecting client NEs to the 
>provider 
>>>>> > network domains).
>>>>> >  They can be PSC or LSC.

---

From: Snigdho Bardalai <[email-masked]>
Date: Thu, 17 Jan 2013 17:24:55 +0000

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

Regards
Snigdho

> Sent: Thursday, January 17, 2013 9:20 AM
> 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
> 
> >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"
> >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.
> >

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 17 Jan 2013 18:33:31 +0000

Daniele,

You say a real link/node COULD be a part of a Virtual Topology. (==> How a real WDM link or ROADM could be a part of ODUk Virtual Topology?)
I say a real link/node MAY be represented in it's entirety  in a Virtual Topology by a virtual link/node which has 1:1 cardinality with the said real link/node.
In other words the representation you are talking about according to my definition is just one of a variety of ways real links/nodes could be presented in a Virtual Topology. I think you are unnecessarily overcomplicating the model  by distinguishing this private case.

Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Thursday, January 17, 2013 12:20 PM
To: Igor Bryskin; Snigdho Bardalai; CCAMP
Subject: RE: Overlay model framework v2

Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 18 Jan 2013 14:37:07 +0000

I like the "MAY" part.

I'd add it to the definition.

Daniele 

>Sent: giovedì 17 gennaio 2013 19.34
>You say a real link/node COULD be a part of a Virtual 
>Topology. (==> How a real WDM link or ROADM could be a part of 
>ODUk Virtual Topology?) I say a real link/node MAY be 
>represented in it's entirety  in a Virtual Topology by a 
>virtual link/node which has 1:1 cardinality with the said real 
>link/node.
>In other words the representation you are talking about 
>according to my definition is just one of a variety of ways 
>real links/nodes could be presented in a Virtual Topology. I 
>think you are unnecessarily overcomplicating the model  by 
>distinguishing this private case.
>
>Igor
>
>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 
>
>via 0 or 
>>>>We wanted to include also the possiblity of having multiple 
>provider 
>>>>domains.
>>>>
>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Jan 2013 12:27:08 -0500

Daniele,
	Very nice summary.  Just catching up, so sorry for the (2 day)
late response.

I really like how the terminology has evolved and appreciate the
summary!

I have a few detail comments, but before I go there I'd like to cover
one more open issue that I think will have some (minor) ripple effects
on the details.

I think there's still the general issue of terminology to use when
referring to the entity that "uses an overlay" and the entity that
"instantiates the overlay".  In your mail and in discussion we have:

- client (service)/OC/CN/customer

and

- server(or service)/OE/EN/provider

I think we had discussed, and possibly agreed on, using VPN
terminology which would have us use the latter options, i.e.,
(overlay) customer/provider (edge).  This would mean eliminating
any references to client/server in the *generic overlay*
definitions.  Of course these terms may reemerge in other contexts
as they have before, e.g., rfc6215.

I like this approach as it is aligned with the much of IETF
work on overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN
(e.g. RFC 4847).  Importantly, RFC 4847 even has quite a few
concepts that can be directly leveraged in this discussion.

I'd even go further and say that we should base the definitions
and resulting framework on RFC 4847.  For example, the definitions
below could start with something along the lines:

    The overlay service model, at a high level, follows Section
    7. of RFC 4847 as represented by:

                        +--------------------+
                  :     |                    |     :
                  :     |                    |     :
         +----+   :   +----+              +----+   :   +----+
         | CE |---:---| PE |              | PE |---:---| CE |
         +----+   :   +----+              +----+   :   +----+
                  :     |                    |     :
                  :     |                    |     :
                  :     +--------------------+     :
                  :     |                    |     :
                  :     |<-Provider network->|     :
             Customer                           Customer
             interface                          interface

                  Figure 7.2: Overlay Service Model

    In this model, the overlay is instantiated by an overlay
    "provider" and its provider edge (PE) nodes , and is used by
    the overlay "customer" which is connected to the provider via
    customer interfaces attached to customer edge (CE) nodes.

    ...

The definition below would need to be tweaked slightly, notably to
remove any references to client and server.  The resulting framework can
also refer back to RFC 4847 as needed.

See below for some additional comments.

On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote:
> being de-provisioned) and which can be instantiated in the data plane

You say "potential path".  I this this should read  "potential or
instantiated path".

>From my perspective, I think a node in the overlay really shouldn't
*directly* distinguish between the two -- now one may have a different
metric/SRLG/weight/etc, but these are abstracted representations of the
tradeoffs between use of the two, that can be provided by the underlying
provider network, rather than a direct indication.

> network and is capable of terminating of access, inter-domain and

I'm a little uncomfortable with the linkage of real nodes to virtual
nodes.  I think VN is a purely abstract concept that may be instantiated
using parts/whole/multiple/logical/real/etc nodes.

How about something like:
Virtual Node: A virtual node is a representation of a collection of
provider resources that are interconnected via virtual (and customer)
links.  A virtual node may be collection of zero or more, including
portions of, provider nodes that are collectively represented to
the customer as a single node which is available in an overlay network.

> customer layer network and are interconnected via 0 or more virtual

How about:
Virtual Topology: A virtual topology is the collection of virtual links
and nodes advertised by a provider to a customer. The virtual topology
includes resources that are advertised as reachable within an overlay
network.

Do you mean to imply/allow for a VN which has no links?

> each of provider network domains, access and inter-domain links.

Doesn't it also include any topology information advertised by the
customer/CE as well?

> can support any of the SCs supported by the GMPLS.

If we adopt RFC 4847 terminology it should be "customer interface".
Also, I suspect you mean PE and CE.

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

humm, I'm inclined to stay away from UNI for the moment.  I also suggest
that we look to 4874 and even 4364 rather than 4208...

> deal with (i) and (ii) above.

same comment WRT RFCs.

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

> the CE-PE apply to this interface.

you mean, PE-PE, right?

> + Statements 1. In the context of overlay model we are aiming to
> build an overlay topology for the customer network domains
> 
> + 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.
> 
> 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
>

We should ensure we're allowing for some of the existing/augmented
models that permit the transport of overlay information within the
provider's CP, e.g., rfc4364, 5195 and 5252.

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

again, we can leverage 4874 terminology if we so choose, i.e., "basic
mode" and "enhanced mode" UNI|NNI

> each of them in terms of e.g. SRLG, loss, delay etc. Signaling
> information and procedures are compliant with RFC4208.
> 

so this is just and 4874 "enhanced mode" interface, right.

>         CE1======VL2======CE2

I think you've reversed CE and PE here...

Much thanks!

Lou
(hatless...)

> 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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 21 Jan 2013 14:41:14 +0000

Hi Lou,

Please find comments in line

BR
Daniele 

>From: Lou Berger [mailto:[email-masked]] 
>Sent: venerdì 18 gennaio 2013 18.27
>To: Daniele Ceccarelli
>Cc: CCAMP
>	Very nice summary.  Just catching up, so sorry for the 
>(2 day) late response.
>
>I really like how the terminology has evolved and appreciate 
>the summary!
>
>I have a few detail comments, but before I go there I'd like 
>to cover one more open issue that I think will have some 
>(minor) ripple effects on the details.
>
>I think there's still the general issue of terminology to use 
>when referring to the entity that "uses an overlay" and the 
>entity that "instantiates the overlay".  In your mail and in 
>discussion we have:
>
>(overlay) customer/provider (edge).  This would mean 
>eliminating any references to client/server in the *generic 
>overlay* definitions.  Of course these terms may reemerge in 
>other contexts as they have before, e.g., rfc6215.

Yes, i think we all agreed. If there are still terms different from customer/provider in the text it's because i missed them during the replacing.

>I'd even go further and say that we should base the 
>definitions and resulting framework on RFC 4847.  For example, 
>the definitions below could start with something along the lines:
>
>The definition below would need to be tweaked slightly, 
>notably to remove any references to client and server.  The 
>resulting framework can also refer back to RFC 4847 as needed.
>
>You say "potential path".  I this this should read  "potential 
>or instantiated path".
>

Maybe we need to define also what "potential" stands for? At least two cases come to my mind (which might be included under the "potential" umbrella):

1. resources reserved via signaling but not instantiated
2. resources not even signaled. In presence of a centralized entity managing the network (sort of PCE plus something) there is no need to reserve resources via signaling as the central entity is the only thing that can reserve or allocate resources. I'm thinking to an opening towards the integration with the SDN world.

Just loud thinking, does it make sense?

>*directly* distinguish between the two -- now one may have a 
>different metric/SRLG/weight/etc, but these are abstracted 
>representations of the tradeoffs between use of the two, that 
>can be provided by the underlying provider network, rather 
>than a direct indication.
>
>I'm a little uncomfortable with the linkage of real nodes to 
>virtual nodes.  I think VN is a purely abstract concept that 
>may be instantiated using parts/whole/multiple/logical/real/etc nodes.

Makes sense. What this definition adds to the one in RFC4847 is basically the fact that also parts of a node can be considered. What saying that it can be a real node i meant 1:1 correspondance between a real and a virtual node. Your definition covers that case also, that's fine.

>Virtual Node: A virtual node is a representation of a 
>collection of provider resources that are interconnected via 
>virtual (and customer) links.  A virtual node may be 
>collection of zero or more, including portions of, provider 
>nodes that are collectively represented to the customer as a 
>single node which is available in an overlay network.

Works for me.

>Virtual Topology: A virtual topology is the collection of 
>virtual links and nodes advertised by a provider to a 
>customer. The virtual topology includes resources that are 
>advertised as reachable within an overlay network.
>

The case of "interconnected via 0 virtual links" implies the whole domain seen as a single node.

>provided by 
>Doesn't it also include any topology information advertised by 
>the customer/CE as well?

Possibly. Do you mean advertised by the CE in the customer domain, right?

>Also, I suspect you mean PE and CE.

Mmm, yes but what if we want to manage it as a link? i.e. All TE-parameters that a link supports. Is it enough to call it interface only? 

>teminology but 
>> (i) receiving virtual topology from the provider network and 
>humm, I'm inclined to stay away from UNI for the moment.  I 
>also suggest that we look to 4874 and even 4364 rather than 4208...

Ok, we can refer to those RFC for what concerns terminology, but at the end of the day we must put the UNI under this framework. In the new terminology the UNI is a particular type of customer interface.

>signaling and 
>interface 
>> it is equivalent to the GMPLS UNI defined in 4208.
>> path carachteristics, e.g. TE-metrics, collected SRLG, path 
>delay etc, 
>establishment 

You're not the first one that makes me notice i'm probably affected by dyslexia :-)

>provider network domains).
>>  They can be PSC or LSC.
>> Virtual Links
>We should ensure we're allowing for some of the 
>existing/augmented models that permit the transport of overlay 
>information within the provider's CP, e.g., rfc4364, 5195 and 5252.

I'd say they should be already covered, but will double check

>> advertisement models.(names still to be agreed)
>> 
>> signaling messages are exchanged between CE and PE.
>again, we can leverage 4874 terminology if we so choose, i.e., 
>"basic mode" and "enhanced mode" UNI|NNI

Don would be happy about that :-). I'd say yes. The goal was to cover the L1VPN work (enhanced mode),  all the drafts-ali recently polled for wg adoption (basic mode?) and the actual ENNI (enhanced mode). Is my mapping in brackets correct?

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

Good question: the enhanced mode supports signaling and routing, so i'd say yes, but reading section 7.3 it talks about "limited exchange of information between the control planes.

   "permits limited exchange of
   information between the control planes of the provider and the
   customer to help such functions as discovery of customer network
   routing information (i.e., reachability or TE information in remote
   customer sites), or parameters of the part of the provider's network
   dedicated to the customer."

Would you say this includes what we want? (i.e. Virtual links, virtual nodes, connectivity matrices, SRLG, delay, loss, etc)
If yes we're done, otherwise an option could be the denition of a third VPN service model.

>I think you've reversed CE and PE here...

Yes, once again.

No comment on my foolish proposal?

>available for

---

From: Lou Berger <[email-masked]>
Date: Mon, 21 Jan 2013 17:12:43 -0500

Thanks Daniele, See below.

On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote:
> Yes, i think we all agreed. If there are still terms different from
> customer/provider in the text it's because i missed them during the
> replacing.
> 

Great!  Glad I didn't miss something over the holidays!

> Maybe we need to define also what "potential" stands for? At least
> two cases come to my mind (which might be included under the
> "potential" umbrella):
> 

Sure.  Sounds like a RFC6001 soft FA.

> 2. resources not even signaled. In presence of a centralized entity
> managing the network (sort of PCE plus something) there is no need to
> reserve resources via signaling as the central entity is the only
> thing that can reserve or allocate resources. I'm thinking to an
> opening towards the integration with the SDN world.
> 

Sure.  Sounds like a Virtual TE link (per RFC6001, 5212).

> Makes sense. What this definition adds to the one in RFC4847 is
> basically the fact that also parts of a node can be considered. What
> saying that it can be a real node i meant 1:1 correspondance between
> a real and a virtual node. Your definition covers that case also,
> that's fine.
> 
>>

Great.  BTW I don't think 4847 precluded a single physical node being
represented as multiple virtual nodes, but it doesn't hurt to make it
explicit.

> domain seen as a single node.

Ahh, fair enough.

> Possibly. Do you mean advertised by the CE in the customer domain, right?

That's possible too, but I was thinking more of advertised by CE
(customer) to PE (provider).

> Mmm, yes but what if we want to manage it as a link? i.e. All
> TE-parameters that a link supports. Is it enough to call it interface
> only?
> 

sure.  Per 4847, I'd say that "customer interface" is the connection
between CE/PE while [virtual] TE links are what is
advertised/represented in routing.

> Ok, we can refer to those RFC for what concerns terminology, but at
> the end of the day we must put the UNI under this framework. In the
> new terminology the UNI is a particular type of customer interface.
> 

Fair enough.  But it is a form on an overlay "customer interface" not
the definitive form.

> You're not the first one that makes me notice i'm probably affected

no problem, happens to the best of us!

> I'd say they should be already covered, but will double check

great.

> Don would be happy about that :-). I'd say yes. The goal was to cover
> the L1VPN work (enhanced mode),  all the drafts-ali recently polled
> for wg adoption (basic mode?) and the actual ENNI (enhanced mode). 

> Is my mapping in brackets correct?
> 

Not sure f I'd break it down they way you are.  I'd say basic mode is
closer to the typical UNI and enhance mode is UNI+routing or perhaps
even an ENNI.

> Good question: the enhanced mode supports signaling and routing, so
> i'd say yes, but reading section 7.3 it talks about "limited exchange
> of information between the control planes.
> 
> Would you say this includes what we want? (i.e. Virtual links,
> virtual nodes, connectivity matrices, SRLG, delay, loss, etc) If yes
> we're done, otherwise an option could be the denition of a third VPN
> service model.
> 

humm, need to think about this.  Perhaps the best thing is to document
the two different cases and then decide if we have something new or
(two) more detailed forms of something old.

> No comment on my foolish proposal?

Which one?  I liked your summary overall.

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 22 Jan 2013 15:05:24 +0000

Lou and Daniele,
Please, see my comments in-line,

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Monday, January 21, 2013 5:13 PM
To: Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote:
>> one more open issue that I think will have some
>> (overlay) customer/provider (edge).  This would mean eliminating any 
>> references to client/server in the *generic
>> overlay* definitions.  Of course these terms may reemerge in other 
>> contexts as they have before, e.g., rfc6215.
> 

IB>> I personally have no problems with the VPN terminology. However, IMO the terminology should be aligned with the RFC 4208 and George's drafts. One cannot use different terminology within the same framework, right? Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. The most important goal is to provide a solution for inter-domain horizontal integration between networks with possibly different switching technologies and independent addressing within the overlay model. 

>>
>> I like this approach as it is aligned with the much of IETF work on 
>> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847).  
>> Importantly, RFC 4847 even has quite a few concepts that can be 
>> directly leveraged in this discussion.
>>
>> I'd even go further and say that we should base the definitions and 
>> resulting framework on RFC 4847.  For example, the definitions below 
>> could start with something along the lines:
>>
>> remove any references to client and server.  The resulting framework 
>> can also refer back to RFC 4847 as needed.
>>
> Maybe we need to define also what "potential" stands for? At least two 
> cases come to my mind (which might be included under the "potential" 
> umbrella):
> 

IB>> Potential path can be defined as a feasible/provisionable  path for the server layer trail supporting an advertised VL, which has attributes consistent with the ones advertised for the Virtual Link (noticeably, bandwidth, SRLGs, etc.) and is guaranteed to be available at the moment of the set-up of a client LSP that has selected the VL in its path across the provider domain.

>>representations of the tradeoffs between use of the two, that  can be 
>>provided by the underlying provider network, rather  than a direct 
>>indication.

IB>> It is beneficial from the client (ONT user) path computation point of view to know whether the advertised VL is committed (the data plane is provisioned) or not. Selecting uncommitted VL means:
a) Higher probability of a client LSP setup failure;
b) Longer client LSP setup time;
c) Probability of effectively removing other VLs from the ONT (those that share MELGs with the VL in question)

>> nodes.  I think VN is a purely abstract concept that may be 
>> instantiated using parts/whole/multiple/logical/real/etc nodes.
> 

IB>> Agree completely

> saying that it can be a real node i meant 1:1 correspondance between a 
> real and a virtual node. Your definition covers that case also, that's 
> fine.
> 
>>
>> portions of, provider nodes that are collectively represented to the 
>> customer as a single node which is available in an overlay network.
> 
> Works for me.
> 

Great.  BTW I don't think 4847 precluded a single physical node being represented as multiple virtual nodes, but it doesn't hurt to make it explicit.

>> Virtual Topology: A virtual topology is the collection of virtual 
>> links and nodes advertised by a provider to a customer. The virtual 
>> topology includes resources that are advertised as reachable within 
>> an overlay network.
>>

Ahh, fair enough.

>> Doesn't it also include any topology information advertised by the 

IB>> Yes, it does: the ends of access links terminated by the clients along with the custom NEs IDs

> TE-parameters that a link supports. Is it enough to call it interface 

sure.  Per 4847, I'd say that "customer interface" is the connection between CE/PE while [virtual] TE links are what is advertised/represented in routing.

>> humm, I'm inclined to stay away from UNI for the moment.  I also 
>> suggest that we look to 4874 and even 4364 rather than 4208...
> 

Fair enough.  But it is a form on an overlay "customer interface" not the definitive form.

>>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of 
>>> + parameters

great.

> Is my mapping in brackets correct?

Not sure f I'd break it down they way you are.  I'd say basic mode is closer to the typical UNI and enhance mode is UNI+routing or perhaps even an ENNI.

> Would you say this includes what we want? (i.e. Virtual links, virtual 
> nodes, connectivity matrices, SRLG, delay, loss, etc) If yes we're 
> done, otherwise an option could be the denition of a third VPN service 
> model.
> 

humm, need to think about this.  Perhaps the best thing is to document the two different cases and then decide if we have something new or
(two) more detailed forms of something old.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Jan 2013 10:50:44 -0500

Igor,

see below.

On 1/22/2013 10:05 AM, Igor Bryskin wrote:
> IB>> I personally have no problems with the VPN terminology. However,
> IMO the terminology should be aligned with the RFC 4208 and George's
> drafts.

My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped
to encompass the broad spectrum of overlays that are/have been discussed.

> One cannot use different terminology within the same
> framework, right? 

Unfortunately we have no shortage of terminology defining (perhaps
different flavors) of the same thing!

> Furthermore, both RFC4208 and ONTs are not
> necessarily about VPNs.

While I certainly agree that not all overlays need be VPNs, it seems to
me that our discussions are best aligned with that set of terminology,
and that UNI/ENNI can be described within the CE/PE/VN/VL/VT constructs.
Perhaps with some tweaking in some cases.

> The most important goal is to provide a
> solution for inter-domain horizontal integration between networks
> with possibly different switching technologies and independent
> addressing within the overlay model.
> 

Sure.  It's also possible that an overlay will use the same switching
technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably
less likely) the same address space (if a provider so chooses).

> Sure.  Sounds like a Virtual TE link (per RFC6001, 5212).
IB>> Potential path can be defined as a feasible/provisionable  path for
the server layer trail supporting an advertised VL, which has attributes
consistent with the ones advertised for the Virtual Link (noticeably,
bandwidth, SRLGs, etc.) and is guaranteed to be available at the moment
of the set-up of a client LSP that has selected the VL in its path
across the provider domain.
>>> provided by the underlying provider network, rather  than a direct 
IB>> It is beneficial from the client (ONT user) path computation point
IB>> of view to know whether the advertised VL is committed (the data
> c) Probability of effectively removing other VLs from the ONT (those that share MELGs with the VL in question)

And I'm suggesting that this be advertised using generic constructs such
as TE metric, SRLG, and even MELG, rather than adding yet another
special case computation/optimization parameter.

> IB>> Yes, it does: the ends of access links terminated by the clients along with the custom NEs IDs

sounds like some agreement here.

I think that was you final comment...

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 22 Jan 2013 16:09:31 +0000

Hi Lou,

You said:
And I'm suggesting that this be advertised using generic constructs such as TE metric, SRLG, and even MELG, rather than adding yet another special case computation/optimization parameter.

Agree, we are already doing this via MELG sub-TLV. This is because the sub-TLV is new (no need to change the existing ones) and because MELG is peculiar to VL.

Igor.

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2013 10:51 AM
To: Igor Bryskin
Cc: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Igor,

see below.

On 1/22/2013 10:05 AM, Igor Bryskin wrote:
>>> I have a few detail comments, but before I go there I'd like to 
>>> cover one more open issue that I think will have some

My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped to encompass the broad spectrum of overlays that are/have been discussed.

> One cannot use different terminology within the same framework, right?

Unfortunately we have no shortage of terminology defining (perhaps different flavors) of the same thing!

> Furthermore, both RFC4208 and ONTs are not necessarily about VPNs.

While I certainly agree that not all overlays need be VPNs, it seems to me that our discussions are best aligned with that set of terminology, and that UNI/ENNI can be described within the CE/PE/VN/VL/VT constructs.
Perhaps with some tweaking in some cases.

> The most important goal is to provide a solution for inter-domain 
> horizontal integration between networks with possibly different 
> switching technologies and independent addressing within the overlay 
> model.
> 

Sure.  It's also possible that an overlay will use the same switching technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably less likely) the same address space (if a provider so chooses).

>> two cases come to my mind (which might be included under the "potential"
>> umbrella):
>>
IB>> Potential path can be defined as a feasible/provisionable  path for
the server layer trail supporting an advertised VL, which has attributes consistent with the ones advertised for the Virtual Link (noticeably, bandwidth, SRLGs, etc.) and is guaranteed to be available at the moment of the set-up of a client LSP that has selected the VL in its path across the provider domain.
>>> representations of the tradeoffs between use of the two, that  can 
>>> be provided by the underlying provider network, rather  than a 
>>> direct indication.
> 
IB>> It is beneficial from the client (ONT user) path computation point 
IB>> of view to know whether the advertised VL is committed (the data 
IB>> plane is provisioned) or not. Selecting uncommitted VL means:
> c) Probability of effectively removing other VLs from the ONT (those 
> that share MELGs with the VL in question)

And I'm suggesting that this be advertised using generic constructs such as TE metric, SRLG, and even MELG, rather than adding yet another special case computation/optimization parameter.

>>> provider resources that are interconnected via virtual (and 
>>> customer) links.  A virtual node may be  collection of zero or more, 
>>> including portions of, provider nodes that are collectively 
>>> represented to the customer as a single node which is available in an overlay network.
>>
>> Works for me.
>>
> 
> IB>> Yes, it does: the ends of access links terminated by the clients 
> IB>> along with the custom NEs IDs
> 

Lou

>>>> e.g. SRLG, optical impairments, delay etc for each entry) 
>>>> describing connectivity between access links and virtual links.
>>>>
>>>> CE-PE interface (it falls under the UNI case as no routing 
>>>> 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, 
>>>> matrices and access links with parameters qualifying each of them 
>>>> in terms of e.g. SRLG, loss, delay etc. Signaling information and 
>>>> 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
>>>
>>>> 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

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Jan 2013 11:20:40 -0500

Igor,
	I was referring to you comment:

IB>> It is beneficial from the client (ONT user) path computation point
IB>> of view to know whether the advertised VL is committed (the data
IB>> plane is provisioned) or not.

So my point is that the U bit should be represented via an increased
metric (or some other existing parameter) as this is what path
computation is going to do in effect in any case.

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 22 Jan 2013 16:41:38 +0000

Lou,
Generally it is not a good idea to play with the TE metric. 
It is up to client path computer (or client policy) to decide how important the difference between  a committed and uncommitted VL, and hence to define the TE metric penalty.
Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2013 11:21 AM
To: Igor Bryskin
Cc: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Igor,

So my point is that the U bit should be represented via an increased metric (or some other existing parameter) as this is what path computation is going to do in effect in any case.

Lou

On 1/22/2013 11:09 AM, Igor Bryskin wrote:
>> Behalf Of Lou Berger
>>>> any references to client/server in the *generic
>>>> resulting framework on RFC 4847.  For example, the definitions 
>>>> remove any references to client and server.  The resulting 
>>>> framework can also refer back to RFC 4847 as needed.
>>>>
>>> managing the network (sort of PCE plus something) there is no need 
>>> to reserve resources via signaling as the central entity is the only 
> IB>> Potential path can be defined as a feasible/provisionable  path 
> IB>> for
> IB>> It is beneficial from the client (ONT user) path computation 
> IB>> point of view to know whether the advertised VL is committed (the 
> IB>> data plane is provisioned) or not. Selecting uncommitted VL means:
>>>> virtual nodes.  I think VN is a purely abstract concept that may be 
>>>> customer) links.  A virtual node may be  collection of zero or 
>>>> more, including portions of, provider nodes that are collectively 
>>>>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. 
>>>>> It can support any of the SCs supported by the GMPLS.
>>>>>
>>>>
>>> TE-parameters that a link supports. Is it enough to call it 
>>> interface only?
>>>
>>
>>>>> 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).
>>>>>
>>>>
>>>>
>>>>> overlay topologies with overlay/underlay relationships
>>>>>
>>> Don would be happy about that :-). I'd say yes. The goal was to 
>>> cover the L1VPN work (enhanced mode),  all the drafts-ali recently 
>>> polled for wg adoption (basic mode?) and the actual ENNI (enhanced mode).
>>
>>> i'd say yes, but reading section 7.3 it talks about "limited 
>>> exchange of information between the control planes.
>>>
>> humm, need to think about this.  Perhaps the best thing is to 
>> document the two different cases and then decide if we have something 
>> new or

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Jan 2013 11:51:11 -0500

>From my perspective, at a high-level the discussion is really about how
best to revise/update MLN(MRN) to align with current (and desired) usage.

Lou

On 1/22/2013 11:38 AM, John E Drake wrote:
> Lou,
> 
> Snipped.  I think this discussion is pointing out that we may be having charter creep in the sense that we are starting to impinge upon the work of the L3/L2 VPN and MPLS WGs.
> 
> I am also having a hard time remembering what problem we are trying to solve.  We have been through enhancements to the overlay model, the GMPLS ENNI, and enhancements to virtual links, as well as one or two I have probably forgotten.
> 
> Irrespectively Yours,
> 
> John
> 
>> Sent: Tuesday, January 22, 2013 7:51 AM
>> To: Igor Bryskin
>> Cc: CCAMP
>>> Of Lou Berger
>> any

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 22 Jan 2013 17:07:14 +0000

I was about to commend you on having stopped referring to MLN/MRN. I was wrong and I agree with John that we are basically quite lost in this discussion and may be should drop it precisely to not produce another framework as useful as MLN/MRN.

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2013 11:51 AM
To: John E Drake
Cc: Igor Bryskin; CCAMP; Stewart Bryant; [email-masked]; 'George Swallow (swallow)'
Subject: Re: [CCAMP] Overlay model framework v2

>From my perspective, at a high-level the discussion is really about how best to revise/update MLN(MRN) to align with current (and desired) usage.

Lou

On 1/22/2013 11:38 AM, John E Drake wrote:
>>> IB>> I personally have no problems with the VPN terminology. 
>>> IB>> However,
>> My issue with 4208 is that UNI (and ENNI) are just too narrowly 
>> scoped to encompass the broad spectrum of overlays that are/have been 
>> discussed.
>>
>> While I certainly agree that not all overlays need be VPNs, it seems 
>> to me that our discussions are best aligned with that set of 
>> terminology, and that UNI/ENNI can be described within the 
>> CE/PE/VN/VL/VT constructs.
>> technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but 
>> probably less likely) the same address space (if a provider so chooses).
>>
> 
> 
> 
> 
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Jan 2013 12:31:09 -0500

Igor,

Sorry to disappoint. I still see a relationship whether we reuse the 
terminology or not. I suspect that I am not alone in this.

Lou

On January 22, 2013 12:07:14 PM Igor Bryskin <[email-masked]> wrote:
> I was about to commend you on having stopped referring to MLN/MRN. I 
> was wrong and I agree with John that we are basically quite lost in 
> this discussion and may be should drop it precisely to not produce 
> another framework as useful as MLN/MRN.
>
> Igor
>
> > Snipped.  I think this discussion is pointing out that we may be 
> having charter creep in the sense that we are starting to impinge upon 
> the work of the L3/L2 VPN and MPLS WGs.
> >
> > I am also having a hard time remembering what problem we are trying 
> to solve.  We have been through enhancements to the overlay model, the 
> GMPLS ENNI, and enhancements to virtual links, as well as one or two I 
> have probably forgotten.
> >
> > Irrespectively Yours,
> >
> > John
> >

---

From: John E Drake <[email-masked]>
Date: Tue, 22 Jan 2013 16:38:57 +0000

Lou,

Irrespectively Yours,

John

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 22 Jan 2013 18:58:42 +0000

Lou,

At my home we have a rule: if something is not being used for one year, it is pronounced  trash that is unlikely to be ever used, which is just taking space of something better and more contemporary and hence must be thrown away.  So I suggest implementing the same or similar rule in our CCAMP home:  let's make an inventory of existing CCAMP RFCs and throw away those that have never seen any interoperability tests and were never part of any product or solution.

Besides, I believe nothing (terminology, architecture,  protocol solutions, etc.)  of MLN/MRN is relevant to what we are/were trying to achieve with ONTs. 

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2013 12:31 PM
To: Igor Bryskin; John E Drake
Cc: CCAMP; Stewart Bryant; [email-masked]; 'George Swallow (swallow)'
Subject: RE: [CCAMP] Overlay model framework v2

Igor,

Sorry to disappoint. I still see a relationship whether we reuse the terminology or not. I suspect that I am not alone in this.

Lou

On January 22, 2013 12:07:14 PM Igor Bryskin <[email-masked]> wrote:
> From my perspective, at a high-level the discussion is really about 
> how best to revise/update MLN(MRN) to align with current (and desired) usage.
>
> Lou
>
> >>>>> discussion we
> >> have:
> >>>> Yes, i think we all agreed. If there are still terms different 
> >>>> from customer/provider in the text it's because i missed them 
> >>>> during the replacing.
> >>>>
> >>>
> >>> IMO the terminology should be aligned with the RFC 4208 and 
> >>> George's drafts.
> >>
> >> scoped to encompass the broad spectrum of overlays that are/have 
> >> been discussed.
> >>
> >> While I certainly agree that not all overlays need be VPNs, it 
> >> seems to me that our discussions are best aligned with that set of 
> >>> switching technologies and independent addressing within the 
> >>> overlay model.
> >>>
> >>
> >> Sure.  It's also possible that an overlay will use the same 
> >> switching technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even 
> >> (but probably less likely) the same address space (if a provider so chooses).
> >>
> >
> >
> >
> >
> >
>

---

From: Gert Grammel <[email-masked]>
Date: Tue, 22 Jan 2013 22:33:55 +0000

Hi Lou, Daniele,

Thanks for summarizing, seems we are converging. Related to terminology I still think that 'customer' and 'provider' give the wrong connotation for overlay networks. While a VPN can be seen as a service, hence both terms might have some justification, a Overlay-UNI/ENNI does not. It's simply a name for a control interface that can be used internally in a network without necessarily providing a customer with any new service. Having to choose between 'Customer-Provider' or 'Client-Server' terminology , the latter fits much better to what we call Overlay.

To move on with terminology we may want to preserve the abbreviations by adding 'overlay':

1.       Overlay-Provider-edge (OPE) - at least it provides a topology to the client

2.       Overlay-Client-edge (OCE) - Note there is no customer here, it's a client

About Virtual topology 3):

·         real-nodes vs. virtual nodes: from a OCE perspective there shall be no difference. In other words there shall be no difference between an OPE Network exposing virtual nodes and an equivalent OPE network where each virtual node is replaced by a real node of equal characteristic.

I would support the connotation of a UNI, an augmented UNI and an O(verlay)NNI (or OCE-OPE interface):

1.       UNI: signaling only, no topology information exchanged (targeted for a customer/provider interface where Client=customer)

2.       Augmented-UNI: signaling only, with post-provisioned topology information of LSPs

3.       ONNI: signaling and routing , where routing injects topology information independent of LSPs

Best

Gert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Montag, 21. Januar 2013 23:13
To: Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

>>> reflecting the latest discussions. Again i hope i've

>> captured all the

>>> virtual or real network elements in a provider layer network

>> that is

>>> maintained/controlled in and by the provider domain control

>> plane (and

>>> provider network domain nodes that are collectively

>> represented to the

>>> clients as a single node that exists in the customer layer

>> network and

> The case of "interconnected via 0 virtual links" implies the whole

> domain seen as a single node.

Ahh, fair enough.

>>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to

>>> Signaling messages are compliant with RFC4208. Information

>> related to

> You're not the first one that makes me notice i'm probably affected by

> dyslexia :-)

>>>     b) inter-domain links (links interconnecting server

>> network domains)

>>> 5. The overlay model assumes one CP instance for the

>>> interface case the provider network also surreptitiously

>> participates

>>> in the customer network by injecting virtual topology

>> information into

great.

>>> 6. L1VPN (and LxVPN) in general is a type of service

>> provided over the

>>> The CE-PE interface in the overlay model context foresees

>> two types of

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

>> and PCEP

Lou

>>> PE1 and PE2 to set up an adjacency in the customer domain.

>> CE1 and/or

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

>>> be connected to PE1 (e.g. VL1 only) and not all of them, it

CCAMP mailing list

---

From: Gert Grammel <[email-masked]>
Date: Tue, 22 Jan 2013 23:03:55 +0000

Lou,

playing with TE metric is indeed not the best idea. However representing the server U-bit in a client domain admin color might be interesting. (sorry for still using the old acronyms)

Gert  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Dienstag, 22. Januar 2013 17:42
To: Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Lou,

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, January 22, 2013 11:21 AM
To: Igor Bryskin
Cc: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Igor,

Lou

---

From: Snigdho Bardalai <[email-masked]>
Date: Tue, 22 Jan 2013 23:05:36 +0000

Hi Gert,

Sorry, but I have to disagree with your statement (BTW - are we going in circles - I thought we had already beaten this topic to death :)). It is possible to have client-server relationships totally contained within a customer or provider network and not visible across the CE-PE or PE-PE interface. That is the reason why we need to keep client/server and customer/provider boundaries completely independent of each other.

Thanks
Snigdho

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: Tuesday, January 22, 2013 2:34 PM
To: Lou Berger; Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Hi Lou, Daniele,

Best

Gert

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Montag, 21. Januar 2013 23:13
To: Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Ahh, fair enough.

great.

Lou

CCAMP mailing list

---

From: Gert Grammel <[email-masked]>
Date: Tue, 22 Jan 2013 23:51:29 +0000

Snigdho,

Not sure why you disagree, it rather seems we are saying the same thing. Client/server is *not* customer/provider. That's why I am struggling to accept the notion of 'Customer-Edge' and 'Provider-Edge' for a relationship that has nothing to do with customers. As a consequence VPN wording (=customer/provider) as proposed by Lou has not the right semantic for an overlay network. Yet by just making such statements, we are no inch closer to an acceptable terminology. If you are not happy with client-Edge and provider-edge feel free to propose other terms. Eventually we have to come to a conclusion.

Best

Gert

From: Snigdho Bardalai [mailto:[email-masked]]
Sent: Mittwoch, 23. Januar 2013 00:06
To: Gert Grammel; Lou Berger; Daniele Ceccarelli
Cc: CCAMP
Subject: RE: [CCAMP] Overlay model framework v2

Hi Gert,

Thanks
Snigdho

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: Tuesday, January 22, 2013 2:34 PM
To: Lou Berger; Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Hi Lou, Daniele,

Best

Gert

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Montag, 21. Januar 2013 23:13
To: Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Ahh, fair enough.

great.

Lou

CCAMP mailing list

---

From: Dieter Beller <[email-masked]>
Date: Wed, 23 Jan 2013 10:43:17 +0100

Hi Gert, Snigdho, all,

I agree with the statement that:

"we need to keep
client/server and customer/provider boundaries completely
independent of each other"

At least the "customer-edge/provider-edge" terminology originally
defined for VPNs does reflect

the fact that this is a horizontal interface as opposed
to client/server in the multi-layer context.

Thanks,

Dieter

On 23.01.2013 00:51, Gert Grammel wrote:

Snigdho,

Not
sure why you disagree, it rather seems we are saying the
same thing. Client/server is *not* customer/provider.
That’s why I am struggling to accept the notion of
‘Customer-Edge’ and ‘Provider-Edge’ for a relationship that
has nothing to do with customers. As a consequence VPN
wording (=customer/provider) as proposed by Lou has not the
right semantic for an overlay network. Yet by just making
such statements, we are no inch closer to an acceptable
terminology. If you are not happy with client-Edge and
provider-edge feel free to propose other terms. Eventually
we have to come to a conclusion.

Best

Gert

From: Snigdho Bardalai
[mailto:[email-masked]]

Cc: CCAMP

Hi
Gert,

Sorry,
but I have to disagree with your statement (BTW - are we
going in circles – I thought we had already beaten this
topic to death
☺). It is possible to have
client-server relationships totally contained within a
customer or provider network and not visible across the
CE-PE or PE-PE interface. That is the reason why we need to
keep client/server and customer/provider boundaries
completely independent of each other.

Thanks

Snigdho

From:
[email-masked]
[mailto:[email-masked]]
On Behalf Of Gert Grammel

Cc: CCAMP

Hi Lou, Daniele,

Thanks for
summarizing, seems we are converging. Related to
terminology I still think that 'customer' and 'provider'
give the wrong connotation for overlay networks. While a
VPN can be seen as a service, hence both terms might have
some justification, a Overlay-UNI/ENNI does not. It's
simply a name for a control interface that can be used
internally in a network without necessarily providing a
customer with any new service. Having to choose between
‘Customer-Provider’ or ‘Client-Server’ terminology , the
latter fits much better to what we call Overlay.

To move on with
terminology we may want to preserve the abbreviations by
adding 'overlay':

1.
Overlay-Provider-edge
(OPE) – at least it provides a topology to the client

2.
Overlay-Client-edge
(OCE) - Note there is no customer here, it’s a client

About Virtual
topology 3):

•
real-nodes
vs. virtual nodes: from a OCE perspective there shall be
no difference. In other words there shall be no difference
between an OPE Network exposing virtual nodes and an
equivalent OPE network where each virtual node is replaced
by a real node of equal characteristic.

I would support the
connotation of a UNI, an augmented UNI and an O(verlay)NNI
(or OCE-OPE interface):

1.
UNI:
signaling only, no topology information exchanged
(targeted for a customer/provider interface where
Client=customer)

2.
Augmented-UNI:
signaling only, with post-provisioned topology information
of LSPs

3.
ONNI:
signaling and routing , where routing injects topology
information independent of LSPs

Best

Gert

-----Original
Message-----

From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Lou Berger

To: Daniele Ceccarelli

Cc: CCAMP

On 1/21/2013 9:41 AM, Daniele

>> I really like how the
terminology has evolved and appreciate the

Great!  Glad I didn't miss something
over the holidays!

>> overlays (e.g., BGP L3/L2
VPNs) as well as the L1VPN (e.g. RFC 4847).

+--------------------+

>>                  :
|                    |     :

>>                  :

>>                  :
|                    |     :

>>                  :

>>                  :

Customer                           Customer

interface

>>    "provider" and its
provider edge (PE) nodes , and is used by

>> remove any references to
client and server.  The resulting framework

>>> 1. Packet opto
integration is often considered but the work can be

>>> 1. Virtual Link: A
virtual link is a potential path between two

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

Sure.  Sounds like a Virtual TE link
(per RFC6001, 5212).

>>different
metric/SRLG/weight/etc, but these are abstracted

>>representations of the
tradeoffs between use of the two, that  can be

>>> is capable of terminating
of access, inter-domain and virtual links.

>> I'm a little uncomfortable
with the linkage of real nodes to virtual

>> instantiated using
parts/whole/multiple/logical/real/etc nodes.

>> provider resources that are
interconnected via virtual (and customer)

>> customer as a single node
which is available in an overlay network.

Great.  BTW I don't think 4847
precluded a single physical node being represented as
multiple virtual nodes, but it doesn't hurt to make it
explicit.

>>> 3. Virtual Topology:
Virtual topology is a collection of one or more

>>> customer layer network
and are interconnected via 0 or more virtual

Ahh, fair enough.

That's possible too, but I was
thinking more of advertised by CE

>>> 5. Access Link: Link
between OC and OE. GMPLS runs on that link. It

>> If we adopt RFC 4847
terminology it should be "customer interface".

> TE-parameters that a link
supports. Is it enough to call it interface

sure.  Per 4847, I'd say that
"customer interface" is the connection between CE/PE while
[virtual] TE links are what is advertised/represented in
routing.

>>> computation and
establishment of a path accordingly to given

>>> constraints in the
provider network and receiving the parameters

Fair enough.  But it is a form on an
overlay "customer interface" not the definitive form.

>>> 7. PE (provider Edge):
Something like the EN in RFC4208 but able to

>>> in the core network or
from CE to PE to be used as path computation

>>> provider networks in the
overlay model environment. Same features of

>>> + Statements 1. In the
context of overlay model we are aiming to

>>>     c) virtual topology
provided by the provider network domains.

>>> e.g. SRLG, optical
impairments, delay etc for each entry) describing

>>> 3. In the context of
overlay model we manage  hierarchy  of overlay

>>> 4. In the context of
overlay model multi-layering and inter-layer

>>> relationships are
peripheral at best, it is all about horizontal

>>> and a separate instance
for the provider network and in the CE-PE

>> We should ensure we're
allowing for some of the existing/augmented

>> models that permit the
transport of overlay information within the

great.

>>> CE-PE interface (it falls
under the UNI case as no routing adjacency

>>> The Augmented UNI is a
particular type of CE-PE interface where only

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

>> again, we can leverage 4874
terminology if we so choose, i.e., "basic

Not sure f I'd break it down they way
you are.  I'd say basic mode is closer to the typical UNI
and enhance mode is UNI+routing or perhaps even an ENNI.

>>> establishment of
signaling and routing adjacency between CE and PE.

>>> matrices and access links
with parameters qualifying each of them in

>    customer to help such
functions as discovery of customer network

humm, need to think about this.
Perhaps the best thing is to document the two different
cases and then decide if we have something new or

(two) more detailed forms of something
old.

>>> 4. Virtual links:
wouldn't a different definition of virtual links

>>> avoid the advertisement
of connectivity matrices (this is out of the

>>> PE1-----CE1
CE2-----PE2

CE1======VL1======CE2

CE1======VL2======CE2

Which one?  I liked your summary
overall.

Lou

>>> depending on the
connectivity matrices of CE1 and CE2. Hence

>>> advertises to PE1 only
the VL that his connectivity matrix allows to

CCAMP mailing list

[email-masked]

--

DIETER
BELLER

ALCATEL-LUCENT
DEUTSCHLAND AG

OPTICS BU, SWITCHING R&D

Lorenzstrasse 10

70435 Stuttgart, Germany

Phone: +49 711 821 43125

Mobil: +49 175 7266874

Alcatel-Lucent
Deutschland AG

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Jan 2013 10:11:03 -0500

Gert,
	Sure.  (As I mentioned) reuse of existing *generic* parameters would be
preferable to adding a new, and very use case specific, one.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Jan 2013 10:22:12 -0500

On 1/22/2013 1:58 PM, Igor Bryskin wrote:
>...
> Besides, I believe nothing (terminology, architecture,  protocol
> solutions, etc.)  of MLN/MRN is relevant to what we are/were trying
> to achieve with ONTs.
> 
> Igor
> ...

Igor,

Can we take a step back for a moment from the (seemingly endless)
terminology/architecture/framework debate?

What additional (i.e., not already covered in a standalone draft, e.g.,
draft-ali-...) *protocol extensions* do you think need to be
standardized (as PS)?

Is it more than just MELG?

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 23 Jan 2013 15:26:48 +0000

Gert,

Changing color every time when a VL becomes committed/uncommitted is as bad as changing VL's TE metric. Besides, you have only 32 colors for the entire domain (scarce resource). Furthermore, colors are used as constraints, while here you need actually a conscious (well understood and selected by a client path computer) penalty for using an uncommitted VL for the path selection optimization. Finally, this is a particularity of a Virtual Link that has never been addresses before (even in the MLN/MRN documents!) and hence requires a dedicated piece of advertisement.

Igor

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2013 6:04 PM
To: Igor Bryskin; Lou Berger
Cc: CCAMP
Subject: RE: [CCAMP] Overlay model framework v2

Lou,

Gert  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Dienstag, 22. Januar 2013 17:42
To: Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Lou,

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, January 22, 2013 11:21 AM
To: Igor Bryskin
Cc: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Igor,

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 23 Jan 2013 16:42:40 +0000

Lou,

Required protocol extensions (just to start with):
1. MELGs +VL's committed/uncommitted status advertising
2. Signaling extensions to set correctly client device RSVP timers and to communicate the state and status of underlying server trail (e.g. taking into account delays due to the server trail setup). Issue of RROs: a client device signals the LSP path in terms of VLs/VNs, what about RROs?;
3. ONT  OAM extensions and procedures (how to associate DP alarms/failures happened on real links and nodes with VLs and VNs that depend on them, so that client LSP restoration could be controlled by the client?);
4. VN related extensions (do we need to advertise TE RTR TLV on behalf of a VN, what are the procedures if several real nodes constitute VN, what is the signaling address to use if a VN is selected, etc.);
5. VN connectivity matrix for addressing VN's blocking/asymmetric nature, including the detailed connectivity matrix (entries with associated costs, which will also require signaling extensions: e.g. how to specify in the ERO that a given connectivity matrix entry is selected?);
6. Routing extensions to separate VN's internals from the outside world;
7. Access/inter-domain links LMP extensions;
8. Split-VN specific extensions ( when a blocking real node is presented via several symmetrical VNs, the VN IDs could be assigned and changed  automatically (to remove extra configuration burden), how the client NEs learn that the remote node ID of an access link is (re-)assigned?)
9. Routing extensions to address independent address spaces;
10. VPN related extensions: how to advertise VL's association with one or several VPNs? How to provide VPN-specific VN's connectivity matrix;
11. Etc.

All of the above mentioned things obviously cannot be done without a well-understood framework with, yes, tightly defined definitions.
Hence the definitions is a very important start.

Cheers,
Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2013 10:22 AM
To: Igor Bryskin
Cc: John E Drake; CCAMP; Stewart Bryant; [email-masked]; 'George Swallow (swallow)'
Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP] Overlay model framework v2)

On 1/22/2013 1:58 PM, Igor Bryskin wrote:
>solutions, etc.)  of MLN/MRN is relevant to what we are/were trying  to 
>achieve with ONTs.
> 
> Igor
> ...

Igor,

Can we take a step back for a moment from the (seemingly endless) terminology/architecture/framework debate?

What additional (i.e., not already covered in a standalone draft, e.g.,
draft-ali-...) *protocol extensions* do you think need to be standardized (as PS)?

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Jan 2013 12:47:39 -0500

Igor,

See below for responses in line.

> 1. MELGs +VL's committed/uncommitted status advertising

Understood, although you and I may not agree on some of the details, 
but that discussion can wait.

> 2. Signaling extensions to set correctly client device RSVP timers and 
> to communicate the state and status of underlying server trail (e.g. 
> taking into account delays due to the server trail setup).

Isn't this possible with any H-LSP), I.e. not unique to ONTs (or 
whatever you call it)?

> Issue of RROs: a client device signals the LSP path in terms of 
> VLs/VNs, what about RROs?;

How is this a new problem? The issue is present/covered in 4208.

> 3. ONT  OAM extensions and procedures (how to associate DP 
> alarms/failures happened on real links and nodes with VLs and VNs that 
> depend on them, so that client LSP restoration could be controlled by 
> the client?);

This too seems like a generic problem, I.e., one present in H-LSPs, 
L1VPNs, and MLN.

> 4. VN related extensions (do we need to advertise TE RTR TLV on behalf 
> of a VN, what are the procedures if several real nodes constitute VN, 
> what is the signaling address to use if a VN is selected, etc.);

My understanding of existing RFCs (and discussion) is that virtual 
nodes/links are advertised just like real nodes/links.  This sounds 
like an informational, or at most a BCP, document.

> 5. VN connectivity matrix for addressing VN's blocking/asymmetric 
> nature, including the detailed connectivity matrix (entries with 
> associated costs, which will also require signaling extensions: e.g. 
> how to specify in the ERO that a given connectivity matrix entry is selected?);

What as a VN connectivity matrix? Does it differ from the connectivity 
matrix already defined by this group?

If yes, it sounds like an extension to the existing work.

If no, sounds like another informational/BCP.

> 6. Routing extensions to separate VN's internals from the outside world;

Sounds like information exchanged between overlay edge nodes (PEs).  
Basically the  information that would be needed to support L1VPN enhanced mode.

> 7. Access/inter-domain links LMP extensions;

Isn't this the same as is needed when using rfc5251 or 4208?

> 8. Split-VN specific extensions ( when a blocking real node is 
> presented via several symmetrical VNs, the VN IDs could be assigned and 
> changed  automatically (to remove extra configuration burden), how the 
> client NEs learn that the remote node ID of an access link is (re-)assigned?)

This is a specific example of item 6 above, right?

> 9. Routing extensions to address independent address spaces;

Part of this is already covered by L1VPN basic mode, and the rest is 
also required by L1VPN enhanced mode.

> 10. VPN related extensions: how to advertise VL's association with one 
> or several VPNs? How to provide VPN-specific VN's connectivity matrix;

I think you already covered this above.

> 11. Etc.
>
> All of the above mentioned things obviously cannot be done without a 
> well-understood framework with, yes, tightly defined definitions.

Wow that's a long list!

It seems  to me that a number/most of the items above, can be done as 
focused and incremental extensions to  existing RFCs/WG products, in a 
generic way, without any further discussion/agreement on the high level 
overlay topic. Just like the other (soon to be) new WG documents.

Certainly the informational/BCP documents would require good 
understanding of the target use cases.  Given the clear, and seemingly 
circular, disagreements on basic terminology it might make most sense 
to spend some time documenting the different use cases/models before 
continuing the definitions discussion.

Lou (as contributor)

---

From: Snigdho Bardalai <[email-masked]>
Date: Wed, 23 Jan 2013 19:03:17 +0000

There is one use-case I don't see being mentioned - signaling LSPs that are diverse in the provider network and do not have common CE nodes as head-end or tail-end.

I believe this will require some extensions, not sure what yet!!

Regards
Snigdho

> Sent: Wednesday, January 23, 2013 9:48 AM
> To: Igor Bryskin
> Cc: CCAMP
> Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re:
> Overlay model framework v2)
> 
> Igor,
> 
> > presented via several symmetrical VNs, the VN IDs could be assigned
> > and changed  automatically (to remove extra configuration burden),
> how
> > the client NEs learn that the remote node ID of an access link is
> > (re-)assigned?)
>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 23 Jan 2013 19:54:13 +0000

Please, see in line.
Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2013 12:48 PM
To: Igor Bryskin
Cc: John E Drake; CCAMP; Stewart Bryant; [email-masked]; 'George Swallow (swallow)'
Subject: RE: Additional overlay protocol extensions? (Was: Re: [CCAMP] Overlay model framework v2)

Igor,

> 1. MELGs +VL's committed/uncommitted status advertising

Understood, although you and I may not agree on some of the details, but that discussion can wait.
IB>>Ok

> taking into account delays due to the server trail setup).

Isn't this possible with any H-LSP), I.e. not unique to ONTs (or whatever you call it)?
IB>> Is this covered? Where? We (ADVA, JNPR) had an issue with that and could not find the answer.

How is this a new problem? The issue is present/covered in 4208.
IB>> 4208 does not have a notion of VL or VN, so it cannot possibly cover it. When ERO is signaled in terms of VLs, how does RRO returned to the client should look like: virtual links? real links? both? encrypted with some key?

> depend on them, so that client LSP restoration could be controlled by 

This too seems like a generic problem, I.e., one present in H-LSPs, L1VPNs, and MLN.
IB>> Where is exactly described how the faults are associated with VLs and VNs? When, say, a fault happens inside a VN, how exactly outside world knows about that to perform an alternative path computation? Please, provide a quote.

> what is the signaling address to use if a VN is selected, etc.);

My understanding of existing RFCs (and discussion) is that virtual nodes/links are advertised just like real nodes/links.  This sounds like an informational, or at most a BCP, document.

IB>> Disagree. If a VN is comprised of two real nodes handled by separate OSPF speakers, which of them (or both) generate TE RTR TLV on behalf of VN? My solution, for example, is to deprecate completely TE RTR TLV, because it is redundant. In any case, if you know where the issue is covered, please, provide the quote.

> how to specify in the ERO that a given connectivity matrix entry is 

What as a VN connectivity matrix? Does it differ from the connectivity matrix already defined by this group?
IB>> Yes, it does: the detailed VN connectivity matrix should include a set of costs (in terms of SRLGs, delay, TE matric, etc.) for cross-connecting two interfaces, similar to what Giovanni suggests for OI (optical impairments) vector. The consequence is that there could be more than one entry for the same pair of interfaces, with a consequence of the necessity of signaling extensions. Also, which of the speakers should advertise the connectivity matrix? I have the solution for that which is quite different from the way it is " already defined by this group"

Sounds like information exchanged between overlay edge nodes (PEs).  
Basically the  information that would be needed to support L1VPN enhanced mode.
IB>> The point of VN as a powerful scalability tool is to present a network to the outside of the world as a single node (i.e. to hide internals) while still exposing in some way an IP connectivity to each of the internal nodes for the management purposes. Considering that VNs can encompass domains made of VNs,  I see this as a big challenge with big benefits if solved. If you know where this issue is covered, please, provide a quote.

Isn't this the same as is needed when using rfc5251 or 4208?
IB>> Access/inter-domain links can be terminated by VNs, so, no, this is not covered

> and changed  automatically (to remove extra configuration burden), how 

This is a specific example of item 6 above, right?
IB>> No. Normally VN requires quite a bit of manual configuration. This is the case when this could be fully automated.

> 9. Routing extensions to address independent address spaces;

Part of this is already covered by L1VPN basic mode, and the rest is also required by L1VPN enhanced mode.
IB>> I am talking about routing extensions for virtual topology which is not part of L1VPN basic mode.
If this covered for  L1VPN enhanced mode, please, provide the quote as to how this could be handled using OSPF.

I think you already covered this above.
IB>> No, I didn't. I don't know yet how to advertise association of a VL with one or multiple VPNs, nor how to advertise VPN specific connectivity matrices, nor how to filter the information from the users of different VPNs

Wow that's a long list!

It seems  to me that a number/most of the items above, can be done as focused and incremental extensions to  existing RFCs/WG products, in a generic way, without any further discussion/agreement on the high level overlay topic. Just like the other (soon to be) new WG documents.

Certainly the informational/BCP documents would require good understanding of the target use cases.  Given the clear, and seemingly circular, disagreements on basic terminology it might make most sense to spend some time documenting the different use cases/models before continuing the definitions discussion.

IB>> Lou, as you see I disagreed with pretty much everything you said. The way I see it, one huge reason why we keep going in circles is you and your desire to make it look like CCAMP work has a continuity of developing new things based on existing RFCs. I am not against continuity when it calls for. This work was not started because CCAMP WG has initiated it. Let me remind you that the work has started because we (ADVA and JNPR) have a product that as we believe could be developed into a wider framework. It was always meant to be built up as a continuation of RFC4208. I personally have full respect for this work as well as for what George is doing to enhance it. What I have problem with is some CCAMP dead stuff such as MLN/MRN and your contra-productive attempts to make it look bigger than it is actually worth of. I also couldn't help but notice that the discussions proceed quite well until you wake up with your comments, so could you wake up a bit less frequently?:=)

Igor (as contributor)

Lou (as contributor)

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Jan 2013 17:24:52 -0500

It seems I failed to make my perspective clear to you in my previous
mail. While this may or may not be the case, I believe your mail has
moved outside acceptable IETF conduct.

Lou

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 23 Jan 2013 22:42:02 +0000

Agree - please keep the discussion technically focused and avoid any personal comments.

Deborah
(with CCAMP Co-Chair hat on)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, January 23, 2013 5:25 PM
To: Igor Bryskin
Cc: CCAMP
Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2)

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 23 Jan 2013 22:55:00 +0000

Lou,

What in your opinion would be an acceptable way to say that you have not taken time to understand what a group of people within CCAMP WG is trying to accomplish and because of that has wasted 1 year of people's time by guiding the discussion in circles  from UNI to ENNI to MLN/MRN to L1VPN to L3VPN to MLN/MRN again ?

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2013 5:25 PM
To: Igor Bryskin
Cc: John E Drake; CCAMP; Stewart Bryant; [email-masked]; 'George Swallow (swallow)'
Subject: Re: Additional overlay protocol extensions? (Was: Re: [CCAMP] Overlay model framework v2)

It seems I failed to make my perspective clear to you in my previous mail. While this may or may not be the case, I believe your mail has moved outside acceptable IETF conduct.

Lou

On 1/23/2013 2:54 PM, Igor Bryskin wrote:
>> 2. Signaling extensions to set correctly client device RSVP timers 
>> and to communicate the state and status of underlying server trail (e.g.
>> alarms/failures happened on real links and nodes with VLs and VNs 
>> that depend on them, so that client LSP restoration could be 
>> controlled by the client?);
> 
>> 4. VN related extensions (do we need to advertise TE RTR TLV on 
>> behalf of a VN, what are the procedures if several real nodes 
>> constitute VN, what is the signaling address to use if a VN is 
>> selected, etc.);
> 
> IB>> Access/inter-domain links can be terminated by VNs, so, no, this 
> IB>> is not covered
> 
>> how the client NEs learn that the remote node ID of an access link is
>> (re-)assigned?)
> 
>> 10. VPN related extensions: how to advertise VL's association with 
>> one or several VPNs? How to provide VPN-specific VN's connectivity 
>> matrix;
> 
> IB>> No, I didn't. I don't know yet how to advertise association of a 
> IB>> VL with one or multiple VPNs, nor how to advertise VPN specific 
> IB>> connectivity matrices, nor how to filter the information from the 
> IB>> users of different VPNs
> 
>> 11. Etc.
>>
> IB>> Lou, as you see I disagreed with pretty much everything you said. 
> IB>> The way I see it, one huge reason why we keep going in circles is 
> IB>> you and your desire to make it look like CCAMP work has a 
> IB>> continuity of developing new things based on existing RFCs. I am 
> IB>> not against continuity when it calls for. This work was not 
> IB>> started because CCAMP WG has initiated it. Let me remind you that 
> IB>> the work has started because we (ADVA and JNPR) have a product 
> IB>> that as we believe could be developed into a wider framework. It 
> IB>> was always meant to be built up as a continuation of RFC4208. I 
> IB>> personally have full respect for this work as well as for what 
> IB>> George is doing to enhance it. What I have problem with is some 
> IB>> CCAMP dead stuff such as MLN/MRN and your contra-productive 
> IB>> attempts to make it look bigger than it is actually worth of. I 
> IB>> also couldn't help but notice that the discussions proceed quite 
> IB>> well until you wake up with your comments, so could you wake up a 
> IB>> bit less frequently?:=)
> 
> Igor (as contributor)
> 
> Lou (as contributor)
> 
>> Cheers,
>> Igor
>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 Jan 2013 13:40:58 -0500

Igor,
	Frustration that one's proposal isn't immediately adopted as
rough consensus, or that progress takes longer than the contributor
thinks, is understandable.  Expressing such frustration is certainly
within one's prevue.

Whatever you feel personally, making public statements on *any*
individuals (perceived or otherwise) faults and any other form of ad
hominem attack is outside of acceptable IETF conduct.  Period.

It is the chair's role to encourage open discussion and consensus.
Being chair also does not remove the chair's ability to participate as
an individual technical contributor.  This includes my ability to
express my technical or WG-related views which I have done and, when
doing so, I have indicated "as contributor".

If you have objections to my execution of the CCAMP WG Co-chair
position, the right next step is to discuss your concerns with the
other CCAMP chair or our AD.

Lou

On 1/23/2013 5:55 PM, Igor Bryskin wrote:
> Lou,
> 
> What in your opinion would be an acceptable way to say that you have
> not taken time to understand what a group of people within CCAMP WG
> is trying to accomplish and because of that has wasted 1 year of
> people's time by guiding the discussion in circles  from UNI to ENNI
> to MLN/MRN to L1VPN to L3VPN to MLN/MRN again ?
> 
> Igor
>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 24 Jan 2013 20:53:29 +0000

Deborah,

I am not sure what are you agreeing with. You know me long enough to know that all emails I send on the list are nothing but "technically focused". While you have your "CCAMP Co-Chair hat on" I'd like to communicate with you as the CCAMP Co-Chair.

Yesterday, Lou asked me to take a step back and explain what protocol extensions beyond MELGs we have in mind for the ONTs work. The way I interpreted his request is that he was trying to understand in some depth what exactly we are trying to do. This would be a reasonable request coming, say, from Adrian, but coming from Lou it did sound a bit strange timing-wise because starting from the Paris IETF (March 2012) he's been making statements/guidelines (periodically once in 3-4 months) like the following:
"This is definitely neither BCP nor UNI. ENNI  - this is exactly what you, guys, are doing";
" There are some serious problems with ENNI definitions, so this is not ENNI. VNT/MLN/MRN - isn't this is exactly what you are doing?";
"This is L1VPN Basic mode, Enhanced mode, whatever mode, that's what you are doing";
"I still believe that ONTs or whatever you call it must be built on top of MLN/MRN ".

Also get this: we have not yet finalized the definitions of Virtual Link, Virtual Node, Virtual Topology, Overlay Topology, etc., but the good news is that at least one thing we are certain: whatever definitions we will end up with they will be based on MLN/MRN. This is because Lou told us so (actually, insisted): quite unambiguously, on many occasions both on the list and the face-to-face meeting. This was far stronger than an advice, to me it seemed as a condition on which the work could be progressed in CCAMP. Why is such a bias? Could it be the case, for example, that MLN/MRN, brilliant as it is, defines one "thing" for Virtual Link, while we call VL something totally different? 

After I provided the list of things that IMO need to be solved, I asked Lou to give me pointers/quotes from RFCs that according to Lou have solved already almost each and every problem I identified, and what is needed (also according to Lou) is a bunch of BCPs (Gert, you must love this!). Did I get these quotes? No, not so far. Instead, Lou has chosen to feel offended by my email. Why is that? Did I use a foul language? No. Did I personally attack or humiliate him? No. I did criticize him, though, for a case of WG chair power abuse via bullying the discussion and wasting people's time and asked (quite politely and not for the first time) to stop doing that. That's it. I hope criticizing of an IETF WG chair is a right of an IETF WG member and well within the IETF rules of conduct. The only thing that could be said is that my criticism is unfair. But then again, so far I haven't seen a single email on the list expressing the outrage. Knowing you, I am pretty sure that deep in your heart you agree that there is at least some truth in what I am saying.

Anyway I still hope that I'll get these quotes that I asked.

Cheers,
Igor

-----Original Message-----
From: BRUNGARD, DEBORAH A [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2013 5:42 PM
To: Lou Berger; Igor Bryskin
Cc: CCAMP
Subject: RE: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2)

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, January 23, 2013 5:25 PM
To: Igor Bryskin
Cc: CCAMP
Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2)

Lou

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 25 Jan 2013 17:26:35 +0000

Igor,

>I am not sure what are you agreeing with. You know me long enough to know that all emails I send on the list are nothing but "technically focused". While you have your "CCAMP Co-Chair hat on" I'd li…

Let's take this off-list.

Deborah

---

From: John E Drake <[email-masked]>
Date: Fri, 25 Jan 2013 17:35:36 +0000

I disagree.  Airing dirty laundry in public is too entertaining to stop.

Irrespectively Yours,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of BRUNGARD, DEBORAH A
> Sent: Friday, January 25, 2013 9:27 AM
> To: Igor Bryskin
> Cc: CCAMP
> >I am not sure what are you agreeing with. You know me long enough to
> know that all emails I send on the list are nothing but "technically
> focused". While you have your "CCAMP Co-Chair hat on" I'd like to
> communicate with you as the CCAMP Co-Chair.
>

---

From: Gert Grammel <[email-masked]>
Date: Fri, 25 Jan 2013 18:36:14 +0000

Hi John,

Would you mind to draft the charter for a dirty laundry BOF?

Guess we are still in time for the next IETF.

Gert
________________________________________
From: [email-masked] on behalf of John E Drake
Sent: Friday, January 25, 2013 6:35:36 PM
To: BRUNGARD, DEBORAH A; Igor Bryskin
Cc: CCAMP
Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2)

Irrespectively Yours,

John

---

From: John E Drake <[email-masked]>
Date: Fri, 25 Jan 2013 18:54:31 +0000

What a great idea.  Pet Peeves and Grievances too!

Irrespectively Yours,

John

> From: Gert Grammel
> Sent: Friday, January 25, 2013 10:36 AM
> To: John E Drake; BRUNGARD, DEBORAH A; Igor Bryskin
> Cc: CCAMP