Re: [CCAMP] MELGs - Q&A

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

Fatai, Hi!

Thanks for keeping the conversation going.
Response inline.

Snipped>>

> 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****
>
> ** **
>
> [Fatai] I don’t understand your definition of MELG(ie., MELGs are used to
> advertise “mutual exclusivity” information).  If we name it as XXLG, we can
> define XXLG similarly in your style: XXLGs are used to advertise “XX”
> informaiton.  My real question is: Why is there “mutual exclusivity”?
>   What is the essence of “mutual exclusivity”?
>

You seem to have missed reading the first couple of questions (in the FAQs)
that I sent out. The answers to those 2 questions should answer why "mutual
exclusivity" exists among the advertised topological constructs and why
 there is a need to advertise this additional information. I'm pasting
those 2 answers here for your benefit.

----
 *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 (centralized)
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.*
----

Please do let us know if the above answers your questions. The 2 things
that you might want to think about  (to understand the need for MELGs) are
- "Network Domain Abstraction" and "Centralized Concurrent Path
Computation".

You are free to define "XXLG" (or any thing of that sort) as long as there
is a valid use-case. Our claim here is that "MELG" serves a valid use-case
(as explained in the draft and in the FAQs that I sent out). Please let us
know what part of this use-case doesn't sound "valid" enough for you.

Regards,
-Pavan