Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/pppext/pppext-minutes-93nov.txt

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               [e-mail]
James Allard             [e-mail]
Fred Baker               [e-mail]
Rich Bowen               [e-mail]
Caralyn Brown            [e-mail]
Steve Buchko             [e-mail]
David Carr               [e-mail]
Cheng Chen               [e-mail]
Chris Chiotasso          [e-mail]
George Clapp             [e-mail]
Thomas Coradetti         [e-mail]
Jonathan Didner          [e-mail]
Thomas Dimitri           [e-mail]
Robert Downs             [e-mail]
Craig Fox                [e-mail]
Richard Fox              [e-mail]
John Gawf                [e-mail]
Shawn Gillam             [e-mail]
Daniel Grossman          [e-mail]
Chris Gunner             [e-mail]
Joel Halpern             [e-mail]
Ronald Jacoby            [e-mail]
B.V. Jagadeesh           [e-mail]
Jan-Olof Jemnemo         [e-mail]
David Kaufman            [e-mail]
Robert Lutz
Andrew Malis             [e-mail]
Glenn McGregor           [e-mail]
William Miskovetz        [e-mail]
Dennis Morris            [e-mail]
Andy Nicholson           [e-mail]
Todd Palgut              [e-mail]
Eric Peterson            [e-mail]
James Philippou          [e-mail]
Venkat Prasad            [e-mail]
David Rand               [e-mail]
Kenneth Rehbehn          [e-mail]
Allen Rochkind           [e-mail]
Robert Roden             [e-mail]
Benny Rodrig             [e-mail]
Paul Serice              [e-mail]
Satya Sharma             [e-mail]
William Simpson          [e-mail]
Keith Sklower            [e-mail]
Timon Sloane             [e-mail]
Steve Suzuki             [e-mail]
Thomas Walsh             [e-mail]
James Watt               [e-mail]
Bradley Wilson           [e-mail]
Honda Wu                 [e-mail]
Mauro Zallocco           [e-mail]