The MPLS WG Archive

[Jim Boyle <jboyle@Level3.net>]

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


On Tue, 17 Oct 2000, Bala Rajagopalan wrote:

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