The MPLS WG Archive

[neil.2.harrison@bt.com]

GMPLS suffers the same fate......so just why should an OTN that is
user-plane transparent, CO and has to carry multiple clients be best served
by a control-plane developed for a CNLS transfer mode?  The arguments 'for'
don't hold on analysis, and the lack of comparative analysis (to get best of
breed) has not be done.  For example, how on earth can anyone justifiably
and honestly say that RSVP as-is and a 32 bit address (ie unacceptably too
small) are the 'right' answers for an OTN?

Observation....we 3 are operators.....maybe that explains our
concerns/views?

neil

> -----Original Message-----
> From:	Ben Black [SMTP:ben@layer8.net]
> Sent:	Monday, December 18, 2000 2:24 AM
> To:	Juha Heinanen
> Cc:	mpls@UU.NET
> Subject:	Re: Concerns regarding the numerous layer violations in base
> MPLS drafts
> 
> I've noticed that response quite a few times.  I wonder if, in this
> case, all the IP bits are in there to maintain a connection to the
> mission of the IETF, since a truly protocol-independent spec would
> fall outside of its domain.
> 
> 
> Ben
> 
> On Mon, Dec 18, 2000 at 03:17:26AM +0200, Juha Heinanen wrote:
> > ben,
> > 
> > i pointed out a long time ago that the encap i-d is full of wrong
> > assupmtions and statements regarding what is carried in the mpls
> > packets, but i was asked to shut up in order to not to delay its
> > publication as an rfc.
> > 
> > -- juha
> >