The MPLS WG Archive

[Bala Rajagopalan <braja@tellium.com>]

Hello,

I'm glad we're getting into some substantive debate on this.
Sorry if there is any repetetion below.


Yakov Rekhter wrote:

> Bala,
>
>
> draft-kompella-mpls-bundle does *not* require multiple adjacencies.
> With draft-kompella-mpls-bundle one *may* create multiple adjacencies
> if one doesn't want to aggregate information about SRLGs and/or
> administrative constraints (affinities), or different TE metric.

I submit that you have to create multiple adjacencies if you want
to bundle according to link type, SRLGs etc. If you're saying that
you can ignore these and create a single bundle, I'm afraid you're
completely ignoring our needs.

>
>
> Your proposal does *not* guarantees only a single adjacency, as if
> different component links have different administrative constraints
> (affinities) and/or different TE metric, and aggregation of the
> administrative constraints is undesirable, then with your proposal one
> would have to have multiple adjacencies.

Or multiple link groups within a bundle, thus maintaining a single
adjacency.

>
>
>
> In one sentence, because draft-kompella- can do everything that your
> proposal can do and more. On the other hand, your proposal can do only
> a subset of what draft-kompella- can do.

If the first sentence is really the case, we'd be glad to go with your
proposal. But I'm not convinced this is true.

>
>
> For more details see below:
>
> 1. Your proposal doesn't have the needed information.
>    For example, it doesn't have Max LSP b/w per priority.  Another
>    example, your proposal doesn't say how signalling could pick up a
>    component link within a particular link group.

I agree. The priority feature hasn't been a priority for us so far. But
this is just a matter of adding a field in link groups (our need will
be to distinguish between working and "extra" traffic only, not
a range of priorities). Anyway, this doesn't argue against
having link groups. As far signaling, yes, the draft omits to mention that
the ERO must carry the advertised link group id for each hop.

>
>
> 2. Your proposal introduces duplication information (information
>    already present elsewhere, like Link Encoding Type, min reservable b/w,
>    max reservable b/w (already present in draft-isis-gmpls-extensions-00.txt)

I don't understand this point. Link encoding has  been defined elsewhere
(source referenced), and max and min are also described  by the encoding type
(i.e., values such as oc-48, etc) in our draft. Anyway, we're defining the
usage of these parameters in bundling.


>
>
> 3. Your proposal results in flooding of information that doesn't change
>    (as when change occurs within just one link group, the whole bundled
>    link that includes all the link groups is flooded), thus creating
>    (for no good reasons) an additional load on the routing system.

As we note, the frequency of flooding doesn't change, whether you
bundle a link group as a separate bundle or include it as part of a
larger bundle. The size of announced information increases, but
it doesn't seem to be a practical concern with optical link types
(which are few).

>
>
> 4. Your proposal doesn't eliminate the need to implement reducing
>    flooding (via flood optimization), as we need to allow for
>    multiple bundled links between a pair of LSRs.

If you do maintain multiple bundles (by not capturing all the information
in link groups), yes, flooding must be reduced. But you don't have to
have multiple bundles.

>
>
> 5. Your proposal doesn't support bundling of non-optical links.

This may be the case for some features, but our draft's
title is indeed  "Link bundling in optical networks".

In the end, I see the real need from our part as the ability to
be more detailed in SRLG specification, plus a grouping of links
according to link types within a bundle. If your bundling proposal can
include these features, we'd be happy to endorse it.

Regards,

Bala


>
>
> Yakov.

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com