Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt

From: Timothy Kwok <[email-masked]>
Date: Thu, 11 Dec 1997 08:09:56 -0800

I am also very surprised that we reopen this issue at this very last minute.
The biggest driving original motivation for this draft is to support ADSL.
The ADSL Forum has supported a draft specification based on null
encapsulation for PPP over ATM. There are 38 companies supporting this
currently. The draft specification is going out of ballot after last week's
meeting to targeted become a final specification for the next meeting. If we
reopen this at the last minute, it will have significant ramification for
the ADSL industry and further delay the consensus we have been trying very
hard to achieve in the past 18 months at the ADSL Forum

I fully understand the need to interoperate with FR. However, for an entity
that is only interested in supporting ADSL applications for PPP over AAL5,
we should not impose restrictions on such devices. Hence, we must allow
entities that don't have intent of supporting FR can implement on null encap
without being noncompliant to the draft.

I wasn't able to make this IETF, but I hope our liason from the ADSL Forum
(Dave Allan) will or has already made this case at the IETF meeting.

Tim

> -----Original Message-----
> From:	Andrew G. Malis [SMTP:[email-masked]]
> Sent:	Friday, December 05, 1997 1:48 AM
> To:	James Watt
> Cc:	[email-masked]; Andrew G. Malis; Philip Rakity;
> [email-masked]; [email-masked]
> Subject:	Re: Last call on draft-ietf-pppext-aal5-03.txt
> 
> James,
> 
> >+--------
> >>Bottom line: the current ID text leaves the following question
> unanswered:
> >>
> >> ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF
> >>*mandatory* for
> >>      compliance with this spec? Or is it optional? Please tell me your
> >>      preference.
> >+--------
> >For the most basic of reasons, i.e. that both RFC 1973 and FRF.* already
> exist,
> >I would suggest that interoperability is mandatory.
> 
> I disagree.  The primary (although certainly not the only) application for
> this specification is for use with ADSL.  For that particular application,
> interoperation with PPP over FR is of no interest whatsover, and the
> ability to do so should not be required in order to have a compliant
> implementation of this spec.
> 
> HOWEVER, for other applications, the ability to interoperate may certainly
> make sense, and vendors will find it in their competitive interest to
> include the ability to do so.
> 
> We can discuss this further in the WG meeting.
> 
> Cheers,
> Andy
> 
> ________________________________________________________________________
> Andrew G. Malis  [email-masked]  phone:978 952-7414   fax:978 392-1484
> Ascend Communications, Inc.        1 Robbins Road     Westford, MA 01886

---

From: Philip Rakity <[email-masked]>
Date: Thu, 11 Dec 1997 14:20:38 -0800 (PST)

Tim,

While it is true that the ADSL forum endorsed your proposal, I explicitly
asked you at the meeting about the omission of LLC multiplexing.  You
replied that it was outside the scope of the proposal and if I am not
mistaken was not being voted on either in for or against sense of the
proposal.

Philip Rakity
FlowPoint

---

From: James Watt <[email-masked]>
Date: Tue, 16 Dec 1997 00:01:07 -0500

Tim:

I didn't intend to re-open this issue; I too thought we had discussed this
on the working group mailing list months ago. My original comment to the
list was because it wasn't clear to me that the text reflected what had
been agreed on the mailing list.

Although the ADSL Forum has provided the "first application" that motivated
producing the PPP/ATM document, IETF documents have a habit of being used
for many applications.

The interoperability issue is simple yet real. Consider the sequence of an
ATM-attached PPP speaker through an FRF.8 compliant inter-working unit to a
FR-attached PPP speaker. If the ATM-attached PPP-speaker supports only the
null encapsulation, there is _no_ way to carry IP end to end if you have
compliant FRF.8 and PPP/FR devices.

This scenario would seem possible in the ADSL world, with ADSL devices
being the ATM-attached PPP speakers and the IP provider's router being FR
attached.

One could observe that RFC 1973 doesn't cover the SVC case and, as it is
updated, it could require FR-attached PPP speakers to speak null
encapsulation in addition to NLPID.  If so, it would only be ATM-attached
PPP speakers that use PVCs that require LLC support for interoperability.

In summary, my concern was simply to point out that the working group is
being ask to publish a document that leads to "conformant but
non-interoperable" implementations.  I believe that everyone should now
understand the issue.

Regards,
-james

>> We can discuss this further in the WG meeting.

____________________________________________________________________________
James W. Watt,	[email-masked]		 Ph: (613) 591-3600
Newbridge Networks	600 March Rd Kanata ON Canada K2K 2E6	 FAX:(613)
591-3680