Subject: Re: Draft Minutes from Pittsburgh

From: Kireeti Kompella <[email-masked]>
Date: Tue, 17 Oct 2000 10:44:15 -0700 (PDT)

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.

---

From: Bala Rajagopalan <[email-masked]>
Date: Tue, 17 Oct 2000 14:39:36 -0400

Kireeti:

> understandably biased (apart from one comment from Curtis

I welcome participation from others too. I'd especially like to hear from
those with an optical network perspective.

> have a chat with service providers that have implemented MPLS/TE.

Let me first say that I have had the previlege of reading RFC 2702.
Presently, routing schemes being designed for optical
transport networks are essentially proprietary in the manner
in which paths are computed. This includes whether and how
metrics and other parameters (per 2702) are assigned for links.
I'm interested in knowing if
 you have chatted with any service provider who
wants to support all the MPLS/TE capabilities as per 2702
in optical transport networks. Because, I haven't heard any such
requirement. In any case, you can always form link groups
based on metrics or any other tag.

> optimization; however, since multiple bundles are needed anyway, this

You're indeed getting repetetious here.

> boxes of the same opinion?  It would be good to hear from them.

I think the issue is of relevance to other vendors in our space. Right
now, I can only speak for ourselves. At this point, I don't know
how many people  (especially with optical orientation)
have read your drafts and endorse them whole-heartedly.
It'd be good hear from those too.

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: [email-masked]

---

From: Jim Boyle <[email-masked]>
Date: Fri, 20 Oct 2000 20:52:43 -0600 (MDT)

sorry if this is a restatement of something substantial in one of the 120
message in this group after this one(!!).

I find no reason why the IGPs and interfaces between telecommunications
gear should remain closed and proprietary.

On safer ground, and I'm sure most of your customers would agree, use of
priorities in signalling and routing will be very useful in providing
services and achieving different levels of protected services.

On technical merits of the two approaches, I believe I've already posted
my thoughts.

regards,

Jim