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

From: Jonathan Sadler <[email-masked]>
Date: Fri, 05 Oct 2001 10:19:00 -0500

James -

Thanks for your response.  I hope that others have opinions to express
regarding this issue so a better "consensus" feeling can be developed.

I have not received any verification from the official OIF liaison to
the IETF, David O'Leary (Juniper Networks), on whether a proper liaison
was submitted to the IETF regarding the OIF UNI.  It is quite likely
that they have not done so.

The OIF has started a Principal Ballot period for the OIF UNI,
completing on October 16th.  I would like to include comments on this
issue in our company's response, but would like to base them on the PPP
working group's feeling on this issue.

Consequently, I would like to suggest that you send your responses
within the next couple of days.

Thanks you!

Jonathan Sadler

James Carlson wrote:
> 
> 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

---

From: Jonathan Sadler <[email-masked]>
Date: Fri, 05 Oct 2001 11:50:12 -0500

James, et al -

> reviewed that they'd approach us (or the IESG) for such a review.

Here is the response I got from David O'Leary regarding the liaison
of the OIF UNI to the IETF:

At Fri, 5 Oct 2001 05:41:21 -0700, dave o'leary wrote:
> A meeting was held last spring where OIF and IETF leadership
> discussed how to work together.  Since many of us are active in both
> groups, and the IETF doesn't require any formal liaison to submit
> drafts, and decisions to review/comment are made on an individual
> basis rather than a group basis, so a request for review basically
> has no effect - and it was decided that it was not worthwhile to
> write and send formal liaison letters.  So my job is really to educate
> each group about the other and about relevant activities, and to
> keep the OIF informed of related activities and status in the IETF.

I have sent him a message stating that the current OIF UNI discusses
PPP implementation issues, and that the PPP working group should be
engaged to discuss these issues.

Jonathan Sadler