Editor's note:  These minutes have not been edited.


The PPP Extensions Working Group met at the Montreal IETF meeting 
on Wednesday, June 26th from 1300-1500 and on Thursday, June 27th 
from 1300-1500.
Minutes of the two meetings follow:

Reported by: Ed Allen

Wednesday meeting

1. LCP Extensions (draft-ietf-pppext-lcpext-ds-00.txt) 

Bill Simpson led a discussion of the various LCP extensions described in 
the document.
Bill said this draft has been on hold waiting for someone who wanted 
to change callback.
An informal poll showed that there are 2 implementations of the 
Identification option, and 2 implementations of callback. Discussion 
revealed there is concern that the callback option is not ready yet.

Resolution is that Callback option will be stripped from current draft 
and made into a separate draft, so that the remaining LCP extensions 
can continue on the standards track. draft-ietf-pppext-lcpext-ds will 
then be resubmitted and sent out for working group last call.


2. Vendor Extensions (draft-ietf-pppext-vendor-00.txt) 

Bill Simpson explained the rationale of this draft. He explained that 
this cannot be standards track document due to no possibility of 
interoperable versions, but noted that CCP already has the same 
vendor-specific option, which is standards-track. Bill asked what do 
people think about going standards track? Area Director Jeff Burgan 
said he thought it would be Informational. 

Resolution is that this draft will be sent as Informational RFC by Bill 
Simpson to the IESG.

3. SONET (RFC 1619)

Bill Simpson explained that there are already commercial 
implementations of this RFC. Bill explained that PPP has been 
designed to run from very low speeds to very high speeds, and briefly 
explained SONET, which runs at 155 Mbits/sec, with 622 Mbs and 2 
Gbps in development. He explained that although ATM runs over 
SONET, it has a larger overhead than PPP. He noted that one major 
chip vendor has admitted not conforming to SONET spec in loss of state. 
The chip only detects 72 bit sequences of zeros.
Bill proposed to add two sentences and an appendix to PPP over SONET 
which will describe a settable third byte and how to escape long 
sequences of zeros. This text will provide a workaround for the chip 
problem. 

4. Multilink Protocol(MP) (draft-ietf-pppext-multilink-12.txt) 

Karl Fox led a discussion of Multilink, RFC 1717. Karl said MP has been 
sent to Draft Standard. 

Karl recalled a discussion which took place on the list to the effect 
that the caller being responsible for initiating bringup of links (with 
respect to dialed lines and bandwidth-on-demand). Resolution of this 
issue was that there would be no change to MP. It is on desk of RFC 
editor and will have a new RFC number assigned to it. There was 
discussion as to whether there should be an informational RFC 
describing current practices in this area. It was decided that there is 
sufficient interest, and Dan Brennan volunteered to head up the effort 
to write the informational RFC. 

5. Extensible Authentication Protocol(EAP) 
(draft-ietf-pppext-eap-auth-02.txt and draft-ietf-pppext-eaprsa-
02.txt) 

Karl Fox noted the main document fell off the six month timer. Since 
there are two interoperable implementations the main document will 
be resubmitted. There was interest by three to four vendors in working 
on this extension.

6. Protocol Spoofing Control Protocol(PSCP) (draft-ietf-pppext-spoof-
00.txt) 

The author was not present.
A discussion of the merits of this approach occurred. A representative 
from one vendor mentioned they had done some work on retaining 
context while spoofing, when zero links (retaining context across 
disconnects). One benefit is that a client can retain its dynamically 
assigned IP address.
There was a proposal that doing a spoofing protocol was not 
worthwhile in and of itself.
Long discussion occurred about persistent state, suspend/resume notion, 
spoofing.
Group rejected idea of putting spoofing capabilities into BACP. At least 
one vendor has implemented PSCP. 

Resolution was that Dana Blair would work with Ian Puleston (draft 
author) to describe current practices.

7. STAC compression (draft-ietf-pppext-stacker-09.txt) 

It was agreed that draft 10 will consist of draft .09 plus fixed typos. 
Draft 10 will then be sent to the IESG for upgrade to proposed standard. 

One questioner asked whether anyone has gone ahead w/ Motorola 
license agreement? Only one company said they had executed the 
license agreement. 

Hands showed there were about 10 implementers of Stacker. A 
representative from Stac said that there is a deal where you can get 
access to Motorola license proposal from Stac. It contains terms of 
license agreement.

8. Status of other work by PPP WG.

CHAP and LQM are now approved Draft Standards, and will get RFC 
numbers soon. Netbios CP is at Proposed Std status.

Other drafts:
Status of WCP (draft-ietf-pppext-wcp-00.txt) was discussed. Ed Allen 
explained that WCP can be negotiated using CCP, and is thus not a 
standard which competes with WCP.

draft-ietf-pppext-dataencap-03.txt has expired, and as there is no 
interest from the WG, will be allowed to die. 

draft-ietf-pppext-encryption-04.txt is at Proposed Standards draft-
ietf-pppext-des-encrypt-01.txt is an informational. draft-ietf-pppext-
frame-relay-03.txt is stds track, and is at PS and will receive an RFC 
number from the RFC editor at some point in the future. 

draft-ietf-pppext-snacp-01.txt has been implemented by one vendor, 
and will become and informational RFC.

11. PacBell bakeoff

Anita Freeman of PacBell stated there will be another interoperability 
bakeoff either Oct 20-25 or Nov 17-22.
(The October choice was chosen by the WG.) Anita stated that there 
will be a max. of 68 tables. There will be up to 8 PRI interfaces and 136 
BRIs 1st couple days are remedial testing for MP, followed by testing 
for CCP and BACP.
Location is San Ramon, San Ramon Marriott was suggested for advance 
reservations.
bob@Larribeau.com is organizer of the bakeoff. 

