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

From: Jonathan Sadler <[email-masked]>
Date: Wed, 02 Apr 2003 12:25:22 -0600

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,
  these messages MUST be transmitted over UDP like all other LMP
  messages. The format of the Test messages is as follows:

   <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>"

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.

These two details (test messages using of UDP/IP, and non-use of LCP/NCP
negotiation) have been confirmed in private communications with the authors.

Jonathan Sadler

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

* link operations = establish control communications between link neighbors,
negotiate link parameters, monitor "liveness of a link"

James Carlson wrote:

> Thomas Narten writes:
> > You reviewed parts of this (and a related) document a long time ago
> > (see below). A question I have for the PPP community is whether the
> > current version of the lmp-test-sonet ID is acceptable from a PPP
> > perspective.
>
> This draft (draft-ietf-ccamp-lmp-test-sonet-sdh-02) is a little hard
> to interpret, but I read it as using the LMP option to run the test
> messages without UDP/IP and instead over raw HDLC framing.  In that
> case, I see no PPP-related issues.
>
> That's not the same as saying that I think this is necessarily a good
> idea -- I don't, because I think being able to run SNMP, OSI, and
> other protocols alongside LMP is valuable, and a multiplexing layer
> such as that provided by PPP would allow you that flexibility at
> fairly low cost.  Retrofitting equipment that uses this null
> encapsulation to work correctly if you decide to do any multiplexing
> in the future will be highly problematic.
>
> The reference to RFC 1662 is odd and probably erroneous, since that
> document describes how PPP uses HDLC framing.  The draft should
> probably reference ISO/IEC 3309 directly instead.
>
> If the reference is actually correct, then the protocol defined here
> will need a PPP protocol number for section 3.1 of RFC 1662, and I
> think we're back where we started ("using PPP without benefit of
> negotiation").
>
> --
> 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: Wed, 2 Apr 2003 13:38:20 -0500

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

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

>  - PPP does a good job of managing link operations in-band

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.

The real question is "what bits are sent on the DCC, and why?"

> Do we really need a radically different protocol to complete the same

Yes, that is interesting to note, though perhaps not really relevant
since there's more to LMP.

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