Re: [CCAMP] MELGs - Q&A

[Dieter Beller <[e-mail]>]

Hi Pavan,

thanks for providing more explanations re the MELG draft.

Please find my comments in-line below.


Thanks,
Dieter

On 14.03.2013 04:27, Vishnu Pavan Beeram wrote:

Folks, Hi!

There were some questions about the use of MELGs this morning after my presentation (Much Thanks to the folks who voiced them out). The questions were mostly on the need for defining this new construct. The following text is an attempt to answer these questions. Please do read this through and let me know if there are any further queries.

Regards,

-Pavan


1. Why do mutually exclusive abstract/virtual TE links exist?

When a server network domain gets abstracted and advertised into the client network domain, the virtual TE links that get created can end up being mutually exclusive. The assumption is that this abstraction is done based on the output of some extensive planning activity.

It is pretty clear that this virtual topology needs to be created by the operator based on
conscious decisions where to place them, i.e., between which potential link end points.

Since uncommitted resources are involved, it is perfectly alright to plan the abstraction in such a way that only a subset of the virtual TE links get used at any given point of time. If multiple virtual TE links depend on the usage of the same uncommitted network resource, only one of them can get instantiated at any given point of time - And this makes them mutually exclusive.

clear

2. Why is there a need to advertise this "mutual exclusivity" information?

The abstract/virtual TE links are advertised into a client network domain and exist in the client TEDB.

I would rather use the term client layer network instead of client network domain as we are
in a multi-layer environment and the client layer network is probably in most cases belonging
to the same operator domain.

For a Client Network Domain path computation function that does concurrent computations (of multiple paths), it is important to know the existence of the mutually exclusive relationship between Virtual TE Links. Absent this information, there exists the risk of yielding erroneous concurrent path computation results where only a subset of the computed paths can get successfully provisioned. The MELG-ID construct is being introduced to advertise this "missing" piece of information.

I think you mentioned the use case for which the mutual exclusiveness of virtual links could be
important, i.e., you have a single path computation instance that is capable to concurrently
calculate n paths in one shot. As soon as you calculate the paths sequentially, the problem goes
away because as soon as the virtual link is used by one path, it is no longer available for other
paths.

Moreover, if you are doing path computation in a distributed fashion and you run into the situation
that two path computation functions are selecting the same virtual TE-link when they calculate
backup paths for failed connections that need to be restored, this conflict can only be resolved
when the backup paths are being setup (first come first serve, crank-back for the 2nd followed
by the calculation of a new backup path excluding the already occupied virtual TE-link). Hence,
MELGs are not needed in this scenario. The problem does also no longer exist as soon as the
the TEDBs are updated in response to the allocation of the virtual link by an LSP.

4. How is MELG different from SRLG?

Each construct addresses a separate problem. SRLGs are used to advertise “fate-sharing” information. MELGs are used to advertise “mutual exclusivity” information. 

It is possible for TE-links that have a common SRLG to be instantiated/used at the same time. It is not possible for TE-links that have a common MELG to be instantiated/used at the same time - only one of them can be used at any given point of time

5. Are there any scaling implications for MELGs?

The number of MELG-IDs advertised per TE-link depends on how the abstraction process is carried out. If at all this is (or would become) a concern, adequate policies can be imposed on the abstraction process to limit the creation of too many mutually exclusive Virtual links.

The question regarding scalability is certainly: how much additional information is needed in case
the MELG concept would be applied to virtial TE links.

_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp" rel="nofollow">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]
Mobil: [phone]

[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

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