Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt

From: James Carlson <[email-masked]>
Date: Wed, 2 Apr 2003 14:55:13 -0500

Jonathan Sadler writes:
> > That doesn't read right to me.  The "in-band" versus "out-of-band"
> > distinction is purely hypothetical.  In both cases, you'd be running
> > *some* signaling bits on the DCC.  Whether those bits are called
> > "in-band" with respect to the DCC itself or "out-of-band" with respect
> > to the actual data channels on the SONET/SDH link seems to me to be an
> > unhelpful distinction to draw.
> 
> In GMPLS, the control network and transport network are not required to have the
> same topology.  It is possible for two nodes (A & B) in two different locations to
> have a transport link (ex a Lambda) between them, but not have direct control
> plane connectivity.  Consequently, the adjacency established between A & B to
> manage the transport link may have to be carried through many IP router hops.

I'm very well aware of that based on my prior SONET/SDH design work,
and it's not the point.

If you did LMP test messages over a raw HDLC session using the DCC,
that would be no more or less "out of band" then a full PPP session
over the DCC used only for management-level signaling support.  The
fact that you're using one set of protocols or another doesn't alter
the way the signaling works on that one channel.

The big difference, as below, is the scope of the signaling.  LMP has
a much wider scope.  I don't see a reasonable way to modify PPP's LCP
and LQM to operate in a way that would signal liveness of unrelated
links.

> For all functions in LMP, the DCC is not the link that is being described -- it is
> just a conduit that MAY be used to carry the messaging.  The link being described
> is the SONET/SDH line/path.  Consequently, the link management operations being
> performed by LMP are really "out-of-band".

OK; we're talking about different things here.  If you run LMP over
UDP/IP over PPP on the DCC, the LMP part still gives you out-of-band
signaling.  Thus, inclusion of PPP does *not* render the solution
capable of supporting only in-band signaling.

> Is there really more?  LMP states it:
>  1) establishes a control channel including the control channel
>     parameters
>  2) identifies the parameters associated with a traffic bearing
>     link
>  3) identifies mis-connection of transmit/recieve pairs
>     (this is specifically what the test-sonet-sdh spec is used for)
>  4) identifies the grouping of traffic bearing links between neighbors
>     so that offered traffic can be carried any of the links in a group
>  5) monitors the liveness of the control channel
>  6) monitors the liveness of the traffic bearing link

It's at least part (6) that's more.  PPP does *NOT* contain any way to
signal anything about what might be going on with any other link.
It's this non-facilities associated signaling that (at least in my
mind) makes LMP a bit different.

Architecturally, there are other differences.  LMP is designed to look
into MPLS as a liveness test for MPLS purposes.  PPP's signaling tells
you no more or less than that the PPP link *itself* is good.  If all
you cared about was the DCC, then PPP's liveness would be enough.

> The only difference is PPP does it for the case where the control channel is
> carried over the traffic link (ie in-band), while LMP does it for the case where
> the control channel and the traffic link are separate (ie out-of-band).

That's a significant difference in my mind.  For the in-band case, you
don't have to name or number the "other" links.  There aren't any. For
the out-of-band case, you have to name or number those links, and you
have to deal with issues surrounding agreement on the naming and
agreement on link status.

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Jonathan Sadler <[email-masked]>
Date: Wed, 02 Apr 2003 13:41:41 -0600

James -

James Carlson wrote:

> Jonathan Sadler writes:
> > Some clarification:
> >
> > In section 3.1, the draft (draft-ietf-ccamp-lmp-test-sonet-sdh-02) states
> > "the test message is sent as defined in [LMP]" (draft-ietf-ccamp-lmp-08)
> > when using SONET/SDH's Section/RS DCC and Line/MS DCC to carry a test
> > message.  Section 12.5.6 of the referenced LMP draft states:
> >
> >   "The Test message is transmitted over the data link and is used
> >   to verify its physical connectivity. Unless explicitly stated,
>                                          ^^^^^^^^^^^^^^^^^^^^^^^^
>
> I read this as indicating that you could run unencapsulated if you had
> a compelling reason to do so, and that this was a reasonable
> interpretation of this new draft.

I can understand your interpretation.  The "explicitly stated" qualifier was not
always there, and was only added by the authors when they realized the size
constraints faced by the J0-16, J1-16, and J2-16 formats.  This definately needs
to be clarified in the test-sonet-sdh draft.

> > The upshot is the test messges are being carried on the SONET/SDH DCC
> > in a UDP/IP packet encapsulated "using bit-oriented HDLC framing
> > format [RFC 1662] (sic)".  The reference to RFC 1662 was done
> > specifically to avoid the LCP/NCP negotiations required in RFC 1661.
>
> In that case, my original objections remain.  This is an end-run
> around RFC 1661 that amounts to exactly the same result -- using "PPP
> frames" on a link without bothering to negotiate PPP.  I certainly
> agree that consenting peers can do such a thing, but I could never
> sanction such a thing.
>
> > PS. Its interesting to note:
> >  - the main purpose of LMP is to manage link operations* out-of-band
> >  - PPP does a good job of managing link operations in-band
>

This sort of disassociated signalling is also necessary for SONET/SDH applications
of GMPLS to handle cases where the DCC endpoints and the link endpoints are not
the same.  An example of this is a SONET line that goes through a regenerator --
the Section DCC will be terminated at the regenerator, while the STS payload will
be continued to the other end of the SONET line.

> The real question is "what bits are sent on the DCC, and why?"
>
> >  - LMP has not been widely implemented, and interoperability has
> >    not been widely demonstrated
> >  - PPP has been widely implemented, and shown to be widely interoperable
> > Do we really need a radically different protocol to complete the same
> > function?
>
> Yes, that is interesting to note, though perhaps not really relevant
> since there's more to LMP.

1 is done today by LCP
2 is done today by LCP and the NCPs
3 can be done either through the Identification LCP message,
  or the endpoint discriminator option defined by Multilink PPP.
4 is done today by Multilink PPP
5&6 are done today by LQM as well as monitoring the health of
  the serial connection (server trail)

> > * link operations = establish control communications between link neighbors,
> > negotiate link parameters, monitor "liveness of a link"
>
> Perhaps.  There are options in PPP to monitor link liveness, and I
> agree there's some overlap with LMP, but PPP's options are not
> 'required' in an implementation and they're not sufficient for all
> purposes.

Right.  And many of the functions in the LMP spec are also "optional"...

============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================