[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: LMP revision 04



Hi Bert, Kireeti, and Yangguang,
Here's my answer from the perspective of SONET/SDH (for other technologies I
might have different answers):

a. control channel management -- To me this is just IP connectivity between
control entities.  I don't use this for "ultra fast" restoration (have
separate signaling mechanisms via AIS, RDI and K bytes) hence I was counting
on IP's inherent resilliance/recovery here.  To set up "control channels" I
use a discovery mechanism(s).  Hence I don't see much use for this.

b.  Link Property correlation -- This is functionality that I'd use.  The
link bundling example is just one case.  A problem does come up in that I'd
like to use it for technology specifics too.  An example that I frequently
use for this type of functionality in promoting SDH interoperability is in
the configuration of 1:N SDH protection groups.  

c.  Link connectivity verification -- This is where the argument concerning
"discovery" comes in again.  SDH contains lots of hooks for this at many
layers (note that SONET/SDH has multiple layers in and of itself).
Don't see this of much use for SONET/SDH as it stands.

d.  Fault management -- Wouldn't touch it.  SONET/SDH has much more
elaborate a faster mechanisms.

Process questions for Bert and </chair> Kireeti </chair>: (a) all this
discussion is interesting but where are we in the process? In particular
Kireeti in a previous mail explained that the comment period was over and
that these discussions were just as a "courtesy" to me. (b)Has "rough
consensus" been obtained?  If so we can close these discussions.  Most of
what I've been reviewing here for folks is standard SONET/SDH. Note however
that the transport network has many layers and that most of the optically
astute authors of LMP have be concerned with either transparent optical or
nearly transparent optical (below the SONET line layer).

Greg 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Friday, August 09, 2002 2:22 AM
To: Yangguang Xu; Ccamp-wg (E-mail)
Subject: RE: LMP revision 04


So... trying to be clear here. What exactly do you mean
would it be that people specify which of the following
four functions they implement/use:

  a. control channel management
  b. link property correlation
  c. link connectivity verification
  d. fault management?

Or are there more?

First, I suspect that when we talk about b. and c., then I guess
we need a better definition of what "link" means in the COMMON
sense. In fact, I would like to see good definitions of each of
the "functions" that people agree on. Only then would it make 
sense to ask for such details. It seems (at least to me) that
we've had some confusion on what exactly is meant, and as a 
result, maybe people believe that they do or do not implement/use
some of those functions with LMP or with other mechanisms.

Thanks,
Bert 

> -----Original Message-----
> From: Yangguang Xu [mailto:xuyg@lucent.com]
> Sent: donderdag 8 augustus 2002 22:22
> To: Ccamp-wg (E-mail)
> Subject: Re: LMP revision 04
> 
> 
> 
> Bert,
> 
> Can we also add which LMP functions too, as Bala suggested? 
> This is where the
> arguments come.
> 
> 
> Kireeti,
> 
> FYI only, (which means I have no intention to argue for it) 
> and just my
> understanding from LMP related emails (I happened to read and 
> understand some of
> them), fault management in LMP is technology specific. Control channel
> management is suspicious. At least some argue that it is not 
> necessary for some
> technologies, and meanwhile overlap with some other solutions 
> (better/complete
> but not invented here).
> 
> BTW, is fault management in CCAMP charter?
> 
> Thanks,
> 
> Yangguang
> 
> "Wijnen, Bert (Bert)" wrote:
> > 
> > > <chair hat>
> > > Nevertheless, this may be of interest.  If an AD would volunteer,
> > > perhaps folks can send him a *short* message stating:
> > >
> > > Type: vendor/carrier
> > > Company: (to weed out duplicates)
> > > Interest level in LMP:
> > >       For vendors:  opposed/yawn/interested/implementing/released
> > >       For carriers: useless/yawn/useful/testing/deploying/deployed
> > I would add:
> >   used with technology: ethernet/sonet/sdh/atm/fr/xx
> > 
> > >
> > > and the AD can post a tally of the responses?
> > > </chair hat>
> > >
> > This AD volunteers for that.
> > 
> > Bert
>