The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Oct> msg00189



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Draft Minutes from Pittsburgh

  • From: Bala Rajagopalan <braja@tellium.com>
  • Date: Tue, 17 Oct 2000 14:39:36 -0400
  • CC: mpls@UU.NET

Kireeti:

Kireeti Kompella wrote:

> Hi Bala,
>
> 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

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

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

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.

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

You're indeed getting repetetious here.

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

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: braja@tellium.com