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

From: [email-masked]
Date: Tue, 16 Dec 1997 08:19:57 -0500

James and Tim:
I agree with James that the issue of FR interworking is a real one.  PPP
over ATM for ADSL encourages the deployment of 2 new networking
technologies - ADSL and ATM (SVC capable) access networks.  Unfortunately,
the very motivation for the proposal - to provide a way to interwork with
existing ISP networking which uses PPP - is also a motivation to interwork
with FR, since many of those ISP networks apparently already connect via
FR, and many existing access networks haven't deployed ATM at all yet.
That said, I also know that the reality of the Prem (that's end customer
premises) equipment will include PCs that are capable of agility between
packet and cell modes.  Is the proposed new text for point 3 (Ian Puleston)
sufficient to define a mode-agile access network that can reflect either FR
or ATM to such a mode-agile prem ADSL host?  That would be desirable, I
think, but I don't understand the details well enough yet to know whether
it's OK as written, a modest extension of scope, or a new document.
Bob Jenness

James Watt <[email-masked]> on 12/16/97 12:01:07 AM

To:   Timothy Kwok <[email-masked]>
cc:   [email-masked] (bcc: Robert
      Jenness/Development/Siemens_Stromberg-Carlson/US)
Subject:  RE: Last call on draft-ietf-pppext-aal5-03.txt

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

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

---

From: [email-masked] (garage!gmg)
Date: Tue, 16 Dec 1997 10:38:28 -0500

Hi,
	Here's what I would like to nominate as the final version of the
text passage in question:

3. If an implementation is connecting through a Frame Relay/ATM
   FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point,
   then it MUST use LLC encapsulated PPP payloads. Implementations
   that want to inter-operate with all potential end points MUST
   implement LLC encapsulated PPP payloads.

The -03 version said "MUST support LLC encapsulated PPP..." instead of MUST
use.  The last sentence in the above text reflects a discussion held last
week at the IETF between Andy Malis, James Watt, David Allan, and myself.
The intent is to highlight the consequences of implementing only
VC-multiplexed PPP payloads.

	George

---

From: Timothy Kwok <[email-masked]>
Date: Thu, 18 Dec 1997 10:14:54 -0800

Joe,

You are right. A vendor may not know what the user is going to use its
equipment for. But isn't this a marketing decision for that vendor ? If the
vendor reads this RFC, they know that if they only want to target nonFR
interworking market, it is optional for them to do X. But if they want to
target the FR interworking market in the PVC environment, they MUST do X.
This RFC clearly spells that out. We should not remove the choice from the
vendor to make their product decisions. Otherwise, we are using this RFC to
make the product decision for all vendors, independent of their market.

Tim

> From:	Joel Halpern [SMTP:[email-masked]]
> Sent:	Thursday, December 18, 1997 9:00 AM
> To:	Timothy Kwok
> Cc:	'Joel Halpern'; David Allan; [email-masked]';
> 'James Watt'; [email-masked]'; [email-masked]'
> On Thu, 18 Dec 1997, Timothy Kwok wrote:
> 
> > Good question, Joel.
> > 
> > The major motivation of driving this RFC is for ADSL environment from
> > vendors and carriers eager to deploy ADSL service ASAP and supporting Y
> in
> > such environments is not the focus at all. Forcing the ADSL environment
> to
> > use X is a burden to those environments. 
> > 
> > Hence, this RFC is really saying
> > 1. X is recommended, but optional (so its not a burden to those who has
> no
> > intention of supporting Y)
> > 2. AND, IF you are interested in interoperating with Y, you MUST X.
> Also, IF
> > you are interested interoperating with ALL scenarios, you MUST X.
> > 
> > Tim
> 
> Time, I am very sympathetic to your view that there is a specific
> envirmonemtn where Y does not apply, and that is the problem to be solved.
> Two issues, from lessor to greater:
> 1) The Document title and Scope is not "ADSL support", but "PPP Over ATM".
> If we only want to solve ADSL, we should say so.
> 
> 2) More significantly, I think that FR interworking does apply to ADSL.
>    For example, consider a work-at-home or remote office, using ADSL to
>    access an ATM service, which is directly interworked with the FR
>    service that the corporation uses.  Instead of using L2TP tunnels 
>    (which are an option), the user simply establishes VCs directly to the
>    corporate infrastructure and runs IP over them.
>    If I can think of one case, I am sure that there are others.
>    Suppose that the ISP is actually using FR rather than ATM, and is
>    reached through an interworking function.
> 
> So, I tend to feel that the device can not "know" at manufacturing time
> that it will never have to deal with FR interworking.
> 
> > 
> > > From:	Joel Halpern [SMTP:[email-masked]]
> > > Sent:	Thursday, December 18, 1997 7:36 AM
> > > To:	David Allan
> > > Cc:	[email-masked]'; 'James Watt';
> > > [email-masked]'; [email-masked]'; Timothy Kwok
> > > I must observe that writing into a proposed RFC text which reads:
> > >   Implementations Should X
> > >   Implementations which do not X will not interoperate with Y
> > > Is a clear invitation for someone to push harder on the question I am
> > > asking:
> > >     Why not MUST X?
> > > 
> > > Yours,
> > > Joel M. Halpern
> > > 
> > >   ... Other content elided ...
> 
> Yours,
> Joel M. Halpern                         [email-masked]
> Newbridge Networks Inc.