Subject: Re: Proposed use of PPP in the OIF UNI

From: James Carlson <[email-masked]>
Date: Mon, 1 Oct 2001 08:00:08 -0400 (EDT)

Jonathan Sadler writes:
> I have some concerns regarding the proposed configuration of PPP for the
> OIF UNI that I would like the PPP working group to look at.
> 
> In the OIF UNI (http://www.oiforum.com/public/documents/UNI_1.0.pdf),
> Section 6.1 page 22 defines the configuration of PPP on the SONET DCC as
> follows:
> 
> "...IP packets are encapsulated using PPP in HDLC like framing as per
> RFC1662. ... only PPP encapsulation must be used with no other PPP
> procedures (i.e. LCP and NCP need not be executed)."

That's absurd on multiple levels.  You can't claim to be using PPP if
you're just using the framing, and I frankly don't see how any level
of interoperability could be hoped for with the phrase "need not be
executed."  What happens when one vendor chooses to implement the
existing IETF Standards Track protocols and another does not?

> Is PPP without LCP/NCP negotiation considered a standard implementation
> by the IETF?

No.  It's not PPP.  It's effectively SLIP, albeit with different
framing.

Of course, consenting peers may do anything they like, including
omitting the necessary (and useful) RFC 1661 LCP and RFC 1332 IPCP
negotiation for no apparent reason.  I see no point to doing so, but
there's no law prohibiting it.

(At a wild guess, I would assume that PPP negotiation is viewed as
"unnecessary overhead."  I would submit that [1] a useful
implementation of the OIF signaling has such significant complexity
that PPP is effectively a drop in the bucket and [2] source code that
implements PPP is freely available.)

>  RFC 1661 (which is never referenced by the OIF UNI
> document) seems to have strong words preventing this.

Right.

> It should be noted that the OIF has chosen this in part to facilitate
> the misconnection detection feature specified in LMP
> (draft-ietf-ccamp-lmp-00.txt, and OIF UNI section 8).  Specifically, the
> test messages for LMP are defined to be carried within IP PDUs on the
> data link.  Because successful LCP/NCP negotiation requires a correctly
> connected full-duplex link, these IP PDUs be prevented from being sent
> on a misconnected link.  As a result, LMP would not have a chance to
> detect this case.

I don't think that's true at all.  There are certainly possible
failure modes in which PPP establishes normally, but IP-based
protocols (such as LMP) don't work at all.  For instance, the peer
might not be running LMP.  Having IPCP properly negotiated does not
mean that any applications are available or running; it merely means
that IP datagrams are permitted on the link.

> While the current LMP solution has this problem, other solutions may
> not.  For example, the test messages could be carried within an LCP
> option (similar to the Identification option specified in RFC 1570). 

I certainly wouldn't want to see that done.  (Perhaps LCP Echo-Request
would be useful *in addition* to other higher-level test messages, but
they're no substitute.)

> Please provide the feeling of the working group on this issue.

Review of these documents isn't required here, but I'd hope that the
OIF would be interested enough in having the relevant portions
reviewed that they'd approach us (or the IESG) for such a review.

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