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

From: Jonathan Sadler <[email-masked]>
Date: Thu, 03 Apr 2003 10:37:33 -0600

Bert -

"Wijnen, Bert (Bert)" wrote:

> The discussion got started, because as responsible AD for
> the draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt document
> I found a ptr that there might be a possible issue.
>
> Not sure I understand all this discussion sofar.

Sorry about taking the discussion in a different direction.

> My understanding and my focus of the discussion would
> be as follows:
>
> - LMP is a Link Management Protocol that runs on UDP and
>   all the control info goes over that path. In many cases
>   that control info goes out of band of the data path
> - In the case where the LMP wants/needs to test that the
>   data path is indeed operational, that is where it sends
>   a test message. It does so over UDP if it is available
>   on the data path, via other methods if it is not available
>   on the data path (as is the case for sonet/sdh).

A clarification: the test message is only sent between two neighbors in a
layer network.  It does not test the end to end connectivity of the client
layer.  As such it cannot verify if the client layer is "operational" -- it
only can test that the server layer is connected.  Other things (such as
adapatations) could be set incorrectly which would cause the client layer to
not be "operational".

> - This test message is only used for very short periods of
>   time.... so I wonder if it then makes sense to try and setup
>   a PPP connection first in order to be able to send a few
>   short test messages in order to just verify that the data
>   path is functioning.

Further, a PPP connection supporting IP requires a functional bi-directional
link -- LCP and IPCP will not negotiate if the link is not bi-directionally
connected.  The result is it would be it impossible to do the miswiring
detection defined by LMP.  However, this does not mean that RFC 1661 should
be precluded...

> Given the above (and pls correct me if I got it wrong),
> Then it it seems that:
>
> > 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.
> >
>
> Is a true statement, but the question is if it indeed makes sense to
> have to setup a PPP connection to send just a few UDP packets after
> which the connection (PPP) is to be removed again, cause there might
> be otehr data (non IP even) traveling on the data path.

Since the test message is going between two immediate neighbors on a PPP
link, there is no need to include IP or UDP in the messages.  Instead, two
methods exist that conform with the RFC 1661 may be used:
 - Use the Identification LCP message as defined in RFC 1570
 - Have the LMP test message carried as an LCP option when
   LCP negotiation is done on the PPP link.

The first method has benefits over the later as:
 - the identification field provides a "method for an
   implementation to identify itself to its peer."  The test
   message defined by LMP contains "TE Link" identification.
 - there is no need for a new code point (and related
   behavior) to be defined
 - a test message can be sent at any time, independent of PPP
   protocol state

Because of these reasons, the ITU chose the first methods for G.7714.1.

A related question is: do we need two different methods for passing the "TE
Link" id in-band to verify the connectivity of a link endpoint?

Jonathan Sadler

> I hope the above makes sense and can keep the discussion to the
> problem/issue at hand (as far as I see it).
>
> Bert

============================================================
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 11:47:18 -0500

>    LCP negotiation is done on the PPP link.

Here's a third: create an LMP "network protocol."  I'd be happier with
that than with either an LCP option or hijacking the Identification
message.  Note that it's not actually necessary for any network
protocol in PPP to have a corresponding NCP to negotiate anything, so
you could just open LCP and then send your "network layer messages"
(actually LMP test messages).  (Each network layer protocol is
separately defined for this reason; each can define its own
procedures.)

Since you send them infrequently and header compression isn't much of
an issue, you could use the relatively open 4xxx range of protocol
IDs.

>    message defined by LMP contains "TE Link" identification.

Er ... ok.  The intent of the Identification field is to provide a
software version string that can be placed in a log file for a human
to determine what might have gone wrong with a broken link.  I agree
that there's no "standard" for what is placed there, but placing
machine-readable data into a field intended for text seems to be an
abuse to me.

Worse, if you did this, nobody would be able to use LCP Identification
on SONET/SDH for its intended purpose, and that would seem to me to
represent a net loss.

>  - a test message can be sent at any time, independent of PPP

That'd be also true if you created a new network layer number.

> Link" id in-band to verify the connectivity of a link endpoint?

Fewer would certainly be better.  One would be ideal.

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