Subject: Re: [CCAMP] MELGs - Q&A

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 12 Apr 2013 11:12:28 +0000

Igor,

If my understanding of MELG is correct, It works only (or has use only) for a specific case of centralized parallel path computation in 2 layer network.

1.       When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will be talking to its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource exclusivity of virtual link for immediate server layer i.e. OTN layer.  However if there is resource exclusivity at DWDM layer, this mechanism doesn't work. You need to do loose routing or use distributed PCE model

2.       For cases of concurrent computation (case#2-5), you are mainly talking about global optimization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from the source end of those LSPs.  So there is no point in doing concurrent computation at one network element for the services starting from multiple network elements. At best it looks to me a problem to be solved by network management/planning software.

Thanks
Khuzema

From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

Dieter,

You said:
>> I guess we are coming back to the essential point: "and how often concurrent path computation will be >> used."

To be honest, this surprises me quite a bit, Let me give you some of many reasons as to why concurrent path computations are needed and why this is better than computing one path at a time:

1.      Computing several diverse paths for the same service in the context of service recovery. I hope you realize that computing one path at a time on many configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  having a link with common MELG with a link from another path;

2.      Computing paths for multiple services to be sufficiently disjoint from each other;

3.      Computing paths for multiple services to achieve a global optimization criteria (e.g. minimal summary total cost);

4.      Computing paths for multiple services for the purpose of removing the bandwidth fragmentations;

5.      Computing paths for multiple services to plan shared mesh protection/restoration schemes

6.      Etc.

Also think about this:

1.      If concurrent path computation was not important, why PCEP includes the machinery to do that?

2.      My understanding of the statefull PCE is that it does pretty much nothing but concurrent path computations

You also said:
>> I suppose that if a pce approach is used, i.e., path computation is centralized including the
>> TE-DB, MELG routing extensions are not needed because the information about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configured.
How this logic does not apply to other link attributes such as SRLGs?
What if path computation is not centralized?

Cheers,
Igor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

Hi Pavan,
On 25.03.2013 07:29, Fatai Zhang wrote:
Hi Pavan,

I am not sure how much VL (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.
I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing extensions
could be beneficial.

IMHO, they would only make sense, if:

  *   a path computation function supports the calculation of k shortest paths concurrently
  *   if there is only a single path computation function instance per domain (pce approach)
If path computation is done in a distributed fashion the benefit goes away because
the instances calculate paths independently!
I suppose that if a pce approach is used, i.e., path computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really useful unless their
applicability is broader.

Thanks,
Dieter

Do you think if it makes sense to add a flag (in routing advertisement) to indicate a link is a VL or not?

Best Regards

Fatai

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] MELGs - Q&A

Fatai, Hi!

Good to see that you understand the construct now.

This is not a corner case. The utility of the construct becomes quite significant if you have an application that does concurrent path computations on an abstract topology.

Regards,
-Pavan

_______________________________________________

CCAMP mailing list

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

https://www.ietf.org/mailman/listinfo/ccamp

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 12 Apr 2013 08:08:21 -0400

Khuzema, Hi!

Please see inline..

** 1.       **When Network has more than 2 layer i.e. Packet-OTN-DWDM, the
> Packet (client) layer will be talking to its immediate server layer i.e.
> OTN, which in turn is talking to DWDM layer. Using MELG, client layer path
> computation can take care of resource exclusivity of virtual link for
> immediate server layer i.e. OTN layer.  However if there is resource
> exclusivity at DWDM layer, this mechanism doesn’t work. You need to do
> loose routing or use distributed PCE model
>

[VPB] The behavior is the same as what you would do with SRLGs in a
multi-layer architecture. There are architectures that allow the SRLGs in
the lowest layer to be exported all the way up to the highest layer. The
expectation is that MELGs would be treated in the same vein.

> ****
>
> **2.       **For cases of concurrent computation (case#2-5), you are
> mainly talking about global optimization and diversity among multiple
> services. You can do the path computation, but to actually enact the
> computed path the signaling needs to be done from the source end of those
> LSPs.  So there is no point in doing concurrent computation at one network
> element for the services starting from multiple network elements. At best
> it looks to me a problem to be solved by network management/planning
> software.
>
[VPB]  I'm not sure why you think there is no point in having a centralized
computation function compute paths concurrently for LSPs with different set
of end-points. Even your NMS/planning-software can interact with such
computation engine, retrieve all the paths and then go about initiating the
path-setup from the ingress of each LSP.

Regards,
-Pavan

> **
>
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Igor Bryskin
> *Sent:* Tuesday, March 26, 2013 7:19 PM
> *To:* Dieter Beller; Vishnu Pavan Beeram
>
> *Cc:* [email-masked]
> *Subject:* Re: [CCAMP] MELGs - Q&A****
>
>  ** **
>
> Dieter,****
>
> ** **
>
> You said:****
>
> >> I guess we are coming back to the essential point: "and how often
> concurrent path computation will be >> used."****
>
> ** **
>
> To be honest, this surprises me quite a bit, Let me give you some of many
> reasons as to why concurrent path computations are needed and why this is
> better than computing one path at a time:****
>
> ** **
>
> **1.      **Computing several diverse paths for the same service in the
> context of service recovery. I hope you realize that computing one path at
> a time on many configurations produces no or sub-optimal results. I also
> hope you realize the problem of selecting two paths with one of them
>  having a link with common MELG with a link from another path;****
>
> **2.      **Computing paths for multiple services to be sufficiently
> disjoint from each other;****
>
> **3.      **Computing paths for multiple services to achieve a global
> optimization criteria (e.g. minimal summary total cost);****
>
> **4.      **Computing paths for multiple services for the purpose of
> removing the bandwidth fragmentations;****
>
> **5.      **Computing paths for multiple services to plan shared mesh
> protection/restoration schemes****
>
> **6.      **Etc.****
>
> ** **
>
> Also think about this:****
>
> **1.      **If concurrent path computation was not important, why PCEP
> includes the machinery to do that?****
>
> **2.      **My understanding of the statefull PCE is that it does pretty
> much nothing but concurrent path computations****
>
> ** **
>
> You also said:****
>
> >>exclusive VLs can be kept in the central TE-DB when VLs are configured.*
> ***
>
> How this logic does not apply to other link attributes such as SRLGs?****
>
> What if path computation is not centralized?****
>
> ** **
>
> Cheers,****
>
> Igor****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Dieter Beller
> *Sent:* Monday, March 25, 2013 5:52 PM
> *To:* Vishnu Pavan Beeram
> *Cc:* [email-masked]
> *Subject:* Re: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Hi Pavan,****
>
> On 25.03.2013 07:29, Fatai Zhang wrote:****
>
> Hi Pavan,****
>
>  ****
>
> I am not sure how much VL (Virtual Link) will be used in the practical
> deployment and how often concurrent path computation will be used.****
>
> I guess we are coming back to the essential point: "and how often
> concurrent path computation will be used."
>
> IMHO, they would only make sense, if:****
>
>    - a path computation function supports the calculation of k shortest
>    paths concurrently****
>    - if there is only a single path computation function instance per
>    domain (pce approach)
>    the instances calculate paths independently!****
>
> ****
>  ****
> Do you think if it makes sense to add a flag (in routing advertisement) to
> indicate a link is a VL or not?****
>
>  ****
>
>  ****
>
>  ****
>
> Best Regards****
>
>  ****
>
> Fatai****
>
>  ****
>
> *From:* Vishnu Pavan Beeram [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Friday, March 22, 2013 8:57 PM
> *To:* Fatai Zhang
> *Cc:* Igor Bryskin; [email-masked]
> *Subject:* Re: [CCAMP] MELGs - Q&A****
>
>  ****
>
> Fatai, Hi!****
>
>  ****
>
> Good to see that you understand the construct now.****
>
>  ****
>
> This is not a corner case. The utility of the construct becomes quite
> significant if you have an application that does concurrent path
> computations on an abstract topology.****
>
>  ****
>
> Regards,****
>
> -Pavan****
>
>
>
> ****
>
> _______________________________________________****
>
> CCAMP mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/ccamp****
>
> ** **
>
> -- ****
>
> *DIETER BELLER *
>
> Mobil: +49 175 7266874 ****
>
> [email-masked] *
>
> ** **
>
> Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub · Dr.
> Rainer Fechner · Andreas Gehe ****
>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 12 Apr 2013 13:06:19 +0000

Khuzema,

2.       For cases of concurrent computation (case#2-5), you are mainly talking about global optimization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from the source end of those LSPs.  So there is no point in doing concurrent computation at one network element for the services starting from multiple network elements. At best it looks to me a problem to be solved by network management/planning software.
Well, when an ingress node is initiating a service, it is doing so on request from some management entity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting paths as explicit EROs in provisioning requests sent to each of the service ingresses. How else, for example,  you can set up several services originated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the statefull PCE work?

Cheers,
Igor

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

Khuzema, Hi!

Please see inline..

[VPB] The behavior is the same as what you would do with SRLGs in a multi-layer architecture. There are architectures that allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. The expectation is that MELGs would be treated in the same vein.

2.       For cases of concurrent computation (case#2-5), you are mainly talking about global optimization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from the source end of those LSPs.  So there is no point in doing concurrent computation at one network element for the services starting from multiple network elements. At best it looks to me a problem to be solved by network management/planning software.
[VPB]  I'm not sure why you think there is no point in having a centralized computation function compute paths concurrently for LSPs with different set of end-points. Even your NMS/planning-software can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from the ingress of each LSP.

Regards,
-Pavan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] MELGs - Q&A

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] MELGs - Q&A

Hi Pavan,
On 25.03.2013 07<tel:25.03.2013%2007>:29, Fatai Zhang wrote:
Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125<tel:%2B49%20711%20821%2043125>
Mobil: +49 175 7266874<tel:%2B49%20175%207266874>
[email-masked]<mailto:[email-masked]>

---

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 12 Apr 2013 14:55:23 +0000

Hi Igor,

Ok. This would be useful if network architecture is based on external PCE or mgmt entity as PCE in client layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path in server layer without getting into virtual link and MELG stuff.

Is that correct?

Khuzema

From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 12 Apr 2013 15:08:46 +0000

Khuzema,

I am not a fan of inter-layer path computations (nor I am a fan of inter-PCE computations). In my mind path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from lower layers should be translated into X layer link SRLGs/MELGs and specified with X layer specific SRLG/MELG IDs.

Cheers,
Igor

From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Hi Igor,

Is that correct?

Khuzema

Cc: Dieter Beller; [email-masked]<mailto:[email-masked]>

Khuzema,

Cheers,
Igor

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] MELGs - Q&A

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 12 Apr 2013 16:05:54 +0000

Hi Igor,

For multi-layer (more than 2) network, consider all the layers are meshy (that's when virtual links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a virtual link can take will change. Mapping lower layer MELGs to higher layer MELGs won't be practical if done in distributed manner, so it has to be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which can be utilized for layer specific path computation (as it is doing it anyway).

This kind of architecture has all the pieces that are required for Inter-PCE communication (across layers), except the protocol that would actually make the 2 PCEs talk.

You seem to be doing something that you don't like :)

Regards
Khuzema

From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 12 Apr 2013 16:22:18 +0000

Khuzema,

MELGs have nothing to do with bandwidth. MELG is a concrete network resource in a server layer that two or more Virtual Links in a client layer depend on in a mutually exclusive way. An example of MELG is a WDM layer transponder that can terminate either of respective WDM layer tunnels (but not both at the same time) for two OTN layer Virtual Links. If you advertise a Virtual Link, say, for Ethernet layer that depends on the connection in OTN layer going through one of the mentioned OTN links, the Ethernet VL must inherit the MELG similarly like it does SRLGs advertised for the OTN links.

Igor

Sent: Friday, April 12, 2013 12:06 PM

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 12 Apr 2013 17:00:52 +0000

Hi Igor,

Do you mean, if virtual link do not have any specific constraint, for example a link in the path (not talking about egress links/interfaces) must be traversed to realize the virtual link, there wont be any MELG for the virtual link?

Regds
Khuzema

Sent: Friday, April 12, 2013 9:52 PM

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 12 Apr 2013 18:25:23 +0000

Khuzema,

Think about MELG as an SRLG that is shared between two or more links in its entirety. When two real links have an SRLG in common, it means that two real links can co-exist concurrently, but there is something (e.g. common conduit, note that the conduit has room for more than for one link) that will bring both these links down, if this something fails (e.g. conduit is cut ). Now consider that this something must be taken in its entirety by one of the links to become operational . In this case SRLG becomes MELG. Note that MELG is only meaningful for virtual links (unlike SRLG that makes sense for either real or virtual link). Why would you advertise two links that mutually exclude each other rather than advertising only one of them at a time, unless the two are virtual links and hence both available for the client layer connections?

Igor

Sent: Friday, April 12, 2013 1:01 PM

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Khuzema Pithewan <[email-masked]>
Date: Mon, 15 Apr 2013 04:04:35 +0000

Hi Igor,

I understand the SRLG and MELG behavior you have penned .

My concern was little different.  With changing resource consumption (because of dynamicity the network has) in the network links, potential paths a set of virtual link can take will change and hence its MELG, as it is tied to a resource it can take. So unless virtual links paths are nailed down, it would be hard to compute MELGs in distributed way.

Another point is, virtual links can be viewed as oversubscription of resources (in MELG context). Taking an example (for OTN, I know it would work differently for a Wavelength in WDM), a link resources are worth 1 TB of BW, user has provisioned 20 virtual links of 100G each going via that OTN link.  Physically, only 10 will get committed. But which 10? It will really depend on network dynamics at the time of demand to commit. MELGs are not that effective here. You need some different mechanism.

Regds
Khuzema

Sent: Friday, April 12, 2013 11:55 PM

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 15 Apr 2013 16:14:19 +0000

Khuzema,
Please, see in-line.

Igor

Sent: Monday, April 15, 2013 12:05 AM

Hi Igor,

IB>> I think you are missing the point here. Virtual Link server layer paths are pinned as far as fate sharing is concerned (that is, they are pinned on  server layer link level). It would make little sense to advertise VL SRLGs if the SRLGs constantly change. The same is true for MELGs.  SRLGs/MELGs advertised for VLs normally do not change: neither over time nor when VLs become committed/uncommitted.

IB>> As I mentioned before MELGs have nothing to do with bandwidth and were never intended to solve the problems such as you describe (just like it would not make much sense to solve such problem with SRLGs :=)
Again,  MELG is an extreme case SRLG designed exclusively for VLs (no more and no less).

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Khuzema Pithewan <[email-masked]>
Date: Tue, 16 Apr 2013 11:08:15 +0000

Hi Igor,

I am trying to summarize the discussion we had so far. Pls see if my conclusion is in sync with the idea of MELG you have

MELG is useful when

1.       server layer VLs are nailed down for the resources on the server layer links that are shared among multiple VLs. These resources are typically wavelength on a fiber (can it be anything else??). In other words, if 2 VLs are pinned to use a particular wavelength on a particular fiber, then these 2 VLs will have MELG for the wavelength.

2.       server layer do not have centralized path computation entity which can be used by client layer to ask for concurrent diverse path computation within server layer.

3.       Client layer has a centralized path computation entity, which would compute paths for client+server layer.

4.       The need is to centralized concurrent computation of more than one client+server layer path that meets some diversity and resource exclusivity requirements.

Regds
Khuzema

Sent: Monday, April 15, 2013 9:44 PM

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 16 Apr 2013 10:10:12 -0400

Khuzema, Hi!

MELGs are useful and come into play only when:
(1) The server network domain is abstracted and the advertised Virtual
TE-links possess some mutual exclusivity relationship.
(2) There is a Centralized path computation entity in the client domain
(computes paths in terms of Client TE-links/TE-nodes) that is capable of
doing concurrent path computations.

If either of the above 2 statements is NOT true, there is no utility for
MELGs.
At the risk of being pedantic:
- Are MELGs needed when the server-network domain in not abstracted (no
Virtual TE links)? The answer is NO.
- Are MELGs needed when you have a distributed path-computation
architecture (Client PCE interacting with Server PCE)? The answer is NO.
- Are MELGs needed when the centralized path-computation engine doesn't
(can't) do concurrent computations? The answer is NO.

The actual procedures involved in abstracting the server network domain is
beyond the scope of <draft-melgs>. The abstraction procedure itself is
implementation-specific (maybe someday someone would put together a draft
for discussing this). Though it is true that the primary use-case we had in
mind when coming up with this new construct involves a lambda-layer server
network domain, there is really no restriction (at a conceptual level) on
using this construct when abstracting a packet-layer server network domain
or a TDM-layer server network domain. It is up to the implementation on how
to make best use of this construct.

When you advertise a Virtual TE-link into a client network domain, you are
doing this based on the existence of some potential underlying server-path.
TE attributes like SRLGs, MELGs, delay etc that get advertised for the
Virtual TE-link depend on the underlying server-path that is chosen for
catering to this Client TE-link. If the underlying server-path keeps
changing (based on network events), these TE attributes would also keep
changing. The procedure for keeping the advertised information "current" is
an implementation choice.

If there exists such a thing as an abstraction manager (again, this is
totally implementation specific), then the assumption is that it does one
of the following -
(a) computes new server-paths for the Virtual TE links whenever there is a
change in the network (may not be very scalable in some architectures),
(b) or does periodic path-computation for each Virtual TE link,
(c) or uses a policy to pin down the Virtual TE-link to a specific
underlying server-path,
(d) or uses a combination of (a), (b), (c).

<draft-melgs> doesn't make any recommendation as to what choice the
abstraction manager would need to take.

Hope this helps.
-Pavan

On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan <[email-masked]>wrote:

>  Hi Igor,****
>
> ** **
>
> I am trying to summarize the discussion we had so far. Pls see if my
> conclusion is in sync with the idea of MELG you have ****
>
> ** **
>
> MELG is useful when****
>
> **1.       **server layer VLs are nailed down for the resources on the
> server layer links that are shared among multiple VLs. These resources are
> typically wavelength on a fiber (can it be anything else??). In other
> words, if 2 VLs are pinned to use a particular wavelength on a particular
> fiber, then these 2 VLs will have MELG for the wavelength.****
>
> **2.       **server layer do not have centralized path computation entity
> which can be used by client layer to ask for concurrent diverse path
> computation within server layer.****
>
> **3.       **Client layer has a centralized path computation entity,
> which would compute paths for client+server layer.****
>
> **4.       **The need is to centralized concurrent computation of more
> than one client+server layer path that meets some diversity and resource
> exclusivity requirements.****
>
> ** **
>
> Regds****
>
> Khuzema****
>
> ** **
>
> *From:* Igor Bryskin [mailto:[email-masked]]
> *Sent:* Monday, April 15, 2013 9:44 PM
>
> *To:* Khuzema Pithewan; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [email-masked]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
>  ** **
>
> Khuzema,****
>
> Please, see in-line.****
>
> ** **
>
> Igor****
>
> ** **
>
> *From:* Khuzema Pithewan [mailto:[email-masked]]
> *Sent:* Monday, April 15, 2013 12:05 AM
> *To:* Igor Bryskin; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [email-masked]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Hi Igor,****
>
> ** **
>
> I understand the SRLG and MELG behavior you have penned .****
>
> ** **
>
> My concern was little different.  With changing resource consumption
> (because of dynamicity the network has) in the network links, potential
> paths a set of virtual link can take will change and hence its MELG, as it
> is tied to a resource it can take. So unless virtual links paths are nailed
> down, it would be hard to compute MELGs in distributed way.****
>
> ** **
>
> IB>> I think you are missing the point here. Virtual Link server layer
> paths are pinned as far as fate sharing is concerned (that is, they are
> pinned on  server layer link level). It would make little sense to
> advertise VL SRLGs if the SRLGs constantly change. The same is true for
> MELGs.  SRLGs/MELGs advertised for VLs normally do not change: neither over
> time nor when VLs become committed/uncommitted.****
>
> ** **
>
> Another point is, virtual links can be viewed as oversubscription of
> resources (in MELG context). Taking an example (for OTN, I know it would
> work differently for a Wavelength in WDM), a link resources are worth 1 TB
> of BW, user has provisioned 20 virtual links of 100G each going via that
> OTN link.  Physically, only 10 will get committed. But which 10? It will
> really depend on network dynamics at the time of demand to commit. MELGs
> are not that effective here. You need some different mechanism.****
>
> ** **
>
> IB>> As I mentioned before MELGs have nothing to do with bandwidth and
> were never intended to solve the problems such as you describe (just like
> it would not make much sense to solve such problem with SRLGs :=)****
>
> Again,  MELG is an extreme case SRLG designed exclusively for VLs (no more
> and no less).****
>
> ** **
>
> Regds****
>
> Khuzema****
>
> ** **
>
> ** **
>
> *From:* Igor Bryskin [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Friday, April 12, 2013 11:55 PM
> *To:* Khuzema Pithewan; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [email-masked]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Khuzema,****
>
> ** **
>
> Think about MELG as an SRLG that is shared between two or more links in
> its entirety. When two real links have an SRLG in common, it means that two
> real links can co-exist concurrently, but there is something (e.g. common
> conduit, note that the conduit has room for more than for one link) that
> will bring both these links down, if this something fails (e.g. conduit is
> cut ). Now consider that this something must be taken in its entirety by
> one of the links to become operational . In this case SRLG becomes MELG.
> Note that MELG is only meaningful for virtual links (unlike SRLG that makes
> sense for either real or virtual link). Why would you advertise two links
> that mutually exclude each other rather than advertising only one of them
> at a time, unless the two are virtual links and hence both available for
> the client layer connections?****
>
> ** **
>
> Igor ****
>
> ** **
>
> ** **
>
> *From:* Khuzema Pithewan [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Friday, April 12, 2013 1:01 PM
> *To:* Igor Bryskin; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [email-masked]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Hi Igor,****
>
> ** **
>
> Do you mean, if virtual link do not have any specific constraint, for
> example a link in the path (not talking about egress links/interfaces) must
> be traversed to realize the virtual link, there wont be any MELG for the
> virtual link?****
>
> ** **
>
> Regds****
>
> Khuzema****
>
> ** **
>
> *From:* Igor Bryskin [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Friday, April 12, 2013 9:52 PM
> *To:* Khuzema Pithewan; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [email-masked]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Khuzema,****
>
>  ****
>
> MELGs have nothing to do with bandwidth. MELG is a concrete network
> resource in a server layer that two or more Virtual Links in a client layer
> depend on in a mutually exclusive way. An example of MELG is a WDM layer
> transponder that can terminate either of respective WDM layer tunnels (but
> not both at the same time) for two OTN layer Virtual Links. If you
> advertise a Virtual Link, say, for Ethernet layer that depends on the
> connection in OTN layer going through one of the mentioned OTN links, the
> Ethernet VL must inherit the MELG similarly like it does SRLGs advertised
> for the OTN links.****
>
>  ****
>
> Igor****
>
>  ****
>
>  ****
>
> *From:* Khuzema Pithewan [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Friday, April 12, 2013 12:06 PM
> *To:* Igor Bryskin; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [email-masked]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
>  ****
>
> Hi Igor,****
>
>  ****
>
> For multi-layer (more than 2) network, consider all the layers are meshy
> (that’s when virtual links are useful anyway), MELGs of virtual link will
> change as and when BW/wavelength availability changes, because potential
> paths, a virtual link can take will change. Mapping lower layer MELGs to
> higher layer MELGs won’t be practical if done in distributed manner, so it
> has to be centralized. So you do have central element in each layer that
> knows all the risk and paths (a PCE?), which can be utilized for layer
> specific path computation (as it is doing it anyway). ****
>
>  ****
>
> This kind of architecture has all the pieces that are required for
> Inter-PCE communication (across layers), except the protocol that would
> actually make the 2 PCEs talk.****
>
>  ****
>
> You seem to be doing something that you don’t like J****
>
>  ****
>
> Regards****
>
> Khuzema****
>
>  ****
>
> *From:* Igor Bryskin [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Friday, April 12, 2013 8:39 PM
> *To:* Khuzema Pithewan; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [email-masked]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
>  ****
>
> Khuzema,****
>
>  ****
>
> I am not a fan of inter-layer path computations (nor I am a fan of
> inter-PCE computations). In my mind path computation for a service or
> services in layer X is performed only in layer X, i.e. considers only X
> layer links (real or virtual). As Pavan mentioned SRLGs and MELGs that need
> to be inherited from lower layers should be translated into X layer link
> SRLGs/MELGs and specified with X layer specific SRLG/MELG IDs.****
>
>  ****
>
> Cheers,****
>
> Igor****
>
>  ****
>
>  ****
>
> *From:* Khuzema Pithewan [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Friday, April 12, 2013 10:55 AM
> *To:* Igor Bryskin; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [email-masked]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
>  ****
>
> Hi Igor,****
>
>  ****
>
> Ok. This would be useful if network architecture is based on external PCE
> or mgmt entity as PCE in client layer, but there is no counterpart in
> server layer, otherwise one could have inter-PCE communication to achieve
> diverse path in server layer without getting into virtual link and MELG
> stuff.****
>
>  ****
>
> Is that correct?****
>
>  ****
>
> Khuzema****
>
>  ****
>
> *From:* Igor Bryskin [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Friday, April 12, 2013 6:36 PM
> *To:* Vishnu Pavan Beeram; Khuzema Pithewan
> *Cc:* Dieter Beller; [email-masked]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
>  ****
>
> Khuzema,****
>
>  ****
>
> 2.       For cases of concurrent computation (case#2-5), you are mainly
> talking about global optimization and diversity among multiple services.
> You can do the path computation, but to actually enact the computed path
> the signaling needs to be done from the source end of those LSPs.  So there
> is no point in doing concurrent computation at one network element for the
> services starting from multiple network elements. At best it looks to me a
> problem to be solved by network management/planning software. ****
>
> Well, when an ingress node is initiating a service, it is doing so on
> request from some management entity. This management entity can compute
> paths for many services with some global criteria in mind, and then specify
> the resulting paths as explicit EROs in provisioning requests sent to each
> of the service ingresses. How else, for example,  you can set up several
> services originated from different nodes that are disjoint from each other?
> Also, what is the point in your opinion of the statefull PCE work? ****
>
>  ****
>
> Cheers,****
>
> Igor****
>
>  ****
>
> *Sent:* Friday, April 12, 2013 8:08 AM
> *To:* Khuzema Pithewan
> *Cc:* Igor Bryskin; Dieter Beller; [email-masked]
> Khuzema, Hi!****
> Please see inline..****
>  1.       When Network has more than 2 layer i.e. Packet-OTN-DWDM, the
> loose routing or use distributed PCE model****
>
>   ****
>
> expectation is that MELGs would be treated in the same vein. ****
>
>  2.       For cases of concurrent computation (case#2-5), you are mainly
> talking about global optimization and diversity among multiple services.
> You can do the path computation, but to actually enact the computed path
> the signaling needs to be done from the source end of those LSPs.  So there
> is no point in doing concurrent computation at one network element for the
> services starting from multiple network elements. At best it looks to me a
> problem to be solved by network management/planning software. ****
>
>  [VPB]  I'm not sure why you think there is no point in having a
> centralized computation function compute paths concurrently for LSPs with
> different set of end-points. Even your NMS/planning-software can interact
> with such computation engine, retrieve all the paths and then go about
> initiating the path-setup from the ingress of each LSP. ****
>
>  ****
>
> Regards,****
>
> -Pavan****
>
>  ****
>
>   ****
>
>  ****
>
>  ****
>
> *To:* Dieter Beller; Vishnu Pavan Beeram****
>
>
> *Cc:* [email-masked]
> 1.      Computing several diverse paths for the same service in the
> 2.      Computing paths for multiple services to be sufficiently disjoint
> from each other;****
>
> 3.      Computing paths for multiple services to achieve a global
> 4.      Computing paths for multiple services for the purpose of removing
> the bandwidth fragmentations;****
>
> 5.      Computing paths for multiple services to plan shared mesh
> 6.      Etc.****
> 1.      If concurrent path computation was not important, why PCEP
> 2.      My understanding of the statefull PCE is that it does pretty much
> nothing but concurrent path computations****
>
>  ****
>
> You also said:****
>
> Dieter****
> -- ** **
> *DIETER BELLER *****
> Phone: +49 711 821 43125 begin_of_the_skype_highlighting +49 711 821 43125FREE
> end_of_the_skype_highlighting <%2B49%20711%20821%2043125>
> Mobil: +49 175 7266874 begin_of_the_skype_highlighting +49 175 7266874FREE
> end_of_the_skype_highlighting <%2B49%20175%207266874> ****
>
> [email-masked] *****
>
>  ****
>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 16 Apr 2013 14:19:45 +0000

Khuzema,
Please, see in line.

Sent: Tuesday, April 16, 2013 7:08 AM

Hi Igor,

MELG is useful when

1.      server layer VLs are nailed down for the resources on the server layer links that are shared among multiple VLs.
IB>> Correction: server layer link-level paths supporting *client layer* VLs are nailed down. The resources of said paths are sharable between the paths (and hence VLs) but not available for anything else.

These resources are typically wavelength on a fiber (can it be anything else??).
IB>> Server layer does not have to be WDM

In other words, if 2 VLs are pinned to use a particular wavelength on a particular fiber, then these 2 VLs will have MELG for the wavelength.
IB>> Correction: Wavelength is not the only type of resource that is used in WDM layer. If two paths use the same transponder, converter, regenerator, etc. then corresponding VLs have a MELG in common. If two paths have a WDM link in common on which they *must* use the same wavelength (e.g. because the paths are started on fixed transponders of the same frequency), then they also have an MELG in common. If two paths have to use the same wavelength on a common WDM link because this is the only wavelength available at the moment, then the VLs *do not* have an MELG in common (just  usual lack of resources on the link)

2.      server layer do not have centralized path computation entity which can be used by client layer to ask for concurrent diverse path computation within server layer.
IB>> This approach has nothing to do with VLs. VLs (just like real links) are supposed to be pre-planned in a different time frame from when client layer connections are set up. When VLs are advertised, this means that the server layer paths are successfully computed and pinned already (btw by server layer path computer). Asking server layer path computation dynamically does not guarantee  any success, so, if it fails, what to do next? You cannot orchestrate any restoration schemes in the client layer this way. Instaed, we suggest solid as_good_as_real Virtual Topology to use.

3.      Client layer has a centralized path computation entity, which would compute paths for client+server layer.
IB>> Correction: only for client layer, based on client layer VLs

4.      The need is to centralized concurrent computation of more than one client+server layer path that meets some diversity and resource exclusivity requirements.
IB>> Correction: there is a need for concurrent path computation in the client layer and because the client layer topology is virtual, you need MELGs to consider

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Khuzema Pithewan <[email-masked]>
Date: Wed, 17 Apr 2013 11:18:31 +0000

Hi Igor and Pavan,

Thanks for the discussion.

I understand MELG proposal is not really precluding non-WDM server layer. I am trying to see, will it solve similar issues if they are there in more dynamic OTN (TDM) server layer.

MELG seems to be made useful by quite a bit of mgmt provisioning w.r.t. VLs and its path in server layer.  It is one way, a client layer can make use of server layer resource information (for path computation). However, is it the typical way?  I am not sure.

Regds
Khuzema

Sent: Tuesday, April 16, 2013 7:50 PM

Khuzema,
Please, see in line.

Hi Igor,

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Apr 2013 12:42:56 +0000

Khuzema,

Comments inline.

Irrespectively Yours,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Khuzema Pithewan
Sent: Wednesday, April 17, 2013 4:19 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

Hi Igor and Pavan,

JD:  This is a very good point.  While MELGs can be used in higher layer server networks, they may not have any utility in these networks because these networks do not use physical resources directly.

JD:  The draft should note that MELGs have utility only in client networks that use centralized concurrent path computation.

Regds
Khuzema

Khuzema,
Please, see in line.

Hi Igor,

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 17 Apr 2013 12:57:33 +0000

John,
You said:

If a client device needs to compute two disjoint paths to a destination (e.g. for recovery purposes), the computation will be concurrent (of more than one paths), but not necessarily centralized. Note that MELGs need to be considered in this case to avoid selecting  links belonging to different paths with an MELG in common. Would you agree?

Cheers,
Igor

From: John E Drake [mailto:[email-masked]]
Sent: Wednesday, April 17, 2013 8:43 AM
To: Khuzema Pithewan; Igor Bryskin; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Khuzema,

Comments inline.

Irrespectively Yours,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Khuzema Pithewan

Hi Igor and Pavan,

Regds
Khuzema

Khuzema,
Please, see in line.

Hi Igor,

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: John E Drake <[email-masked]>
Date: Wed, 17 Apr 2013 13:05:38 +0000

Sure

Irrespectively Yours,

John

From: Igor Bryskin [mailto:[email-masked]]
Sent: Wednesday, April 17, 2013 5:58 AM
To: John E Drake; Khuzema Pithewan; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

John,
You said:

Cheers,
Igor

Khuzema,

Comments inline.

Irrespectively Yours,

John

Hi Igor and Pavan,

Regds
Khuzema

Khuzema,
Please, see in line.

Hi Igor,

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 19 Apr 2013 03:07:55 +0000

Hi Igor,

This case can be still regarded as centralized path computation, ie., multiple disjoint paths are computed by one single node.
===================================================================================================================
If a client device needs to compute two disjoint paths to a destination (e.g. for recovery purposes), the computation will be concurrent (of more than one paths), but not necessarily centralized. Note that MELGs need to be considered in this case to avoid selecting  links belonging to different paths with an MELG in common. Would you agree?

Best Regards

Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, April 17, 2013 8:58 PM
To: John E Drake; Khuzema Pithewan; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

John,
You said:

Cheers,
Igor

Khuzema,

Comments inline.

Irrespectively Yours,

John

Hi Igor and Pavan,

Regds
Khuzema

Khuzema,
Please, see in line.

Hi Igor,

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 19 Apr 2013 03:25:42 +0000

Hi Pavan, Igor

I think there are some concerns about the applicability of MELGs and I have the same feeling as Khuzema and Dieter.

I still think that MELGS can only handle a very small corner case as you put many cases below where MELGs are not needed.

What is Virtual Link? As described in RFC6001, it says as below. So my question is: when there are two VLs created through Call approach as defined in RFC6001, one has 3 potential paths in the server layer to setup FA-LSP, and another has 2 potential paths in the server layer, and only one of the 3 &2 has the same resource shared in the server layer.

How MELGs can help in this case?
==============================================================================================================
A virtual TE link is defined as a TE link between two upper-layer nodes that is not associated with a fully provisioned FA-LSP in a lower layer [RFC5212<http://tools.ietf.org/html/rfc5212>].  A virtual TE link is advertised as any TE link, following the rules in [RFC4206<http://tools.ietf.org/html/rfc4206>] defined for fully provisioned TE links.  A virtual TE link represents thus the potentiality to set up an FA-LSP in the lower layer to support the TE link that has been advertised.
============================================================================================================

Best Regards

Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan
Cc: [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

Khuzema, Hi!

MELGs are useful and come into play only when:
(1) The server network domain is abstracted and the advertised Virtual TE-links possess some mutual exclusivity relationship.
(2) There is a Centralized path computation entity in the client domain (computes paths in terms of Client TE-links/TE-nodes) that is capable of doing concurrent path computations.

If either of the above 2 statements is NOT true, there is no utility for MELGs.
At the risk of being pedantic:
- Are MELGs needed when the server-network domain in not abstracted (no Virtual TE links)? The answer is NO.
- Are MELGs needed when you have a distributed path-computation architecture (Client PCE interacting with Server PCE)? The answer is NO.
- Are MELGs needed when the centralized path-computation engine doesn't (can't) do concurrent computations? The answer is NO.

The actual procedures involved in abstracting the server network domain is beyond the scope of <draft-melgs>. The abstraction procedure itself is implementation-specific (maybe someday someone would put together a draft for discussing this). Though it is true that the primary use-case we had in mind when coming up with this new construct involves a lambda-layer server network domain, there is really no restriction (at a conceptual level) on using this construct when abstracting a packet-layer server network domain or a TDM-layer server network domain. It is up to the implementation on how to make best use of this construct.

When you advertise a Virtual TE-link into a client network domain, you are doing this based on the existence of some potential underlying server-path. TE attributes like SRLGs, MELGs, delay etc that get advertised for the Virtual TE-link depend on the underlying server-path that is chosen for catering to this Client TE-link. If the underlying server-path keeps changing (based on network events), these TE attributes would also keep changing. The procedure for keeping the advertised information "current" is an implementation choice.

If there exists such a thing as an abstraction manager (again, this is totally implementation specific), then the assumption is that it does one of the following -
(a) computes new server-paths for the Virtual TE links whenever there is a change in the network (may not be very scalable in some architectures),
(b) or does periodic path-computation for each Virtual TE link,
(c) or uses a policy to pin down the Virtual TE-link to a specific underlying server-path,
(d) or uses a combination of (a), (b), (c).

<draft-melgs> doesn't make any recommendation as to what choice the abstraction manager would need to take.

Hope this helps.
-Pavan

On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Igor,

MELG is useful when

Regds
Khuzema

From: Igor Bryskin [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, April 15, 2013 9:44 PM

Khuzema,
Please, see in-line.

Igor

From: Khuzema Pithewan [mailto:[email-masked]<mailto:[email-masked]>]

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting [X] +49 711 821 43125 FREE  end_of_the_skype_highlighting<tel:%2B49%20711%20821%2043125>
Mobil: +49 175 7266874 begin_of_the_skype_highlighting [X] +49 175 7266874 FREE  end_of_the_skype_highlighting<tel:%2B49%20175%207266874>
[email-masked]<mailto:[email-masked]>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 19 Apr 2013 12:13:49 +0000

Fatai,

What I said was that this is not necessarily the case of centralized path computation: a given NE, being an ingress of a service, is capable to compute disjoint paths to the service destination on its own (i.e. without asking a network PCE to do so). The point is that MELGs need to be considered in this case just as in the case of centralized concurrent path computation for multiple services.

Cheers,
Igor

From: Fatai Zhang [mailto:[email-masked]]
Sent: Thursday, April 18, 2013 11:08 PM
To: Igor Bryskin; John E Drake; Khuzema Pithewan; Vishnu Pavan Beeram
Cc: [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Hi Igor,

Best Regards

Fatai

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Igor Bryskin

John,
You said:

Cheers,
Igor

Khuzema,

Comments inline.

Irrespectively Yours,

John

Hi Igor and Pavan,

Regds
Khuzema

Khuzema,
Please, see in line.

Hi Igor,

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 19 Apr 2013 12:22:28 +0000

Fatai,

IB>> Simple: with MELGs the path computer will know in advance that selecting two paths with a virtual link belonging to path #1 and a virtual link belonging to path #2 having an MELG in common will be a bad idea, because an attempt to provision such path combination is guaranteed to fail. Without MELGs the path computer won't have such knowledge.

Cheers,
Igor

From: Fatai Zhang [mailto:[email-masked]]
Sent: Thursday, April 18, 2013 11:26 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Beller
Cc: [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Hi Pavan, Igor

Best Regards

Fatai

Khuzema, Hi!

Hope this helps.
-Pavan

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting [Image removed by sender.] +49 711 821 43125 FREE  end_of_the_skype_highlighting<tel:%2B49%20711%20821%2043125>
Mobil: +49 175 7266874 begin_of_the_skype_highlighting [Image removed by sender.] +49 175 7266874 FREE  end_of_the_skype_highlighting<tel:%2B49%20175%207266874>
[email-masked]<mailto:[email-masked]>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 19 Apr 2013 10:28:42 -0400

Fatai, Hi!

See inline:

 ** **
>
> I still think that MELGS can only handle a very small corner case as you
> put many cases below where MELGs are not needed.
>

[VPB] MELGs come into play when there are Virtual TE Links and  there is a
client computation function capable of doing concurrent computations. If
the client computation function cannot do concurrent computations, then the
MELGs have NO utility.  If you are not using Virtual TE Links and are
relying on a hierarchical PCE framework to co-ordinate between the client
and server domains for the selection of paths, then you don't need MELGs.

Let me try an analogy - If I'm riding a bike, I need a helmet. If I'm
driving a car (not NASCAR), the helmet has no utility. That doesn't mean
the helmet serves a small corner case :)

> ****
>
> ** **
>
> What is Virtual Link? As described in RFC6001, it says as below. So my
> question is: when there are two VLs created through Call approach as
> defined in RFC6001, one has 3 potential paths in the server layer to setup
> FA-LSP, and another has 2 potential paths in the server layer, and only one
> of the 3 &2 has the same resource shared in the server layer. ****
>
> ** **
>

[VPB] I think the disconnect between us has got to do with how the Virtual
TE (VTE) Link gets advertised. Say, that there are 3 potential paths in the
server layer that can cater to a given VTE link. In our notion of the
"Virtual TE Link", at the time of advertising there already exists an
association between the VTE link and one of these 3 paths. Without
associating your VTE link with a specific server-path, you wouldn't be able
to accurately advertise attributes like diversity, delay,
mutual-exclusivity etc. If I understood your question correctly, your
notion of how the Virtual TE Link gets advertised seems to be different -
you don't associate the VTE link to a specific potential path at the time
of advertisement.

Continuing with your example - If the path that gets associated with
VTE-Link-1 and the path that gets associated with VTE-Link-2 depend on the
same resource, "MELGs" would make sure that the client computation function
is aware of the existence of such "mutual exclusivity" relationship.

BR,
-Pavan

> A virtual TE link is defined as a TE link between two upper-layer nodes
> that is not associated with a fully provisioned FA-LSP in a lower layer [
> RFC5212 <http://tools.ietf.org/html/rfc5212>].  A virtual TE link is
> advertised as any TE link, following the rules in [RFC4206<http://tools.ietf.org/html/rfc4206>]
> defined for fully provisioned TE links.  A virtual TE link represents
> thus the potentiality to set up an FA-LSP in the lower layer to support
> the TE link that has been advertised.****
>
>
> Of *Vishnu Pavan Beeram
> *Sent:* Tuesday, April 16, 2013 10:10 PM
> *To:* Khuzema Pithewan
>
> *Cc:* [email-masked]
> MELGs are useful and come into play only when:****
>
> TE-links possess some mutual exclusivity relationship.****
>
> doing concurrent path computations.****
>
> ** **
>
> MELGs. ****
> At the risk of being pedantic: ****
>
> Virtual TE links)? The answer is NO.****
>
> architecture (Client PCE interacting with Server PCE)? The answer is NO.**
> **
>
> (can't) do concurrent computations? The answer is NO.****
>
> ** **
>
> to make best use of this construct. ****
>
> ** **
>
> an implementation choice. ****
>
> ** **
>
> of the following - ****
> change in the network (may not be very scalable in some architectures), **
> **
>
> (b) or does periodic path-computation for each Virtual TE link, ****
>
> underlying server-path, ****
>
> (d) or uses a combination of (a), (b), (c).****
>
> ** **
>
> abstraction manager would need to take.****
>
> ** **
>
> Hope this helps.****
>
> -Pavan****
>
> ** **
>
> On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan <[email-masked]>
> wrote:****
>
> Hi Igor,****
>
>  ****
>
> 1.       server layer VLs are nailed down for the resources on the server
> layer links that are shared among multiple VLs. These resources are
> 2.       server layer do not have centralized path computation entity
> 3.       Client layer has a centralized path computation entity, which
> would compute paths for client+server layer.****
>
> 4.       The need is to centralized concurrent computation of more than
> one client+server layer path that meets some diversity and resource
> *Sent:* Monday, April 15, 2013 9:44 PM****
>
>
> end_of_the_skype_highlighting begin_of_the_skype_highlighting +49 711 821
> 43125 begin_of_the_skype_highlighting +49 711 821 43125 FREE
> end_of_the_skype_highlighting FREE  begin_of_the_skype_highlighting +49
> 711 821 43125 FREE  <%2B49%20711%20821%2043125>
> end_of_the_skype_highlighting begin_of_the_skype_highlighting +49 175
> 7266874 begin_of_the_skype_highlighting +49 175 7266874 FREE
> end_of_the_skype_highlighting FREE  begin_of_the_skype_highlighting +49
> 175 7266874 FREE  <%2B49%20175%207266874> ****
>

---

From: Fatai Zhang <[email-masked]>
Date: Sat, 20 Apr 2013 01:10:09 +0000

Hi Pavan,

In my exmple, I just want to show you that the more generic case for the VTE link (to improve resource usage efficiency), which does not associate a specific potential path at the time of advertisement. In this generic case, MELGs don’t help.

Please see more in-line below.

[VPB] I think the disconnect between us has got to do with how the Virtual TE (VTE) Link gets advertised. Say, that there are 3 potential paths in the server layer that can cater to a given VTE link. In our notion of the "Virtual TE Link", at the time of advertising there already exists an association between the VTE link and one of these 3 paths. Without associating your VTE link with a specific server-path, you wouldn't be able to accurately advertise attributes like diversity, delay, mutual-exclusivity etc. If I understood your question correctly, your notion of how the Virtual TE Link gets advertised seems to be different - you don't associate the VTE link to a specific potential path at the time of advertisement.

[Fatai] Right. The VTE link does not associate a specific potential path at the time of advertisement, it is a kind of potentiality for the VTE advertised as defined in RFC6001. In this case, path computation element (e.g, centralized PCE for inter-layer) can be aware of the link information, including link bandwidth, SRLG…..

Continuing with your example - If the path that gets associated with VTE-Link-1 and the path that gets associated with VTE-Link-2 depend on the same resource, "MELGs" would make sure that the client computation function is aware of the existence of such "mutual exclusivity" relationship.

[Fatai] The path computation element (centralized PCE for inter-layer or multiple PCEs through communication) can take care of this issue to avoid this happen without MELG introduced.

BR,
-Pavan

Best Regards

Fatai

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan

Khuzema, Hi!

Hope this helps.
-Pavan

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

For multi-layer (more than 2) network, consider all the layers are meshy (that’s when virtual links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a virtual link can take will change. Mapping lower layer MELGs to higher layer MELGs won’t be practical if done in distributed manner, so it has to be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which can be utilized for layer specific path computation (as it is doing it anyway).

You seem to be doing something that you don’t like ☺

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

 1.       When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will be talking to its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource exclusivity of virtual link for immediate server layer i.e. OTN layer.  However if there is resource exclusivity at DWDM layer, this mechanism doesn’t work. You need to do loose routing or use distributed PCE model

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting [X] +49 711 821 43125 FREE  end_of_the_skype_highlighting begin_of_the_skype_highlighting 错误！未指定文件名。+49 711 821 43125 begin_of_the_skype_highlighting [X] +49 711 821 43125 FREE  end_of_the_skype_highlighting FREE  begin_of_the_skype_highlighting 错误！未指定文件名。+49 711 821 43125 FREE  <tel:%2B49%20711%20821%2043125>
Mobil: +49 175 7266874 begin_of_the_skype_highlighting [X] +49 175 7266874 FREE  end_of_the_skype_highlighting begin_of_the_skype_highlighting 错误！未指定文件名。+49 175 7266874 begin_of_the_skype_highlighting [X] +49 175 7266874 FREE  end_of_the_skype_highlighting FREE  begin_of_the_skype_highlighting 错误！未指定文件名。+49 175 7266874 FREE  <tel:%2B49%20175%207266874>
[email-masked]<mailto:[email-masked]>

---

From: Fatai Zhang <[email-masked]>
Date: Sat, 20 Apr 2013 01:14:20 +0000

Hi Igor,

I have explained to Pavan.

The path computation element (centralized PCE for inter-layer or multiple PCEs through communication) can take care of this issue.

In addition, in this case, how you advertise MELGS for this two VT links?  Will you advertise that VL 1 must be exclusive with VL2? That is wrong, because VL1 and VL2 can be used for the disjoint paths in the client layer.

Best Regards

Fatai

From: Igor Bryskin [mailto:[email-masked]]
Sent: Friday, April 19, 2013 8:22 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller
Cc: [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Fatai,

Cheers,
Igor

Hi Pavan, Igor

Best Regards

Fatai

Khuzema, Hi!

Hope this helps.
-Pavan

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 22 Apr 2013 13:34:22 +0000

Hi Fatai,
Please, see my comments in line.

Cheers,
Igor

From: Fatai Zhang [mailto:[email-masked]]
Sent: Friday, April 19, 2013 9:10 PM
To: Vishnu Pavan Beeram
Cc: Khuzema Pithewan; Igor Bryskin; Dieter Beller; [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Hi Pavan,

IB>> We’ve never said that our work is limited to what is defined or prescribed by RFC6001. In particular, according to our VL story, when a VL is advertised, this is about much more than advertising “a kind of potentiality”. Not only a potential path in the server layer is selected and pinned (at least as far as the link fate sharing is concerned), a state is created at every server layer link the selected path is going through. The said state allows for sharing the link resource among VLs, but makes resource unavailable for anything else and prevents the resource from being de-provisioned. In our opinion, this is the only way to prevent the following situations to happen after the VL is advertised:

a)      Some LSP, unrelated to VL, allocates and starts using the resource the VL depends upon;

b)      The operator (consciously or otherwise) de-provisions the resource.
Besides, how else one can advertise the VL’s SRLGs, if one has no clue as to what server layer path the VL will end up taking when is committed?

IB>> IMO inter-layer path computation is one of those things people talk for many years (7+ ?), but which never sees any production network deployment for a simple reason: it is only good for a carefully orchestrated demo, but is not good enough to solve any real network problem. One big problem with the inter-layer path computation is that it implies *re-defining client layer topology during a client layer path computation, i.e. based on a single path computation request*. A real life analogy of this paradigm would be something like this. Imagine, Fatai, you arrive to the Beijing airport and say: “I need to fly to Washington DC”, and you hear back: “Mr. Zhang, All flights to Washington are booked, however, I can see that we have a spare plane available, so I’ve just created for you a flight AirChina XYZ which will go non-stop to Washington. We will start boarding shortly. Hopefully other several hundred passengers  will  show up. If not, don’t worry, we will fly you alone. Thank you for choosing Air China”. As you know, things do not work this way: Air China pre-plans its flights very carefully, based on far more data than Mr.Zhang’s request and in a different time frame (long before it starts flying people). This pre-planning may prove, for example, that instead of creating a non-stop flight to Washington, it is better economics-wise to create two flights: Beijing-London and London-Washington. In the context of this analogy, VLs are flights that do not have committed planes, instead, there is a pool of planes that is shared between a group of flights. In all other respects the “virtual” flights are no different from the “real” flights, in particular, they are subject for the same tedious planning process, hence it is better to use these virtual flights than to create flights on the fly :=)

Igor

BR,
-Pavan

Best Regards

Fatai

Khuzema, Hi!

Hope this helps.
-Pavan

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125 begin_of_the_skype_highlighting [Image removed by sender.] +49 711 821 43125 FREE  end_of_the_skype_highlighting begin_of_the_skype_highlighting 错误！未指定文件名。+49 711 821 43125 begin_of_the_skype_highlighting [Image removed by sender.] +49 711 821 43125 FREE  end_of_the_skype_highlighting FREE  begin_of_the_skype_highlighting 错误！未指定文件名。+49 711 821 43125 FREE  <tel:%2B49%20711%20821%2043125>
Mobil: +49 175 7266874 begin_of_the_skype_highlighting [Image removed by sender.] +49 175 7266874 FREE  end_of_the_skype_highlighting begin_of_the_skype_highlighting 错误！未指定文件名。+49 175 7266874 begin_of_the_skype_highlighting [Image removed by sender.] +49 175 7266874 FREE  end_of_the_skype_highlighting FREE  begin_of_the_skype_highlighting 错误！未指定文件名。+49 175 7266874 FREE  <tel:%2B49%20175%207266874>
[email-masked]<mailto:[email-masked]>

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 22 Apr 2013 13:58:29 +0000

Fatai and Khuzema,

In my opinion you confuse two cases:

Case 1. Two virtual links are served by WDM layer. The potential paths supporting each VL are terminated on the same transponder, hence the two VLs are mutually exclusive. Note that this mutual exclusivity relationship is static: it is true at all times and does not depend on anything else (e.g. it does not depend on # of available wavelengths on WDM links the transponder could be connected to). This is the case of MELGs and is focus of our MELG draft;

Case 2. Two virtual links are served by WDM layer. The potential paths supporting each VL use a common WDM link that has only one wavelength available at the moment, hence the two VLs are mutually exclusive. Note that this mutual exclusivity is dynamic: as soon as an additional wavelength becomes available on the common WDM link, the two VLs will be able to be committed at the same time. This is not the MELG case. We discussed this dynamic mutual exclusivity (Cyril was the first, I believe, to bring this up) and have decided to keep this case out of scope of the MELG draft. Note, that there is a simple solution for this case based on the VL model, which we will solve in a separate draft. This solution does not include the inter-layer path computation: the whole point of the VLs is to alleviate the clients from dealing with the server layer traffic engineering and path computations.

Cheers,
Igor

From: Fatai Zhang [mailto:[email-masked]]
Sent: Friday, April 19, 2013 9:14 PM
To: Igor Bryskin; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller
Cc: [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Hi Igor,

Best Regards

Fatai

Fatai,

Cheers,
Igor

Hi Pavan, Igor

Best Regards

Fatai

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] MELGs - Q&A

Khuzema, Hi!

Hope this helps.
-Pavan

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Khuzema Pithewan <[email-masked]>
Date: Mon, 22 Apr 2013 18:16:09 +0000

Hi Igor,

Indeed you are solving the problem described in the case 1 and probably the only case MELG is trying to solve, However MELG draft read gives an impression that you are trying to solve far more generic issue of mutual exclusivity of virtual links w.r.t. resources in server layer  and this seems farfetched and hence confusion and discussion.

It might be apt to capture this usecase in draft in such a way that, it actually solves only this case.

Thanks
Khuzema

From: Igor Bryskin [mailto:[email-masked]]
Sent: Monday, April 22, 2013 7:28 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller
Cc: [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Fatai and Khuzema,

Cheers,
Igor

Hi Igor,

Best Regards

Fatai

Fatai,

Cheers,
Igor

Hi Pavan, Igor

Best Regards

Fatai

Khuzema, Hi!

Hope this helps.
-Pavan

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 22 Apr 2013 19:28:37 +0000

Khuzema,

I agree that we need to define the problem more clearly, in particular, to separate from the case #2.
I promise we will provide a solution for case # 2 as well.

Thanks,
Igor

From: Khuzema Pithewan [mailto:[email-masked]]
Sent: Monday, April 22, 2013 2:16 PM
To: Igor Bryskin; Fatai Zhang; Vishnu Pavan Beeram; Dieter Beller
Cc: [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Hi Igor,

Thanks
Khuzema

Fatai and Khuzema,

Cheers,
Igor

Hi Igor,

Best Regards

Fatai

Fatai,

Cheers,
Igor

Hi Pavan, Igor

Best Regards

Fatai

Khuzema, Hi!

Hope this helps.
-Pavan

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 23 Apr 2013 01:03:35 +0000

Hi Igor,

It is OK to have different drafts(solutions) for different cases of VT, but it is better to find a generic solution for all the cases of VT.

Best Regards

Fatai

From: Igor Bryskin [mailto:[email-masked]]
Sent: Tuesday, April 23, 2013 3:29 AM
To: Khuzema Pithewan; Fatai Zhang; Vishnu Pavan Beeram; Dieter Beller
Cc: [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Khuzema,

Thanks,
Igor

Hi Igor,

Thanks
Khuzema

Fatai and Khuzema,

Cheers,
Igor

Hi Igor,

Best Regards

Fatai

Fatai,

Cheers,
Igor

Hi Pavan, Igor

Best Regards

Fatai

Khuzema, Hi!

Hope this helps.
-Pavan

MELG is useful when

Regds
Khuzema

Khuzema,
Please, see in-line.

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regds
Khuzema

Khuzema,

Igor

Hi Igor,

Regards
Khuzema

Khuzema,

Cheers,
Igor

Hi Igor,

Is that correct?

Khuzema

Khuzema,

Cheers,
Igor

Khuzema, Hi!

Please see inline..

Regards,
-Pavan

Dieter,

6.      Etc.

Also think about this:

Cheers,
Igor

Hi Pavan,

Thanks,
Dieter

Best Regards

Fatai

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany