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

From: Jonathan Sadler <[email-masked]>
Date: Wed, 02 Apr 2003 18:43:32 -0600

James -

James Carlson wrote:

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

Good to know the amount of explanation I should include in my responses.

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

I think your mixing the two message flows that exist in LMP.  I agree, the test messages
must run in a trace channel or traffic bearer associated with the traffic link in order
to work.  However, the management messages being sent between LMP instances to control
the test process, monitor the health of the LMP association, etc. do not.

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

Actually, I believe that the server layer trail's FDI/BDI is better than any out-of-band
method for relaying the state of the user plane link (traffic link).  LQM in this
situation would be better used as mechanism to monitor the control channel.

As for scope, I would be interested in your opinion on what information LMP has to
handle that PPP does not.

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

I think we're in agreement that the use of PPP for the Data Link layer on the DCC is
actually orthoginal from the issue of how non-associated link management operations is
done for user plane link.

My original comments were made as an identification that LMP is really doing the same
things already done by PPP -- its just doing them for non-associated links.

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

See my comment above about the use of an out-of-band channel instead of FDI/BDI to do
(6).

> It's this non-facilities associated signaling that (at least in my
> mind) makes LMP a bit different.

I tend to agree, but don't see it as too far different than what PPP can already do.
For example, one instance of PPP today can negotiate configuration parameters for links
that appear in different layer networks (ie. OSI, IPX, IPv4).  It accomplishes this
through the use of different NCPs at different PPP protocol numbers.

Similarily, it should be possible to have a "non-associated link" NCP which includes the
name of the specific link being "negotiated" in each negotiation message.  This would
allow for multiple instances of this NCP to exist, each tracking the status of a
different non-associated link.

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

I'm unaware of where LMP states that you should look into the MPLS layer as a liveness
test.  Can you provide me a reference?

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

The same issues exist for LMP.  Currently they are using <NodeID, IfIndex>, which is
very similar to the SNPP names being defined in the ITU.  Though, this shouldn't justify
the development of a completely new protocol...

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

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

---

From: James Carlson <[email-masked]>
Date: Thu, 3 Apr 2003 08:00:09 -0500

> the test process, monitor the health of the LMP association, etc. do not.

I wasn't disputing any of that.

I was disputing the (apparent) claim that running PPP on the DCC would
somehow render the entire solution to be "in-band only."  This is just
false.  There's no difference between running LMP over UDP/IP/PPP on
one hand, and running LMP over UDP/IP/raw-HDLC on the other.  LMP is
going to be the same no matter what transport is used.

So, back to the problem: I see no useful purpose served by running
UDP/IP over a hacked version of RFC 1332 plus RFC 1662, but with the
negotiation portion of RFC 1332 disabled and RFC 1661 omitted
entirely.

Doing this essentially makes the connection revert to SLIP-like
semantics.  The reason PPP was designed to negotiate was to avoid the
problems that had been seen with SLIP.  See RFC 1547 -- especially
section 2 -- for the reasons that PPP does what it does.

We've been down that road before, and it hurts.  Trivial
misconfigurations result in substantial network misbehavior.  It seems
a shame that anyone else should make that same mistake.

> situation would be better used as mechanism to monitor the control channel.

Sure.  It doesn't matter if it's better.  PPP's LQM can't tell you
anything about events outside of that point-to-point connection.

> handle that PPP does not.

They're utterly different protocols.

For one thing, LMP signals information about the data links themselves
-- communicating wavelength, bandwidth, type of switching, et cetera.
None of this would make any sense in PPP.

> done for user plane link.

Good!

> things already done by PPP -- its just doing them for non-associated links.

I don't see that as a "just."

The details are substantially more complex, *and* it would not make
sense at all to try to force LMP's features into PPP.

> through the use of different NCPs at different PPP protocol numbers.

They're all in parallel, and they're all at the network layer.

This is completely different from having to name and manage
information related to separate data channels.  The design issues are
different.

> different non-associated link.

Yes, you could do that.  If you did it right, I suspect you'd end up
reinventing LMP, but in a perhaps less flexible manner.

> test.  Can you provide me a reference?

Sorry.  I meant to type "hook," not "look."

It's the other way around.  LMP provides a way for nodes to signal the
existence and *status* of data links to be aggregated into TE links
for use by MPLS.  Sections 1 and 2 of the LMP draft cover this.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-08.txt

> the development of a completely new protocol...

And yet it's there.  I have no position on LMP.  I don't much care
about it.  It's the (re)use of PPP mechanisms without proper
implementation that I care about.