[CCAMP] MELGs - Q&A

[Vishnu Pavan Beeram <[e-mail]>]

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


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


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