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

From: [email-masked] (garage!gmg)
Date: Thu, 4 Dec 1997 18:09:23 -0500

Hi,

	I share the concern that has been expressed about the text in
section 4 point 3. At the very least I will revise it in ID version 4 to
say "MUST use" instead of "MUST support".

	Although I'd rather not re-visit all the ground we covered on this
topic earlier this year back in April, it seems to me that more clarification
is needed in this part of the ID. Here's my shot at revising point 3's text:

3. If an implementation is connecting through a Frame Relay/ATM FRF.8
   service inter-working unit to an RFC 1973 end point, then it MUST
   use LLC-encapsulated PPP payloads. An implementation that elects
   to inter-operate with all prospective end points MUST implement both
   VC-multiplexed PPP payloads and LLC-encapsulated payloads.

	The intent of point 3 is say that those end points that *choose* to
inter-work with an RFC1973/FRF.8 service MUST be prepared to accept LLC-
encapsulated PPP.  By implication, the ID allows a RFC1973/FRF.8 IWF end
point to support *only* LLC-encapsulated PPP and not VC-mux'ed PPP. This
is effectively an exception to point 1, which says you MUST support
VC-mux'ed PPP.

So inter-working with a RFC1973/FRF.8 service end point reduces to two cases:

a) When administering an AAL5 PVC, choose the same PPP technique at both
   end points. Some FRF.8/ATM IWF units MAY support VC-mux'ed PPP, but all
   MUST support LLC-encapsulated PPP. As a consequence, if you want to
   inter-operate with _all_ potential PPP over AAL5 end points, you MUST
   implement LLC-encapsulated PPP.

b) If negotiating an AAL5 SVC, then the discussion in section 7 applies.
   Unfortunately, there is the SVC case of an originating end point that offers
   only VC-mux'd PPP to an RFC1973/FRF.8 end point that wants to accept
   only LLC-encapsulated PPP. The FRF.8/ATM IWF unit will refuse the call.
   They will *not* inter-operate. Of course if the FRF.8/ATM IWF is clever,
   both SVC end points MAY agree to do VC-mux'ed PPP instead of
   LLC-encapsulated PPP.

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.

	BTW, I should point out that the recent exchanges on the PPP list
about "active" versus "passive" bridging convertors are directly applicable
to this situation. When handling PPP sessions, the existing FRF.8 IWF is
strictly a "passive" FR/ATM bridging convertor, and so it will fall into the
same inter-operability problems that have been identified with that
implementation choice as were discussed for other media.

	George Gross

---

From: James Watt <[email-masked]>
Date: Thu, 4 Dec 1997 20:59:24 -0500

At 18:09 -0500 1997.12.04, garage!gmg wrote:
>...
+------
This looks good by me and clarifies the ambiguity that was of concern.

+--------
>      compliance with this spec? Or is it optional? Please tell me your
+--------
For the most basic of reasons, i.e. that both RFC 1973 and FRF.* already exist,
I would suggest that interoperability is mandatory.

Regards,
-james

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 05 Dec 1997 04:47:47 -0500

James,

>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