Re: [CCAMP] MELGs - Q&A

[Fatai Zhang <[e-mail]>]

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:[e-mail]]
Sent: Friday, April 19, 2013 8:22 PM
To: Fatai Zhang; Vishnu Pavan Beeram; Khuzema Pithewan; Dieter Beller
Cc: [e-mail]
Subject: RE: [CCAMP] MELGs - Q&A

Fatai,

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?

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:[e-mail]]
Sent: Thursday, April 18, 2013 11:26 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan; Igor Bryskin; Dieter Beller
Cc: [e-mail]
Subject: RE: [CCAMP] MELGs - Q&A

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: [e-mail] [mailto:[e-mail]] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, April 16, 2013 10:10 PM
To: Khuzema Pithewan
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<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]<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] begin_of_the_skype_highlighting [Image removed by sender.] [phone] FREE  end_of_the_skype_highlighting<tel:%2B49%20711%20821%2043125>
Mobil: [phone] begin_of_the_skype_highlighting [Image removed by sender.] [phone] FREE  end_of_the_skype_highlighting<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