The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Hi Bala,

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

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 the user decides to create multiple bundles, they may choose to do
flooding optimization also.  This is recommended, not required.  In
fact, depending on how you implement bundling and control channels,
flood optimization might not even be necessary.

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.

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

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.

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

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.

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.

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

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.

Kireeti.