Re: [CCAMP] MELGs - Q&A

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

Dieter, Hi!

Thanks for your response. Glad to see that you understand the fundamental
concept now.
Responses inline (prefixed with [VPB])


Snipped..

* 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.
>
>
[VPB] Your points about the "path computation aspects" are fairly obvious
points - there is no dispute there. The context of interest (in case you
are still missing it) here is a centralized path computation function that
is capable of doing concurrent computations. And this computation function
operates on a Client TED that includes some mutually exclusive abstract
links (note that there could be multiple levels of abstraction). All that
this draft is trying to do is provide a means for this centralized
computation function to concurrently compute multiple paths that have a
high probability of being successfully provisioned.


Snipped..

>
> * 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.
>
>
[VPB]  I don't really think there is any valid scaling argument to be made
against "MELGs". All that you would need to advertise the "mutual
exclusivity" information is included in the "construct" that is defined in
the draft. There is NO additional information that you would need to
advertise to make use of MELGs. Please do read through the draft (if you
haven't already) when you get a chance.

And please do let me know if you have any further concerns about MELGs.

Regards,
-Pavan