home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
pppext
/
pppext-minutes-93nov.txt
< prev
next >
Wrap
Text File
|
1994-02-08
|
10KB
|
221 lines
CURRENT_MEETING_REPORT_
Reported by Fred Baker/ACC
Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT)
Two documents were referred, without discussion, to the IESG for
consideration as Proposed Standards.
o ``PPP over ISDN'' (draft-ietf-pppext-isdn-03.txt)
o ``PPP over SONETE/SDH'' (draft-ietf-pppext-sonet-01.txt)
The following Drafts generated quite a bit of discussion.
o ``PPP over X.25'' (draft-ietf-pppext-x25-02.txt)
Should the language in the document be changed to say must not
instead of should not about the sending of the 0xCF encapsulation
if the connection was established with the zero Call User Data?
Resolution: the language is acceptable as it stands since it does
not propose using the 0xCF encapsulation for times other than when
PPP is desired. The document is recommended to the IESG for
consideration as a Proposed Standard.
o ``PPP in Frame Relay'' (draft-ietf-pppext-frame-relay-02.txt)
- The interaction with RFC 1490 systems may be indeterminate.
- To make it determinate, data protocols (not control protocols)
must use RFC 1490 encapsulation.
- This is per PPP/IPLPDN agreements from Columbus and Amsterdam.
- Requirement is a direct result of separating Bill and Keith's
documents.
The question was raised: If a system dies, how can the other
system tell if we are using the 0xCC data encapsulation? It was
also suggested that we use a SNAP encapsulated negotiation if we
want to revert to 1490 and use the 0xCF otherwise. Recommendation:
Insert a new sentence in the PPP/Frame Relay document that would
clarify the requirement that a system re-negotiate if it sees an
encapsulation it was not expecting. The final vote for this
results in several options.
- Option 1: The result of the negotiation results in the PPP
encapsulation and provides an LCP option to change the
encapsulation to 1490.
- Option 2: If the negotiations are performed on a medium that
has a default encapsulation, default to the media's preferred
encapsulation type. Provide an LCP option to go back to PPP
(0xCF) encapsulation.
- Option 3: There should be no LCP option for changing the
encapsulation type.
Final vote: Option 1: 1, Option 2: 23, Option 3: 5, Abstain:
10. Given this option, it is recommended that the single sentence
be added to draft-ietf-pppext-frame-relay-02.txt, and the resulting
draft-ietf-pppext-frame-relay-03.txt be considered by the IESG as a
Proposed Standard.
The obvious place to put this option is ``PPP LCP Extensions''
(draft-ietf-pppext-lcpext-04.txt), but it contains other work that has
been waiting and needs to be moved forward. Therefore, the
recommendation is that draft-ietf-pppext-lcpext-04.txt be considered by
the IESG as a Proposed Standard, and another document will be drawn up
describing the LCP option for negotiation of encapsulations.
[A note from the PPPEXT Chair: It is not clear that the group
reached an effective consensus concerning the default
encapsulation, or that this consensus represents the many
members of the PPP Working Group who were not in the meeting.
It was stated clearly and unanimously conceded in the meeting
that the indeterminate interaction with RFC 1490 systems is
only of concern if the default data encapsulation is
1490-style; if the negotiation results in the use of the PPP
encapsulation, and given the renegotiation on receipt of the
other encapsulation, there is no ambiguity. The members of
IPLPDN present in the meeting stated that they found the
ambiguity acceptable because it enabled them to not change
their micro code for their routers, to which the
counter-argument was made that to continue using the 1490
encapsulation they need only not negotiate the indicated NCP.
The chair observes that there is also a backward compatibility
issue; by the time the working group agrees on the LCP option
and publishes a document, there will assuredly be compliant
PPP/Frame Relay implementations fielded, which will be using
the 0xCF data encapsulation it recommends. The chair also
notes, without prompting from the members of the working group,
that it is as easy for one political camp to negotiate the
option as it is for the other, so the argument that the default
must be to use 1490 encapsulation after the NCP has been
negotiated appears weak. The chair further notes that the PPP
encapsulation inside a compressed or multi-link data stream is
(by specification) the PPP encapsulation without any
address/control field, requiring Frame Relay system to
recognize the encapsulation anyway if they use the PPP features
that they wish to import.
The chair notes that he has sought throughout this debate to
mediate a strong disagreement between two working groups, and
give each what they wish out of it. The objective facts seem
to suggest that the LCP option should negotiate the use of a
non-PPP encapsulation after the negotiation of the NCP, as the
use of the PPP encapsulation is provably correct and the
other---a point freely admitted by the proponents of the other
position---is not. This is the most important attribute of
all, and should, in his opinion, drive the debate to its
conclusion.
The chair's recommendation (to be freely and spiritedly debated
by all who wish) is that the document describing the option
should be drawn up by Bill Simpson, indicating that the default
encapsulation is the provably correct PPP encapsulation, but
that the other is negotiable. The updated PPP/Frame Relay
document and the document describing this LCP option should
become Proposed Standards together.]
Day 2 - Further Document Review
Dave Rand presented the ``PPP Reliable Transmission'' document,
(draft-ietf-pppext-reliable-00.txt). After some discussion, the
document was recommended for consideration by the IESG as a Proposed
Standard.
Dave also presented ``The PPP Compression Control Protocol (CCP)'',
(draft-ietf-pppext-compression-01.txt). Numerous changes were
recommended by the working group, separating the ``Predictor'' algorithm
into a separate document, and modifying the structure of the CCP
options. These will be edited into a new draft, which will be posted in
the Internet-Drafts directory for discussion. It is anticipated that
this work can be sent to the IESG before year end.
Rich Bowen then presented the updated ``PPP Bridging Control Protocol
(BCP)'' document (draft-ietf-pppext-for-bridging-01.txt). Minor
revisions were suggested. It is anticipated that this will go to the
IESG by year end.
Thomas Dimitri presented his NETBEUI/PPP proposal, ``The PPP NetBIOS
Frames Control Protocol (NBFCP)''
(draft-ietf-pppext-netbios-fcp-00.txt). This was cut short due to time
constraints and will be taken to the list.
Keith Sklower discussed ``The PPP Multilink Control Protocol (MCP)''
(draft-ietf-pppext-multilink-02.txt), that he had mailed to the list
just before the IETF meeting. This discussion continued with key
players during lunch. He will post the draft
(draft-ietf-pppext-multilink-03.txt) for discussion; it is anticipated
that this work will be ready for IESG consideration by year end.
The chair had planned to discuss the plan for the PPPEXT Working Group
for the coming two years, but was unable to do so due to lack of time.
This matter will be taken to the list.
Attendees
Andy Adams ala@merit.edu
James Allard jallard@microsoft.com
Fred Baker fbaker@acc.com
Rich Bowen rkb@ralvm11.vnet.ibm.com
Caralyn Brown cbrown@wellfleet.com
Steve Buchko stevebu@newbridge.com
David Carr dcarr@gandalf.ca
Cheng Chen chen@accessworks.com
Chris Chiotasso chris@lightstream.com
George Clapp clapp@ameris.ameritech.com
Thomas Coradetti tomc@digibd.com
Jonathan Didner jonb@bangate.compaq.com
Thomas Dimitri tommyd@microsoft.com
Robert Downs bdowns@combinet.com
Craig Fox craig@ftp.com
Richard Fox rfox@metricom.com
John Gawf gawf@compatible.com
Shawn Gillam shawn@timonware.com
Daniel Grossman dan@merlin.dev.cdx.mot.com
Chris Gunner gunner@dsmail.lkg.dec.com
Joel Halpern jmh@network.com
Ronald Jacoby rj@sgi.com
B.V. Jagadeesh bvj@novell.com
Jan-Olof Jemnemo jan-olof.jemnemo@farsta.trab.se
David Kaufman dek@magna.telco.com
Robert Lutz
Andrew Malis malis@maelstrom.timeplex.com
Glenn McGregor ghm@lloyd.com
William Miskovetz misko@cisco.com
Dennis Morris morris@altair.disa.mil
Andy Nicholson andyni@microsoft.com
Todd Palgut todd@nei.com
Eric Peterson elpeterson@eng.xyplex.com
James Philippou japhilippou@eng.xyplex.com
Venkat Prasad vsp@3com.com
David Rand dave_rand@novell.com
Kenneth Rehbehn kjr@netrix.com
Allen Rochkind Allen_Rochkind@3com.com
Robert Roden roden@roden.enet.dec.com
Benny Rodrig brodrig@rnd-gate.rad.co.il
Paul Serice serice@cos.com
Satya Sharma ssharma@chang.austin.ibm.com
William Simpson Bill.Simpson@um.cc.umich.edu
Keith Sklower sklower@cs.berkeley.edu
Timon Sloane timon@timonware.com
Steve Suzuki steve@fet.com
Thomas Walsh tomw@kalpana.com
James Watt james@newbridge.com
Bradley Wilson wilson@ftp.com
Honda Wu honda@nat.com
Mauro Zallocco mdz@netlink.com