Re: LMP fraud

[Dimitri.Papadimitriou@alcatel.be]

there are several points that must be clarified because 
we are entering into some dead-lock in the discussion 
here (just be aware that this "hmm" is really question-
able since nobody know what it really means):

1) LMP does not intend to replace functions already 
provided by the transport plane (for instance, AIS/RDI 
for sdh FDI/BDI for oth) when available however, it
helps in providing the needed mechanisms in order to 
enable the gmpls control plane to have the "usable" 
information for subsequent gmpls operations (or any
other ip based signalling protocol suite by the way) 

note that (this is clear in your e-mail) tti string
insertion "will" allow discovery meaning that since
so far available methods were running outside of the
scope of a non-associated distributed control plane
(or at least in a standardized way) and as such the 
merits of LMP is to have open the door for (ip-based) 
"protocol" mechanism allowing automated processing 
of operations that were also previously under "non-
real time" control 

2) LMP does not mandate to use (or implement, see
the distinction) all the proposed functions for any 
transport technology (i see for instance the use of 
LMP in environments such as gigabit ethernet) and 
as such it fits very well within the "Common" CAMP 
WG effort, suggesting that these protocol mechanisms 
must keep a common foundation (a per technology i-d
may be suggested if there are specific issues to be
detailed for these environments)

3) LMP is a "way" to implement these features, it never
precludes other methods to be developed, proposed and
drafted as long as it attracts the interest of the 
ccamp community... 

4) if there are interactions with other bodies (for
instance, determine the J0, J1/J2 pattern and also
processing, encoding, etc.) nothing precludes "human" 
interactions (in the kireeti sense) in order to really
achieve a common agreement

imho, and this was clear for me after a first reading
of the "michiel's" draft, that if a dedicated piece
of text may cover "layered discovery" for sdh/oth 
networks most of these discussions would be settled

i hope this clarifies the reason of the "venture"
into this area and its interest by the ccamp wg
community,

- dimitri.  

"Bernstein, Greg" wrote:
> 
> 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.
> 
> Greg
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Tuesday, August 06, 2002 10:03 AM
> To: Michiel van Everdingen
> Cc: Dimitri.Papadimitriou@alcatel.be; 'Kireeti Kompella'; Jonathan Lang;
> ccamp@ops.ietf.org
> Subject: Re: LMP fraud
> 
> Michiel,
> 
> > Hello Dimitri, Kireeti, Yakov, Jonathan,
> >
> > I would suggest that you start reading
> >   http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00
> 
> After careful consideration I decided to ignore your suggestion.
> 
> > Only the pictures in this draft can clarify this confusing
> > discussion.
> > Terms that caused confusion are a.o.
> > - link
> > - TE-link
> > - data link
> > - data-bearing link
> > - name server
> 
> I understand that you are confused. However, dealing with
> your confusion is not within the charter of the CCAMP WG.
> 
> Yakov.

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361