RE: LMP fraud

[Bala Rajagopalan <BRaja@tellium.com>]

hello,

At the risk of sounding like the pope (or an IETF AD),
I would like to point out that it would indeed help if
the LMP contributors were to clarify the usage of the protocol
and understand the issues that are being raised. Perhaps
some are too busy. But it's quite likely that there are others 
currently just waiting for the downturn to end, and 
thus have some time to spare :-(. (BTW, this is also
a crushing argument against the RFC editor's whimsical
notion of "not more than 5 authors" criterion. More the
authors, more the likelihood that there is someone with time
to explain things to the 
 - uninformed (those that read a given draft and don't 
   understand the gobbledigook), 
 - the misguided (those that read the draft and figure out it 
   doesn't do much for them),  or 
 - the intelligent (those that ignore the draft)).

Having thus interested you in this message, I would like to first
acknowledge that Greg raised some valid points, i.e., the applicability
of all the prodedures in the rather rich document to SONET/SDH,
the notion of discovery vs IP forwarding over control channels,
whether simpler procedures might be possible for SONET/SDH, etc.
To which Dimitri had some excellent suggestions, one of which
is to  consider a technology specific draft. This issue of LMP
vs SONET, btw, is not new. It has been raised before, but we 
have failed to address it head on. Rather, we have proposed
plucking a procedure from here, one from there, and create
a hodge-podge (as in OIF UNI neighbor discovery). The fact
is, an influential community of potential users of this protocol
are not satisfied, and the G.7714 work is a result of that.
As a contributor, I would like to be constructive about
all this, and see how to progress LMP on the standards track
while addressing the concerns raised in a clean way. On the other
hand, I think it's regrettable the term
"LMP Fraud" has been used by Michiel to describe the perceived 
shortcomings. Predictably, it has provoked a bad
reaction. 

(As for implementations, could anyone post some information
about who has implemented
what parts of LMP so that we can get an idea of the entrenchment
of the current version of the protocol spec?)

Regards,

Bala

P.S: If you have read up to this point, you're really not busy :-).



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 

> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Wednesday, August 07, 2002 12:48 PM
> To: Bernstein, Greg
> Cc: Michiel van Everdingen; Dimitri.Papadimitriou@alcatel.be;
> ccamp@ops.ietf.org
> Subject: Re: LMP fraud 
> 
> 
> Greg
> 
> > Hmm, interesting attitude Yakov.  However, it seems that 
> when two very
> > disparate world such as optical transport and IP routing attempt to
> > synergize that a bit more preciseness in terminology and 
> assumptions.
> > 
> > Why are you so concerned with LMP?  The SONET/SDH 
> interfaces on your routers
> > provide just about all this functionality and more.  
> > 
> > For example for fault localization the SONET/SDH framer and 
> packet mapping
> > chips on your router most likely supports section, line and path AIS
> > (downstream alarm indication signal) and line and path RDI 
> (sent upstream to
> > indicate remote defect indication).  All without software 
> intervention in
> > less than a mili-second time frame. That's why these are 
> used to trigger
> > protection/restoration action.
> > 
> > These same chips also will provide for end to end path, 
> nearest line,
> > nearest section performance monitoring in terms of fairly 
> exact bit error
> > rate numbers.
> > 
> > Finally these chips also will allows the insertion of trail 
> trace identifier
> > strings via (J0, J1, or J2) that with proper use can be 
> used for automated
> > discovery.  Or provide for section, line, or path overhead 
> communication
> > channels that could also be used for discovery.
> > 
> > Hence why would one ever want to use LMP between two pieces 
> of equipment
> > utilizing SONET/SDH interfaces?  LMP was aimed a particular type of
> > transparent OXC that chose not to implement any of the 
> above functionality.
> > I'm not sure why the rest of us should be burdened with 
> supporting LMP.
> > Maybe in fact the confusion is over the state of the art in 
> transport
> > network technology and standards, of which, a group such as 
> CCAMP, if it is
> > to venture into this area, should be much more aware.
> 
> I have no time/desire to explain to you why I think LMP is useful.
> If you think that you don't need to implement LMP, then don't
> implement it. The choice is yours. If other folks think that LMP
> adds value to their products, then they would implement it.
> 
> Yakov.
>