RE: LMP revision 04

["Bernstein, Greg" <GregB@ciena.com>]

Hi Kireeti, see below answer to your question on control channel.

Greg

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Monday, August 12, 2002 10:27 AM
To: Bernstein, Greg
Cc: Ccamp-wg (E-mail)
Subject: RE: LMP revision 04


Hi Greg,

On Mon, 12 Aug 2002, Bernstein, Greg wrote:

> 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.

Is it possible for a network that uses SONET to transport data to use an
Ethernet for OSPF adjacencies and RSVP messages?

****  Yep, folks are doing this all the time (well some are) but nobody
wants to configure these "control channels" they want this discovered
whenever possible.  I.e., at the same time that I discover the (node, link)
<---> (node, link) mappings, I'd want to share info concerning the IP
addresses of the control entities.  I don't want to configure that info
since its to error prone.  Hence, why in G.7714, this process is called
"control entity adjacency" (or something like it).  Hmm, do you think we
need to break the topic of "control channel management" into separate
subtopics: (a) control channel configuration, (b) control channel
maintenance?  There is always a need to be able to configure "out of band"
control channels between entities (I didn't think this was covered by LMP
since its just configuration).  Control channel maintenance meaning
periodically checking the IP connectivity is what I was adressing.  Hmm,
maybe a third (c) control channel verification (are the right entities
talking) -- but does this overlap alot with OSPF and RSVP hello
functionality...
****

> 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.

Thanks, useful to know.

> 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).

Good question.  I've asked the ADs the same.

Kireeti.