Re: [CCAMP] MELGs - Q&A

[John E Drake <[e-mail]>]

Khuzema,

Comments inline.

Irrespectively Yours,

John

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

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.

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.

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.

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

Regds
Khuzema




From: Igor Bryskin [mailto:[e-mail]]
Sent: Tuesday, April 16, 2013 7:50 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
Subject: RE: [CCAMP] MELGs - Q&A

Khuzema,
Please, see in line.

From: Khuzema Pithewan [mailto:[e-mail]]
Sent: Tuesday, April 16, 2013 7:08 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
Subject: RE: [CCAMP] MELGs - Q&A

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

From: Igor Bryskin [mailto:[e-mail]]
Sent: Monday, April 15, 2013 9:44 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
Subject: RE: [CCAMP] MELGs - Q&A

Khuzema,
Please, see in-line.

Igor

From: Khuzema Pithewan [mailto:[e-mail]]
Sent: Monday, April 15, 2013 12:05 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Friday, April 12, 2013 11:55 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Friday, April 12, 2013 1:01 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Friday, April 12, 2013 9:52 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Friday, April 12, 2013 12:06 PM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
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 :)

Regards
Khuzema

From: Igor Bryskin [mailto:[e-mail]]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
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

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

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram

Cc: [e-mail]<mailto:[e-mail]>
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] MELGs - Q&A

Hi Pavan,
On 25.03.2013 07<tel:25.03.2013%2007>: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:[e-mail]]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; [e-mail]<mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

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: [phone]<tel:%2B49%20711%20821%2043125>
Mobil: [phone]<tel:%2B49%20175%207266874>
[e-mail]<mailto:[e-mail]>

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