12. Assorted other PPP extensions.
Bill Simpson asked the working group about assorted other PPP 
extensions. 

IPXCP
Bill Simpson asked the WG if there were any changes need to IPXCP. 
Twelve vendors said they had implemented IPXCP. The WG agreed to 
send IPXCP to IESG as draft standard. 

PPP over ISDN (RFC 1618)
Bill said there have questions and comments about this draft. Dana 
Blair will solicit list for comments. 

PPP over X.25
A (non) show of hands revealed , nobody in room had implemented this 
one Bill knows of 3 vendors shipping this.

There will be an effort to get a number of protocols either to draft std 
status or to kill them.


---------------------

Thursday meeting

13. BACP - Craig Richards

Current draft is draft-ietf-pppext-bacp-03.txt, is based on comments 
from LA IETF meeting and experiences at May Pacbell bakeoff. The 
draft is now in last call status.
Craig said the most recent changes were the removal of Link Drop 
request, Bundle Drop request and 2 other msgs.
He said he improved & clarified phone number format, he noted other 
changes as well.

Craig noted there was successful interoperability at PacBell bakeoff. 
All were alpha or beta code.

There were questions and suggestions for rewording regarding: 
o section 6.2 Phone-Delta Unique Digits suboption o substituting 
transmitter/receiver for peer. o Link-Drop-query request wording.
o sect 2.1 Link Discriminator, description of wrapping. o discussion re: 
Callback-request value and concern of is value. o link-type option only 
being 8 bits.
Craig indicated he would clarify the wording where necessary. 

Karl Fox polled the WG to find out the WG opinion of BACP. A show of 
hands revealed there are 4 BACP implementations and 8 more planned. 
25 hands indicated they thought BACP was valuable, while zero 
hands thought BACP was not valuable. 

14. Point-to-Point Tunneling Protocol(PPTP) - draft-ietf-pppext-pptp-
00.txt 

Gurdeep Singh Pall presented concepts, terminology, design goals and 
protocol details of PPTP.
He presented Incoming Call states for each end of a tunnel. He also 
presented a comparison between PPTP and L2F. Gurdeep stated future 
goals for PPTP, which included the following: 
o Converge with L2F
o Include new features which have been identified, but which 
are not in PPTP today.
o Leverage other IETF efforts, including IPSEC. Gurdeep provided the 
following URL for PPTP source code: 
http://ftp.microsft.com/developer/drg/pptp/src 

Here are some of many questions/discussions following Gurdeep's 
presentation:
o How does PPTP go thru firewall
o How handle shared credentials, and other security issues. 


15. Level Two Forwarding(L2F) - draft-ietf-pppext-l2f-02.txt 

Andy Valencia discussed a number of detailed L2f issues that are 
outstanding. Some are included here:
o out of seq recovery
o uniform len-type-value encoding
o mandatory/optional flag
o vendor specific fields
o outbound calling
There was a lot of discussion on question of whether to use IP instead of 
UDP. Resolution was to use GRE, which has its own IP protocol number. 
Coulduse and IP prot # instead, and sve 20 bytes pkt hdr. AV has 
concern that if eeveryone did this, all IP #s would be used up Concern 
that firewalls would not be able to filter on IP prot #. Pat asks why not 
use GRE, which has prot number Disc of Ipv6

There was discussion of various other issues, such as: 
o how IPv6 fits in
o MTU issues
o clear text passwords across tunnel when PAP or SLIP is used o pre-
encrypted passwords
o other possible security attacks
o the second negotiation of LCP, and how client LCP 
implementations handle LCP going down.
o minimal or no L2f header

A discussion of the LCP options recommended for use with L2F suggested 
the following options:
o Multilink
o 1500 byte MTU
o others to be solicited from the PPP WG list. 

Andy presented L2F status as this:
1. holding up well in IETF
2. interoperable implementations
3. L2F and PPTP folks have been talking

Andy categorized commonalities between L2F and PPTP and also 
aspects unique to each.

16. Combine PPTP and L2F

After discussion a goal was stated to combine PPTP and L2F before the 
next IETF meeting.
Proponents of each will work together to come up with a new draft, 
tentatively called L2TP.

Andy Valencia made some suggestions as to what L2TP would inherit 
from PPTP and L2F.
L2TP would:
Keep layer 2 tunnel
keep GRE format
Adopt uiformat content format
L2TP would inherit from PPTP:
media semantics (BACP)
calling (but modularize)
optional flow control
L2TP would inherit from L2F:
optional ID
optional LCP
others were mentioned

Andy also highlighted some L2TP futures as being: 
encryption
integration with BACP
multicasting
fancy queuing issues

There was a discussion of using a reliable channel for data. 

Ian Duncan agreed to set up a mailing list for discussions related to L2TP 
and to send the email address to the PPP list. 

17. Secure Dynamic Tunneling Protocol(SDTP) Pat Calhoun and Ellis 
Wong 

Pat Calhoun and Ellis Wong presented concepts of SDTP. The following 
are some SDTP concepts:
o can be used as a router to router tunneling protocol o can be used as a 
NAS to gateway tunneling protocol o PPP is terminated at the NAS for 
dial-up access. o security for the tunnel uses IPSEC
o high scalability due to multiple tunnel capability o multiple protocol 
support (any level 2 and level 3) o some SDTP concepts are borrowed 
from Mobile IP 

Questions/discussion followed regarding how SDTP is different from 
ATMP. Ellis Wong agreed to send a path to slides to the mailing list. 

Some participants expressed the opinion that SDTP concepts should be 
combined into L2TP.