home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
pppext
/
pppext-minutes-92mar.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
8KB
|
192 lines
This is only a rough draft - Megan 04/20/92
18 March 1992
Point-to-Point Protocol Extensions (pppext)
Chair: Brian Lloyd, brian@lloyd.com
Mailing Lists:
General Discussion: ietf-ppp@ucdavis.edu
To Subscribe: ietf-ppp-request@ucdavis.edu
Archive: ucdavis.edu:archive/ppp-archive
IETF PPP
*Appletalk
*LQM
*MIB
*IPX
*Decnet
*CLNP
*Physical Layer
Brian Lloyd distributed a memo titled "The PPP Internetwork Packet
Exchange (IPX) Control Protocol" submitted by Novell. Karl Fox
distributed a PPP Pocket Reference card from Morningstar Technologies.
There will be a delay in the issuance of an RFC for LCP, IPCP, and
Authentication due to an oversite within the IAB. However, there
are not going to be any changes to the drafts prior to becoming RFCs.
So it is safe to implement, and still be in compliance.
Questions re: IP Address Negotiation. The implementor needs to
support old format until PPP becomes a full standard. First check to
see if the peer is using the old format. If so, negotiate IP
addressing using the old algorithm. This procedure applies until PPP
is a full standard. After that, support will not be provided for old
algorithm for IP address negotiation. If you do IP you need to go
ahead and do the new IP address negotiation scheme.
Each of LCP, IP Control, LQM, and Authentication have their own
document.
Brian asked, "how many here are actively working to implement PPP?"
Approximately 12 hands went up.
As for penetration in the market it was noted that BARRNet now runs
PPP on links to member sites.
APPLETALK
Brad Parker of Cayman presented an updated draft of his Appletalk over
PPP document. Feedback from Bill Simpson and Chris Ranch of Novell.
The document was forwarded to the IETF drafts mailing list. Good
review from Appletalk community, supports ARAP. Will support router
to router half routing. Doc will be placed on Merit.edu and
Angband.stanford.edu in addition to usual places.
LINK QUALITY MONITORING (LQM)
The previous version of LQM was not widely implemented so major
changes were deemed acceptable (this choice was made at the Santa Fe
IETF meeting). As a result the general mechanism was redefined.
should be able to determine if a synchronous link is up. Flow control
monitoring not recommend for async. LQM is useful for high speed
point to point between router vendors. LQM will give continuous state
of the link info. This is good for OSPF type link state relative
protocols.
PPP MIB
Frank Kastenholz of Clearpoint (kasten@clearpoint.com) updated MIB for
PPP. Discussion has been open on the mailing list. Frank presented
an update. PPP is a complex protocol so the MIB grew to almost 200
variables. Frank says this MIB has to be trimmed down, but others are
asking for more. This MIB doesn't even address Appletalk, Decnet,
CLNP.
Should this MIB cover NCPs? was asked.
Frank drew on the overhead. There were four columns: Protocol,
Mandatory, Conditional Mandatory (if you are trying to control PPP
instead of just monitor), and Optional. This graph allowed the
members of the WG to assign each variable to a category.
One reason to have lots of MIB variables is the need to configure PPP
in routers via SNMP (the router from NAT was used as an example since
it is only manageable via SNMP). It was suggested that all
configuration variables be in the optional column and get rid of the
Conditional Mandatory column.
Discussion continued as to how necessary it might be to trim down the
variables. It was determined that MIB variables present for debugging
purposes be discarded. Brian requested that Frank Kastenholz, Bill
Simpson, and Glenn McGregor meet to pare down the MIB prior to the
next day's WG meeting.
IPX
Christopher Ranch of Novell took the floor to lead the discussion of
IPX over PPP. The Novell NCP has no options and this is in conflict
with what Shiva has proposed. Brian recommended that Novell and Shiva
hammer out the differences and produce a single unifying document.
The working group indicated that they wanted to see an address
negotiation and a compression option added to Novell's proposal.
Brian also asked Chris to consider adding negotiation of a routing
protocol IF he thinks it would be useful.
DECNET
There appeared to be no progress in the area of DECNet over PPP.
Further work on this subject is awaiting an implementation and/or a
new draft document.
OSI/CLNP
Bill opened discussion with the remark that there is a well-written
document for which there are no implementations. This is a no-option
document that differentiated between the three different kinds of
CLNP. This will be re-addressed when there is an implementation.
Christopher Ranch will forward requests on this to the correct person
at Novell who is beginning an implementation.
BRIDGING
Fred Baker is looking for implementation experiences to document.
3-COM has done bridging over PPP. Currently the document needs to
1) clarify the concept of a virtual ring, and
2) tighten up the language.
19 March 1992 09:00
32-BIT FCS
Bill Simpson stated the issues with 32-bit FCS. These being that DEC
owns patents on a procedure of combining the 32bit and 16bit FCS into
a 48bit FCS to be used while 32bit FCS is being negotiated. Noel
Chiappa said that DEC will make a license to their process freely
available. DEC will provide a general grant of right to use the
technology and will provide a letter to the IETF stating so.
Action item: Karl Fox of Morningstar Technologies, being
a vendor of a company with an implementation, is going to take the
task of getting the letter from DEC releasing the rights to the
process to the world.
PHYSICAL LAYER
Where/how to handle the physical layer information. The PPP mailing
list concluded that the LCP layer is not the place. Bill Simpson
stated that PPP is supposed to run over anything; in other words if
you have two wires you should be able to run PPP. Brian Lloyd
suggested the need for an implementation reference. There was
agreement to this. Someone said this should be an informational RFC.
Items to be covered included: PPP SYNC interface with an eye towards
RS232, V35, V36, RS422/RS449; async implementations; switched
circuits, i.e. Hayes compatible, X21, V25bis dialing; and definition
of physical layer up/down determination; etc.
Questions presented:
How are we going to deal with ISDN? This is a topic of future
discussion and work with the IPLPDN WG.
Chat scripts and dealing with a login sequence on an async link. What
is the other end going to send?
MIB REVISITED
Frank took the floor to revisit the issue of MIB variables. Together
with Bill Simpson, Glenn McGregor, and some input from Jeff Case they
got the number of variables to just over a hundred. This is down from
196. They did not deal with every section, and some still need to be
added for Appletalk, and IPX. It will be necessary to know if and
what will be monitored in IPX over PPP.
Changes: link extensions table is gone, FSM table(s) are gone, these
were deemed to be debugging information. It was decided that it made
more sense to return the link quality reports as a single aggregate
MIB variable instead of permitting each field withing the LQR to be
queried separately. Individual variables in the LQR are not very
useful by themselves plus in order to make sense of the timely
information it is necessary to see a complete "snapshot" in one
operation.
On the philosophy of configurable parameters: the choice seems to be,
a rich set of "knobs" or allowing the vendor to completely control the
initial and desired state of the implementation. There was no
hard-and-fast decision so it was left up to Frank to clean up what was
decided and to post all changes to the MIBs to the mailing list in a
few weeks where discussion will begin anew.