The MPLS WG Archive

[Bala Rajagopalan <braja@tellium.com>]

Hello,



Kireeti Kompella wrote:

> Let's take this in two steps: draft-kompella- does not *require*
> multiple adjacencies.  It's a choice the user makes.  If they want
> a single bundle with mixed link types and SRLGs, they can.  Otherwise
> they can create a bundle for each link type and SRLG set.

If you read our draft carefully, the requirement is NOT to mix link types
and SRLG information.  I don't want to create multiple bundles
(and hence adjacencies) doing this. The bottom line is,  your
proposal does not support this. The only way to do this under your
proposal is to necessarily create multiple bundles, and then incur
the added complexity of flooding opt. This is the point I'm trying
to communicate.

>
>
> With your proposal:
> 1) a user *must* have multiple link groups, even if they don't care
>    about separate link types or SRLGs.
> 2) if a single link group changes, the entire bundle must be
>    readvertised.  This is as bad as flooding all the multiple bundles.
>    However, the design of link groups offers no scope for optimization
>    analogous to flooding optimization.

Our proposal addresses specific requirements as outlined in the
draft. So, your point (1) is of no relevance. Furthermore, (2) is
a weak point. Advertising an entire bundle vs just a link group
that's bundled separately doesn't change the frequency, but the
size of LSAs.  And, the whole idea is that I don't want to
implement an OSPF flooding opt. just to support bundling.

>
>
>
> >
> > Or multiple link groups within a bundle, thus maintaining a single
> > adjacency.
>
> You missed Yakov's point: if ports 1-10 have metric 12, ports 11-20
> have metric 15, ports 21-30 have metric 18, you need three bundles.
> These cannot be link groups within a bundle, as link groups share the
> metric of the bundle.  Same with affinities.

You're generalizing too much here, beyond our requirements. In any case, if
such metrics are needed, then link groups can be formed based on the
metric.

>
>
>
>
> However, in all of the following, the only thing that you say that
> your draft has that ours doesn't is:
>
> > 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.

But this is the point of our draft!

>
>
> There is nothing in draft-kompella- that precludes bundling just
> the links that share SRLG sets or link types or whatever.  So, this
> draft is clearly a superset of draft-rs-.  The only (non)issue is
> flooding.

At the risk of being repetetious, we're not denying that you could
bundle based on any criterion using draft-kompella. All we're saying is
that we don't want to create  multiple adjacencies doing this. It's a
simple matter of adding link groups to your bundling proposal and
we'll be happy.

>

>
>
> On the other hand, draft-rs- introduces a new mechanism that adds no
> value, has the downside that the flooded information is potentially
> much greater (without recourse to optimization), and in the end does
> not remove the need for multiple parallel bundles between a pair of
> LSRs (OXCs).

draft-rs addresses a specific set of requirements. Whether that adds
"value" is subjective, depending on what the application is. To us, your
draft (+ flooding opt, multiple unnumbered link support)
doesn't give the value for the amount of work involved in implementing
it in the specific environment we're interested in. Your last statement about
multiple bundles is not true at all in the environment described in our
draft.

>
>
> Furthermore, draft-rs- is specific to optical links, whereas
> draft-kompella- is more general purpose; and while this may be your
> stated goal, a more general solution is clearly preferable to a more
> specific one.

Preferrable to who? A solution that addresses the problem in
our specific environment in a circuitous way is not very exciting
for us, just because it addresses bundling in the genereal MPLS
environment also. The essential idea of our draft is to describe
the specific requirements in optical networks. In fact, some of
the requirements you have incorporated in your draft are not
important to us, and the way bandwidth is described in your
proposal is not natural for our application. We're willing to
put up with all this if you can add link groups as a feature.
I think this is a reasonable compromise.


regards,
--

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