The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Bora,

> And that object was based on my now expired draft in
> draft-akyol-mpls-expanded-ero-00.txt

I'm not sure what you mean by "that object"; the only reference to
an object in David's mail is

> The unnumbered draft defines a new ERO subobject, which will allow for
> this kind of specification.

The unnumbered draft (and the ERO subobject for specifying unnumbered
links) *preceded* your expired draft; what's your basis for claiming
that the ERO subobject is based on your draft?

Kireeti.

------------ Original Mail --------------

Date: Fri, 26 Oct 2001 09:46:01 -0700
From: Bora Akyol <bora@cisco.com>
To: David Charlap <David.Charlap@marconi.com>
CC: mpls@uu.net
Subject: Re: Questions on unnumbered links

Yes

And that object was based on my now expired draft in
draft-akyol-mpls-expanded-ero-00.txt

I guess as people get around to implementing this stuff, they realize that

they need more information. This is what happens when you first write the
draft and then write the code.

Additionally, there is quiet a few "implementation" decisions that you
make as you write the CSPF and traffic engineering database code as well.
Sounds like fun, it sure is.



Bora


David Charlap wrote:

> Eric Gray wrote:
> >
> > Maybe I missed something: I thought support for unnumbered links
> > needed to be added for GMPLS because there are problems with these
> > links in the general case.  I was not aware that there are problems
> > with unnumbered links in the Ethernet, PPP, ATM and Frame Relay
> > cases or in basic signaling of MPLS explicit routes.
> >
> > What exactly are the problems with using unnumbered links in the
> > specific cases defined for MPLS?
>
> Without extensions, an ERO can not specify which of several parallel
> unnumbered links should be used for an LSP.
>
> The unnumbered draft defines a new ERO subobject, which will allow for
> this kind of specification.
>
> But without thit unnumbered-link extensions in the IGP's topology, the
> information necessary to compute an ERO using this subobject is not
> present.
>
> -- David