The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Hi Bala,

As the mail is getting repetitious, I will address only a few points.

I would invite others to participate; so far, the argument has gone
back and forth between the authors of the drafts, who are
understandably biased (apart from one comment from Curtis

| > 1. draft-kompella-mpls-bundling-02.txt  for bundling description
| > 2. draft-zinin-flood-opt-00.txt for ospf flooding optimization when
| > there are multiple bundles between the same pair of nodes.
| > 3. draft-kompella-mpls-unnum-01.txt for specifying component
| > links in ERO
| 
| IMHO 2 is not required therefore your more complex bundling scheme
| adds litte or no value.

apropos link groups (if you want the full mail, I'll post it), and a
general statement of support from John Drake).

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

Perhaps you should read RFC 2702.  TE metrics and affinities are a
big part of MPLS/TE; if they are beyond your requirements, you should
have a chat with service providers that have implemented MPLS/TE.

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

You're sidestepping the issue.  The point is that "link groups" don't
add value.  At best, they appear to remove the need for flood
optimization; however, since multiple bundles are needed anyway, this
is a false notion.

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

Does your "specific environment" include other boxes from other
vendors that you would interoperate with?  Are the vendors of these
boxes of the same opinion?  It would be good to hear from them.

Kireeti.