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

From: Timothy Kwok <[email-masked]>
Date: Fri, 12 Dec 1997 11:48:44 -0800

Just to clarify, this is not only our proposal, but the proposal jointly
with 38 companies to accelerate the ADSL standard efforts. It took us a very
long long time to reach this level of consensus.

The core part of the proposal is PPP over ATM with null encapsulation and
after last week's ADSL Forum meeting, it has been agreed to send that out
for ballot. e believe we have a good chance to have the ADSL Forum issued a
specification on this so the ADSL deployment can be accelerated, instead of
stalled by lack of end to end interoperability.

Philip, you are right, the LLC SNAP is outside this current draft
specification of the ADSL Forum. I haven't heard any proposal to vote on
this separately and I don't believe we intend to do so because we already
achieved that level of consensus within the ADSL Forum to adopt PPP over ATM
with null encapsulation. 

Since your question is surrounding the process of the ADSL Forum, we should
take this offline or on the ADSL Forum list.

Tim
> -----Original Message-----
> From:	Philip Rakity [SMTP:[email-masked]]
> Sent:	Thursday, December 11, 1997 2:21 PM
> To:	Timothy Kwok
> Cc:	'Andrew G. Malis'; James Watt; [email-masked]; Andrew G.
> Malis; [email-masked]; [email-masked]; [email-masked]';
> [email-masked]'; [email-masked]'
> Subject:	RE: Last call on draft-ietf-pppext-aal5-03.txt
> 
> 
> 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
> 
> 
> On Thu, 11 Dec 1997, Timothy Kwok wrote:
> 
> > 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: Rene Tio <[email-masked]>
Date: Mon, 15 Dec 1997 16:21:02 -0800 (PST)

I agree with Tim on this point.  Given the current architectures:

- prem-to-POP SVCs: last I saw there was no frame relay to ATM service
interworking defined for SVCs, perhaps it's in the works but even then it
might take a while to be deployed.

- PVCs: we've all decided prem-to-POP PVCs is impractical.  If it's prem to
CO then you'd either tunnel or route at the CO.

Either way, LLC encapsulation is of limited utility.  Saying it's a "should"
for completeness is probably enough.

- Rene

> From [email-masked]  Fri Dec 12 12:31:48 1997
>

---

From: Philip Rakity <[email-masked]>
Date: Mon, 15 Dec 1997 16:40:31 -0800 (PST)

Rene,

Could you please explain what a prem is?

thanks,

Philip

On Mon, 15 Dec 1997, Rene Tio wrote:

> > > > (Dave Allan) will or has already made this case at the IETF meeting..
> > > > 
> > > > Tim
> > > >