Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12870;
8 Nov 93 11:25 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12866;
8 Nov 93 11:25 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07148;
8 Nov 93 11:25 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12737;
8 Nov 93 11:25 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12733;
8 Nov 93 11:21 EST
Received: from LOBSTER.WELLFLEET.COM by CNRI.Reston.VA.US id aa06996;
8 Nov 93 11:21 EST
Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1)
id AA03080; Mon, 8 Nov 93 11:09:56 EST
Received: from godiva.wellfleet by pobox.wellfleet (4.1/SMI-4.1)
id AA12425; Mon, 8 Nov 93 11:17:33 EST
Date: Mon, 8 Nov 93 11:17:33 EST
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Caralyn Brown
Message-Id: <9311081617.AA12425@pobox.wellfleet>
To: iplpdn@CNRI.Reston.VA.US
Subject: meeting minutes
Please find attached the meeting minutes from the IPLPDN meeting in Houston.
I will be forwarding this to the area directors on Tuesday. If you have any
comments or additions, please send them as soon as possible so that I can
include them before I ship this off.
c
Minutes of the IPLPDN Working Group
Chair:
Caralyn Brown, cbrown@wellfleet.com
Area Directors:
Stev Knowles, stev@ftp.com
Dave Piscitello, dave@mail.bellcore.com
The purpose of re-opening the IP over Large Public Data Networks (IPLPDN)
working group was to clean up some unresolved items, and attend to those items
which have come up after the group became inactive.
The meeting opened with a list of agenda items which we hoped to discuss. These
were:
1. Encapsulation Determination
2. Parameter negotiation
3. Status of updates to RFC 1315, DTE MIB
4. Routing Protocols over Frame Relay
5. Inverse ARP for protocols other than IP
6. Inverse ARP extensions
7. Source Routing over frame relay
1. Encapsulation Determination.
Keith Sklower presented a summary of the internet draft that he has written
entitled Determination of Encapsulation of Multi-protocol Datagrams in
Circuit-switched Environments. The objective of this work is to define a way
in which a receiving station might determine which type of encapsulation,
X.25, Frame Relay or PPP, is used on a ISDN call. This is an issue because of
the fact that ISO prefers X.25, PPP is out there, and the ITU has recently
included access to a Frame Relay switch as an access feature. The document is
not specific to ISDN, but to circuit switched networks where prior
configuration is not easily done.
Several Action items were identified.
Keith Sklower agreed to update the document to remove section 8,
"Out of Band Signaling", change bit inversion parameters ("callee's
algorithm") and remove section 10. Keith has also agreed to clean
up the sections referring to internet drafts.
It was agreed that this draft should be published as an informational
RFC as a statement of applicability for various standards. This will
be done after Keith has updated the document and circulated it to the
working group (via the mailing list) for further comments.
2. Parameter Negotiation.
Keith Sklower presented a summary of the internet draft entitled Parameter
Negotiation over Frame Relay. The fundamental issue is to enable the
negotiation of a few options in the context of the existing RFC 1490
encapsulation and philosophy. There is a similar document being worked in
the PPP extensions working group called PPP over Frame Relay. This document
preposes that once an NCP is negotiated, the encapsulation change to the PPP
encapsulation with the CF NLPID identifier. Each document presupposes
different goals. Parameter negotiation defines how to add certain negotiations
to a 1490 environment, while PPP on frame relay attempts to define how to run
the entire PPP suite over frame relay.
The implication of forwarding both documents is the fact that two
implementations, one using the parameter negotiations document, and one
using PPP over frame relay, might successfully complete negotiation and
then be unable to pass data due to differing data encapsulations.
The decision was reached within the group that the parameter negotiations
document would be modified to clarify that the final data encapsulation would
be as specified in 1490 even after negotiations. It would also be clarified
to specify that, should an implementation decide to negotiate a protocol
for which a PPP encapsulation is defined, but none is defined within 1490
(VJ compression for example), the PPP encoding would be allowed. This
will also allow for the use of the compression schemes being defined in
the PPP extensions working group. Protocols which can be defined within
the context of 1490 will continue to be encapsulated in that manner.
3. Status of updates to RFC 1315.
The draft for the updates to rfc 1315 has expired. Caralyn Brown has agreed
to repost it and set the wheels in motion to get it forwarded.
4. Routing over Frame Relay
Since the disbanding of the original IPLPDN group, there has been much
discussion about how to run various protocols over a frame relay network;
in particular DECnet over frame relay. The group decided that there are
many ways in which to run a protocol over the FR network depending upon
what the configuration is. Joel Halpern and Fred Baker volunteered to
write an informational document covering experience in partial mesh networks.
The document will be posted on the mailing list and discussed there.
5. Inverse ARP for IPX
The group decided that the definition of InARP for IPX might better be handled
by Novell. There were several companies which already have an implementation
of InARP for IPX, the attendees could not remember details. It was decided
that the discussion would take place off-line among those who had already
implemented InARP for IPX. Caralyn Brown agreed to be editor for a document
describing a common method for IPX InARP.
6. Inverse ARP extensions.
During the Ip over ATM discussions, it was felt that InARP was not robust
enough. Specifically, a requesting station could not determine whether an
InARP request was lost, or the responding station did not have an appropriate
answer. It was suggested that InARP be expanded to contain a NAK. The
group did not disagree with the suggestion, but decided that, because this
problem was related to ATM's ARP server, the ATM group should pursue this
work.
7. IEEE 802.5 Source Routing over Frame Relay
Those who were most interested in this topic were not present at the
meeting. It was decided that this should be taken to the mailing list
for further discussion.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13976;
8 Nov 93 12:02 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13972;
8 Nov 93 12:02 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08600;
8 Nov 93 12:02 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13949;
8 Nov 93 12:02 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13945;
8 Nov 93 12:01 EST
Received: from nsco.network.com by CNRI.Reston.VA.US id aa08584;
8 Nov 93 12:01 EST
Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34)
id AA04974; Mon, 8 Nov 93 11:04:12 -0600
Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1)
id AA07334; Mon, 8 Nov 93 11:00:07 CST
Date: Mon, 8 Nov 93 11:00:07 CST
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Joel Halpern
Message-Id: <9311081700.AA07334@anubis.network.com>
To: iplpdn@CNRI.Reston.VA.US
Subject: Re: meeting minutes
Minor nit in the meeting minutes:
While we said during the meeting that compression was one example
of an alternate encapsulation which would use PPP, that is misleading.
Data Compression as an otpion in PPP does not change the PPP protocol
type, and therefore does not affect which of 1490/PPP identification is
used with the packet. If one negotiates full data compression, one simply
compresses whatever data is identified by the identifier.
Thank you,
Joel M. Halpern jmh@network.com
Network Systems Corporation
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17829;
8 Nov 93 14:31 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17824;
8 Nov 93 14:31 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13933;
8 Nov 93 14:31 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17781;
8 Nov 93 14:31 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17777;
8 Nov 93 14:30 EST
Received: from vangogh.CS.Berkeley.EDU by CNRI.Reston.VA.US id aa13906;
8 Nov 93 14:30 EST
Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.4/8.6.3) id LAA08146 for iplpdn@cnri.reston.va.us; Mon, 8 Nov 1993 11:30:54 -0800
Date: Mon, 8 Nov 1993 11:30:54 -0800
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith Sklower
Message-Id: <199311081930.LAA08146@vangogh.CS.Berkeley.EDU>
To: iplpdn@CNRI.Reston.VA.US
Subject: Major nit with minutes/section 8
I did not agree to remove the entirety of the section on out of band signalling.
I agreed to remove the paragraph between section 8 and 8.1.
I did agree to look up the proposed encodings for Bearer capability.
The section is important. It says "Although you can't count on
LLC and BC, if you do want to use them, use them in this way ..."
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21191;
8 Nov 93 16:53 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21187;
8 Nov 93 16:53 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19139;
8 Nov 93 16:53 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21168;
8 Nov 93 16:53 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21164;
8 Nov 93 16:52 EST
Received: from LOBSTER.WELLFLEET.COM by CNRI.Reston.VA.US id aa19114;
8 Nov 93 16:52 EST
Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1)
id AA05860; Mon, 8 Nov 93 16:41:07 EST
Received: from godiva.wellfleet by pobox.wellfleet (4.1/SMI-4.1)
id AA18273; Mon, 8 Nov 93 16:48:44 EST
Date: Mon, 8 Nov 93 16:48:44 EST
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Caralyn Brown
Message-Id: <9311082148.AA18273@pobox.wellfleet>
To: iplpdn@CNRI.Reston.VA.US, sklower@vangogh.cs.berkeley.edu
Subject: Re: Major nit with minutes/section 8
I have updated the minutes accordingly.
c
> From iplpdn-request@ietf.nri.reston.va.us Mon Nov 8 16:11:56 1993
> Date: Mon, 8 Nov 1993 11:30:54 -0800
> Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
> From: Keith Sklower
> To: iplpdn@CNRI.Reston.VA.US
> Subject: Major nit with minutes/section 8
> Content-Length: 342
>
> I did not agree to remove the entirety of the section on out of band signalling.
> I agreed to remove the paragraph between section 8 and 8.1.
>
> I did agree to look up the proposed encodings for Bearer capability.
>
> The section is important. It says "Although you can't count on
> LLC and BC, if you do want to use them, use them in this way ..."
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22392;
8 Nov 93 18:26 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22388;
8 Nov 93 18:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21496;
8 Nov 93 18:26 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22374;
8 Nov 93 18:26 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22370;
8 Nov 93 18:25 EST
Received: from combinetu.combinet.com by CNRI.Reston.VA.US id aa21481;
8 Nov 93 18:25 EST
Received: from snail.combinet.com by combinetu.combinet.com (5.67/1.00)
id AA29277; Mon, 8 Nov 93 15:23:58 -0800
Received: from cc:Mail by snail.combinet.com (1.30/SMTPLink)
id A02622; Mon, 08 Nov 93 15:19:49 PST
Date: Mon, 08 Nov 93 15:19:49 PST
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bob Downs
Message-Id: <9311081519.A02622@snail.combinet.com>
To: iplpdn@CNRI.Reston.VA.US, sklower@vangogh.cs.berkeley.edu
Subject: Re: Major nit with minutes/section 8
Keith Sklower says:
>I did not agree to remove the entirety of the section on out of band
>signalling. I agreed to remove the paragraph between section 8 and 8.1.
>I did agree to look up the proposed encodings for Bearer capability.
>The section is important. It says "Although you can't count on
>LLC and BC, if you do want to use them, use them in this way
..."
I want to comment on a couple of items about ISDN signalling.
The LLC is not a reliable IE in the ISDN signalling. Not all
ISDN switches use LLC signalling all the time.
However, the Bearer Capability Information Element is in every
setup message. It must include a transfer mode and this is coded
as circuit mode or packet mode. Circuit mode implies a clear
channel. Packet mode implies X.25 or Frame Relay though I have
only seen X.25.
There are additional bytes in the BC IE that identify the type of
protocol more explicitly. These are similar to those mentioned
by Keith in the draft as part of the LLC IE. Different countries
may use different IE's to signal the protocol used.
It seems to me that if we are talking about ISDN calls (incoming
or outgoing), then it should be possible to determine whether the
call is clear channel, X.25 or Frame Relay.
Even if different countries use different ways to represent this,
it is known within each country how this encoding works. It is
already the case that other ISDN signalling differs from one
country to another so these differences should not concern us.
It is only necessary to know that if Frame Relay (or X.25) is
available on an ISDN connection and the signalling supports it,
then the ISDN device must be capable of setting and recognizing
the signalling if it is to use these features.
I suggest that the wording of the Parameter Negotiation document
mention both the BC and the LLC as possible ways to determine the
protocol used and that the wording be 'generalized' to allow any
out-of-band signalling that lets the device determine what
protocol is in use; where this signalling is available.
Bob Downs
Combinet
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05515;
9 Nov 93 10:16 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05511;
9 Nov 93 10:16 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09701;
9 Nov 93 10:16 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05458;
9 Nov 93 10:16 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05454;
9 Nov 93 10:12 EST
Received: from uu5.psi.com by CNRI.Reston.VA.US id aa09562; 9 Nov 93 10:12 EST
Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
id AA13400 for ; Tue, 9 Nov 93 09:51:09 -0500
Date: Tue, 9 Nov 93 09:24:44 EST
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Chip Sharp 6424
Received: by teleoscom.com (4.1/3.2.083191-Teleos Communications Inc.)
id AA17423; Tue, 9 Nov 93 09:24:44 EST
Message-Id: <9311091424.AA17423@teleoscom.com>
To: bob@combinet.com
Cc: iplpdn@CNRI.Reston.VA.US, sklower@vangogh.cs.berkeley.edu
In-Reply-To: Bob Downs's message of Mon, 08 Nov 93 15:19:49 PST <9311081519.A02622@snail.combinet.com>
Subject: Major nit with minutes/section 8
>I want to comment on a couple of items about ISDN signalling.
>The LLC is not a reliable IE in the ISDN signalling. Not all
>ISDN switches use LLC signalling all the time.
I agree. LLC is not reliable, especially when going between networks.
>However, the Bearer Capability Information Element is in every
>setup message. It must include a transfer mode and this is coded
>as circuit mode or packet mode. Circuit mode implies a clear
>channel. Packet mode implies X.25 or Frame Relay though I have
>only seen X.25.
Unfortunately, the Bearer Capability is not always reliable as well.
Until, ISUP is implemented worldwide there is always the possibility
that what you send on the origination side will not appear on the
destination side. For example, sometimes a 56 kbit/s call will appear
as a 64 kbit/s call at the destination due to the network dropping the
rate adaption bytes in the Bearer Capability.
As long as the Packet Mode and Frame Relay BC signaling is only
between the endpoint and the nearest switch then it can be relied on.
Chip Sharp
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02693;
10 Nov 93 8:19 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02689;
10 Nov 93 8:19 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07884;
10 Nov 93 8:19 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02596;
10 Nov 93 8:19 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02592;
10 Nov 93 8:15 EST
Received: from LOBSTER.WELLFLEET.COM by CNRI.Reston.VA.US id aa07817;
10 Nov 93 8:15 EST
Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1)
id AA20189; Wed, 10 Nov 93 08:04:47 EST
Received: from godiva.wellfleet by pobox.wellfleet (4.1/SMI-4.1)
id AA12745; Wed, 10 Nov 93 08:12:26 EST
Date: Wed, 10 Nov 93 08:12:26 EST
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Caralyn Brown
Message-Id: <9311101312.AA12745@pobox.wellfleet>
To: dave@mail.bellcore.com, stev@ftp.com
Subject: meeting minutes for IPLPDN meeting
Cc: iplpdn@CNRI.Reston.VA.US
Minutes of the IPLPDN Working Group
Chair:
Caralyn Brown, cbrown@wellfleet.com
Area Directors:
Stev Knowles, stev@ftp.com
Dave Piscitello, dave@mail.bellcore.com
The purpose of re-opening the IP over Large Public Data Networks (IPLPDN)
working group was to clean up some unresolved items, and attend to those items
which have come up after the group became inactive.
The meeting opened with a list of agenda items which we hoped to discuss. These
were:
1. Encapsulation Determination
2. Parameter negotiation
3. Status of updates to RFC 1315, DTE MIB
4. Routing Protocols over Frame Relay
5. Inverse ARP for protocols other than IP
6. Inverse ARP extensions
7. Source Routing over frame relay
1. Encapsulation Determination.
Keith Sklower presented a summary of the internet draft that he has written
entitled Determination of Encapsulation of Multi-protocol Datagrams in
Circuit-switched Environments. The objective of this work is to define a way
in which a receiving station might determine which type of encapsulation,
X.25, Frame Relay or PPP, is used on a ISDN call. This is an issue because of
the fact that ISO prefers X.25, PPP is out there, and the ITU has recently
included access to a Frame Relay switch as an access feature. The document is
not specific to ISDN, but to circuit switched networks where prior
configuration is not easily done.
Several Action items were identified.
Keith Sklower agreed to update the document to remove part of section
8, "Out of Band Signaling", change bit inversion parameters ("callee's
algorithm") and remove section 10. Keith has also agreed to clean
up the sections referring to internet drafts.
It was agreed that this draft should be published as an informational
RFC as a statement of applicability for various standards. This will
be done after Keith has updated the document and circulated it to the
working group (via the mailing list) for further comments.
2. Parameter Negotiation.
Keith Sklower presented a summary of the internet draft entitled Parameter
Negotiation over Frame Relay. The fundamental issue is to enable the
negotiation of a few options in the context of the existing RFC 1490
encapsulation and philosophy. There is a similar document being worked in
the PPP extensions working group called PPP over Frame Relay. This document
preposes that once an NCP is negotiated, the encapsulation change to the PPP
encapsulation with the CF NLPID identifier. Each document presupposes
different goals. Parameter negotiation defines how to add certain negotiations
to a 1490 environment, while PPP on frame relay attempts to define how to run
the entire PPP suite over frame relay.
The implication of forwarding both documents is the fact that two
implementations, one using the parameter negotiations document, and one
using PPP over frame relay, might successfully complete negotiation and
then be unable to pass data due to differing data encapsulations.
The decision was reached within the group that the parameter negotiations
document would be modified to clarify that the final data encapsulation would
be as specified in 1490 even after negotiations. It would also be clarified
to specify that, should an implementation decide to negotiate a protocol
for which a PPP encapsulation is defined, but none is defined within 1490
(VJ compression for example), the PPP encoding would be allowed. Protocols
which can be defined within the context of 1490 will continue to be
encapsulated in that manner.
3. Status of updates to RFC 1315.
The draft for the updates to rfc 1315 has expired. Caralyn Brown has agreed
to repost it and set the wheels in motion to get it forwarded.
4. Routing over Frame Relay
Since the disbanding of the original IPLPDN group, there has been much
discussion about how to run various protocols over a frame relay network;
in particular DECnet over frame relay. The group decided that there are
many ways in which to run a protocol over the FR network depending upon
what the configuration is. Joel Halpern and Fred Baker volunteered to
write an informational document covering experience in partial mesh networks.
The document will be posted on the mailing list and discussed there.
5. Inverse ARP for IPX
The group decided that the definition of InARP for IPX might better be handled
by Novell. There were several companies which already have an implementation
of InARP for IPX, the attendees could not remember details. It was decided
that the discussion would take place off-line among those who had already
implemented InARP for IPX. Caralyn Brown agreed to be editor for a document
describing a common method for IPX InARP.
6. Inverse ARP extensions.
During the Ip over ATM discussions, it was felt that InARP was not robust
enough. Specifically, a requesting station could not determine whether an
InARP request was lost, or the responding station did not have an appropriate
answer. It was suggested that InARP be expanded to contain a NAK. The
group did not disagree with the suggestion, but decided that, because this
problem was related to ATM's ARP server, the ATM group should pursue this
work.
7. IEEE 802.5 Source Routing over Frame Relay
Those who were most interested in this topic were not present at the
meeting. It was decided that this should be taken to the mailing list
for further discussion.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05507;
15 Nov 93 11:45 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05499;
15 Nov 93 11:45 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14099;
15 Nov 93 11:45 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05472;
15 Nov 93 11:45 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04129;
15 Nov 93 10:36 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iplpdn@CNRI.Reston.VA.US
X-Orig-Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-to: Internet-Drafts@CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-iplpdn-frmib-dte-01.txt
Date: Mon, 15 Nov 93 10:35:57 -0500
X-Orig-Sender: cclark@CNRI.Reston.VA.US
Message-ID: <9311151036.aa04129@IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Over Large Public Data
Networks Working Group of the IETF.
Title : Management Information Base for Frame Relay DTEs
Author(s) : C. Brown, F. Baker, C. Carvalho
Filename : draft-ietf-iplpdn-frmib-dte-01.txt
Pages : 30
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing Frame Relay.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-iplpdn-frmib-dte-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-iplpdn-frmib-dte-01.txt".
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19931112115134.I-D@CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-iplpdn-frmib-dte-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iplpdn-frmib-dte-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19931112115134.I-D@CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15194;
19 Nov 93 17:22 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15190;
19 Nov 93 17:22 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02248;
19 Nov 93 17:22 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15070;
19 Nov 93 17:22 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15066;
19 Nov 93 17:20 EST
Received: from fennel.acc.com by CNRI.Reston.VA.US id aa02130;
19 Nov 93 17:20 EST
Received: from by fennel.acc.com (4.1/SMI-4.1)
id AB28817; Fri, 19 Nov 93 14:20:17 PST
Message-Id: <9311192220.AB28817@fennel.acc.com>
X-Sender: fbaker@fennel.acc.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 19 Nov 1993 14:19:20 -0800
To: ietf-ppp@ucdavis.edu
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker
Subject: PPP Meeting Minutes for the IETF Meeting, November 1993
Cc: iplpdn@nri.reston.va.us, minutes@CNRI.Reston.VA.US, cbrown@wellfleet.com,
dave@mail.bellcore.com, stev@ftp.com
PPP Meeting Minutes for the IETF Meeting, November 1993
Two documents were referred to the IESG for consideration as Proposed
Standards without discussion:
draft-ietf-pppext-isdn-03.txt
draft-ietf-pppext-sonet-01.txt
PPP over X.25 (draft-ietf-pppext-x25-02.txt) generated discussion:
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.
Discussion of PPP over Frame Relay:
Issues on the table are:
-- 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 & 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 provide 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.
draft-ietf-pppext-lcpext-04.txt is the obvious place to put this option,
but contains other work that has been waiting and needs to move 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.
An editorial note by the chair: it is not clear that the group reached
an effective consensus concerning the default encapsulation, or that
this consensus represents the many 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...
Dave Rand presented the PPP/LAPB document, draft-ietf-pppext-reliable-
00.txt. After some discussion, the document was recommended for
consideration by the IESG as a Proposed Standard.
Dave Rand then presented the Compression Control Protocol, 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 Bridging document, pppext-for-
bridging-01.txt. Minor revisions were suggested. It is anticipated that
this will go to the IESG by year end.
Thomas Dimitri then presented his NETBEUI/PPP proposal, draft-ietf-
pppext-netbios-fcp-00.txt. This was cut short due to time constraints
and taken to the list.
Keith Sklower then discussed 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 a draft named
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 PPP 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.
Respectfully submitted,
Fred Baker
Chair
=============================================================================
Don't blame ACC; they think I'm nuts too!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14726;
21 Nov 93 14:15 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14722;
21 Nov 93 14:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09107;
21 Nov 93 14:15 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14704;
21 Nov 93 14:15 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14700;
21 Nov 93 14:10 EST
Received: from volitans.MorningStar.Com by CNRI.Reston.VA.US id aa08932;
21 Nov 93 14:09 EST
Received: from via.rmm2.merit.edu by volitans.MorningStar.Com (5.65a/93052901)
id AA15873; Sun, 21 Nov 93 14:01:20 -0500
Date: Sun, 21 Nov 93 10:37:23 EDT
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: William Allen Simpson
Message-Id: <1659.bill.simpson@um.cc.umich.edu>
To: ietf-ppp@ucdavis.edu
Cc: iplpdn@CNRI.Reston.VA.US, minutes@CNRI.Reston.VA.US,
cbrown@wellfleet.com, dave@mail.bellcore.com, stev@ftp.com
Reply-To: bsimpson@morningstar.com
Subject: Re: PPP Meeting Minutes for the IETF Meeting, November 1993
Thank you for finishing the minutes. However, there are several errors.
> Discussion of PPP over Frame Relay:
>
> Issues on the table are:
> -- 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 & Keith's
> documents.
>
I disagree with the issues as stated. The issues were:
-- the interaction with RFC 1490 systems must be determinate.
There was no statement that they were indeterminate, only that
some folks didn't like the determining factor, which is use of
the associated NCP. The problem is there is no determining
factor in RFC 1490 itself.
-- when to use RFC 1490 encapsulation.
The PPP/F-R solution was when there is no NCP negotiated.
-- Disagreement as to the content of PPP/IPLPDN agreements from
Columbus and Amsterdam.
The agreements were spelled out in my message to the list months
ago, and there was no disagreement on the PPP list.
-- Keith's refusal to merge his material with PPP/F-R, as was decided
at Columbus.
There was no technical reason for separation of the drafts.
Kieth simply refused to co-operate.
> The final vote for this results in several options.
>
It should be noted that voting is not the IETF way. The solution adopted
by vote is demonstrably _technically_ incompetent.
The technical problems are discussed in your later editorial note, but I
would like a specific note that voting is unusual in the IETF context,
and was taken because of the high number of OSI/ANSI/IEEE professional
meeting-goers present.
> 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.
>
If this option is chosen, much more than a single sentence will need to
be added.
In fact, much of the draft will need to be re-written, and many warning
messages will need to be added, since Protocol-Reject, Compression,
Reliable operation, Authentication, and several LCP options (MRU, PFC,
Self-Describing-Padding, and Compound-Frames) would be broken. Also,
specific requirements of PPP operation phases would be invalidated.
> An editorial note by the chair: it is not clear that the group reached
> an effective consensus concerning the default encapsulation, or that
> this consensus represents the many 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
I thank the esteemed Chair for his editorial note. Perhaps the
discussion which ensues will obviate the need for a formal procedural
objection to be filed with the IAB, and a formal motion for impeachment
of the IESG member involved.
> 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.
>
I concur and like to add that the previous (planned) joint meetings with
IPLPDN had asked for a statement of applicability. This is:
Applicability
This specification is intended for those implementations which
desire to use facilities which are defined for PPP, such as the
Link Control Protocol, Network-layer Control Protocols,
authentication, and compression.
Since the vote breaks portions of these, if the "new option" is not
negotiated, it would violate the Applicability statement. Therefore,
the "new option" MUST always be negotiated, which means it is not an
option, but a requirement.
> 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.
>
I heartily agree.
Bill.Simpson@um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15459;
21 Nov 93 17:20 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15455;
21 Nov 93 17:20 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12475;
21 Nov 93 17:20 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15446;
21 Nov 93 17:20 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15442;
21 Nov 93 17:19 EST
Received: from ftp.com by CNRI.Reston.VA.US id aa12428; 21 Nov 93 17:19 EST
Received: from wilson.zaphod by ftp.com via PCMAIL with DMSP
id AA28346; Sun, 21 Nov 93 17:18:17 -0500
Date: Sun, 21 Nov 93 17:18:17 -0500
Message-Id: <9311212218.AA28346@ftp.com>
To: bill.simpson@um.cc.umich.edu
Subject: Re: PPP Meeting Minutes for the IETF Meeting, November 1993
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Brad Wilson
Reply-To: wilson@ftp.com
Cc: ietf-ppp@ucdavis.edu, iplpdn@CNRI.Reston.VA.US,
minutes@CNRI.Reston.VA.US, cbrown@wellfleet.com, dave@mail.bellcore.com,
stev@ftp.com
X-Orig-Sender: wilson@ftp.com
Repository: babyoil.ftp.com
Originating-Client: zaphod
>> It should be noted that voting is not the IETF way. The solution adopted
>> by vote is demonstrably _technically_ incompetent.
>>
>> The technical problems are discussed in your later editorial note, but I
>> would like a specific note that voting is unusual in the IETF context,
>> and was taken because of the high number of OSI/ANSI/IEEE professional
>> meeting-goers present.
I don't feel that was why a vote was taken ... the way I saw it was:
Two conflicting documents were available. A consensus need to be
reached on one document or the other. Neither person was ready to
accept the other's document as is. There are demonstratable problems
with using 1490 encapsulation after option negotiation; however,
those present felt that ensuring compatibility with older software
and not changing their microcode was fairly important. Therefore,
the vote was taken because we had two non-converging opinions. The
majority of the people in the room felt comfortable with the possible
problem with 1490 encapsulation as proposed.
There were problems with *BOTH* sides of aisle. Most (in attendance)
felt that the action accepted by vote was the most appropriate. There
are just some times when consensus isn't going to work.
(o o)
--------------------------------------------------------------ooO-(_)-Ooo---
Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297
Not speaking for FTP Software, Inc. Internet Email: wilson@ftp.com
----------------------------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02198;
22 Nov 93 10:23 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02194;
22 Nov 93 10:23 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03759;
22 Nov 93 10:23 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02108;
22 Nov 93 10:23 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02102;
22 Nov 93 10:21 EST
Received: from ftp.com by CNRI.Reston.VA.US id aa03712; 22 Nov 93 10:21 EST
Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP
id AA11042; Mon, 22 Nov 93 10:20:59 -0500
Date: Mon, 22 Nov 93 10:20:59 -0500
Message-Id: <9311221520.AA11042@ftp.com>
To: bsimpson@morningstar.com
Subject: Re: PPP Meeting Minutes for the IETF Meeting, November 1993
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: stev knowles
Cc: ietf-ppp@ucdavis.edu, iplpdn@CNRI.Reston.VA.US,
minutes@CNRI.Reston.VA.US, cbrown@wellfleet.com, dave@mail.bellcore.com,
stev@ftp.com, iesg@CNRI.Reston.VA.US, iab@isi.edu
X-Orig-Sender: stev@ftp.com
Repository: babyoil.ftp.com
Originating-Client: d-cell.ftp.com
>I thank the esteemed Chair for his editorial note. Perhaps the
>discussion which ensues will obviate the need for a formal procedural
>objection to be filed with the IAB, and a formal motion for impeachment
>of the IESG member involved.
if you intend to have your IESG representative removed, you shoudl talk to
phil gross, the IESG chair, at pgross@ans.net. if you are interested in
a formal complaint to the IAB, i would suggest you talk to their chair,
christian huitema, at christian.huitema@sophia.inria.fr.
your comments on the meeting minutes are appreciated, your personal
comments on those attending the meeting and your threats are
un-necessary.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03301;
22 Nov 93 10:59 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03296;
22 Nov 93 10:59 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04936;
22 Nov 93 10:59 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03277;
22 Nov 93 10:59 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03273;
22 Nov 93 10:59 EST
Received: from sprintf.merit.edu by CNRI.Reston.VA.US id aa04918;
22 Nov 93 10:59 EST
Received: by sprintf.merit.edu (5.64/1123-1.0-X.500)
id AA27492; Mon, 22 Nov 93 10:59:36 -0500
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: BENJAMIN.ABARBANEL@adn.sprint.com
Received: by sprint.com (SXG 7.0a/sprintf2.0) with X.400
id 00gwC7Xwm001; 22 Nov 93 15:58:26 UT
Date: 22 Nov 93 10:32:55-0500
P1-Message-Id: US*TELEMAIL;KGJD-5741-7581/27
To: iplpdn@CNRI.Reston.VA.US
Subject: Join Frame Relay Forum
Message-Id:
Gentlemen:
I am currently doing alot of pioneering work in the Frame Relay, ATM, LAN
arenas. I would like to keep abreast of all new FR discussions, could you join
me into the Frame Relay Forum user group.
Thank You,
Ben Abarbanel (703)689-7125
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03315;
22 Nov 93 10:59 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03310;
22 Nov 93 10:59 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04947;
22 Nov 93 10:59 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03284;
22 Nov 93 10:59 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03279;
22 Nov 93 10:59 EST
Received: from sprintf.merit.edu by CNRI.Reston.VA.US id aa04928;
22 Nov 93 10:59 EST
Received: by sprintf.merit.edu (5.64/1123-1.0-X.500)
id AA27496; Mon, 22 Nov 93 10:59:37 -0500
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: BENJAMIN.ABARBANEL@adn.sprint.com
Received: by sprint.com (SXG 7.0a/sprintf2.0) with X.400
id 00gwC7Y8g001; 22 Nov 93 15:58:22 UT
Date: 22 Nov 93 10:31:43-0500
P1-Message-Id: US*TELEMAIL;DGJD-5741-7406/27
To: iplpdn@CNRI.Reston.VA.US
Cc: ROY.SPITZER@adn.sprint.com, ROBERT.C.LICHT@adn.sprint.com,
/DD.UN=FR.ACC/O=ADN/ADMD=TELEMAIL/C=US/@sprint.com
Subject: ARP described in RFC1490
Message-Id:
Gentlemen:
I have been looking at RFC1490 specifically at the ARP and Inverse ARP
description and although I understand that both ends of the network connectio
n
are conveying each others Frame Relay DLCI numbers, I don't see what routing
benefit it has in a tightly closed DLCI/PVC connection. Could you elaborate
a little on how this information is used with perhapes some examples.
I am looking at a configuration where we have a Frame Relay Node being manage
d
by primary (MOM) NMS located on a remote lan and its IP and DLCI/PVC addresse
s
are defined at system configuration time. And a potential for Secondary NMS's
whose IP address may not be known but just the DLCI/PVC address is known at
least to the LAN router point as shown below:
-------------- --------------- |------------|
| LAN | | Frame Relay | | Our FR |
| | --- ROUTER ---| WAN |---| Node being |
|--|-------|-| | | | | Managed |
| | | |_____________| |------------|
|-----|--| |-|------| | |
|(MOM)NMS| | NMS2 | | |
|known | |Unknown | Configured
|IP Addrs| |IP Addrs|
|--------| |--------|
1. Does the ARP protocol provide a way for the Router to converse with our
FR node and identify each IP node attached on its LAN?
2. How is the addressing referenced via the RFCs?
3. Do we have to be able to learn the unknown IP addresses in our node so we
could convey this IP address to the router at some later point?
4. If the answer to these questions are very long could you recommand a good
text book that covers this implementation configuration?
Cheers,
Ben Abarbanel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15240;
22 Nov 93 21:25 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15236;
22 Nov 93 21:25 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21282;
22 Nov 93 21:25 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15226;
22 Nov 93 21:25 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15222;
22 Nov 93 21:23 EST
Received: from fennel.acc.com by CNRI.Reston.VA.US id aa21248;
22 Nov 93 21:23 EST
Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1)
id AA27724; Mon, 22 Nov 93 18:22:57 PST
Message-Id: <9311230222.AA27724@fennel.acc.com>
X-Sender: fbaker@fennel.acc.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 22 Nov 1993 18:22:15 -0800
To: bill.simpson@um.cc.umich.edu
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker
Subject: Re: PPP Meeting Minutes for the IETF Meeting, November 1993
Cc: ietf-ppp@ucdavis.edu, iplpdn@CNRI.Reston.VA.US, cbrown@wellfleet.com,
dave@mail.bellcore.com, stev@ftp.com
> -- Keith's refusal to merge his material with PPP/F-R, as was decided
> at Columbus.
> There was no technical reason for separation of the drafts.
> Keith simply refused to co-operate.
I agree that there was no technical reason to separate the drafts. I think
your understanding of the situation leading up to this is shared by Keith,
in mirror image. The price of being considered to have "co-operated" was
unacceptable both in personal dynamics and in objectives not acheived.
>> The final vote for this results in several options.
>>
>It should be noted that voting is not the IETF way. The solution adopted
>by vote is demonstrably _technically_ incompetent.
Heaven forbid that there should diversity among us.
Let me discuss for a moment the dynamics of the meeting. I had several -
more than two - groups of people in the room who were very vocal for
certain positions, and a much larger group of people who couldn't or didn't
choose to get a word in edgewise. With many present, there was room for
compromise, and major frustration that a viable compromise could not be
reached. For some, I'm not sure that there existed a viable compromise. I
had some in the room who considered it necessary to challenge every
statement I made, literally starting with the first statement. Running such
a meeting is not for the faint of heart.
I tried to summarize positions and take straw votes on them, not as a way
of making a final decision, but as a way of crystalizing the questions and
determining whether any consensus was forming, and if so, what it was. As I
noted in the minutes, I do not believe that we acheived a consensus
position on the issue of what the default encapsulation for data should be
after its NCP had been negotiated on a Frame Relay link. Had I been trying
to force the vote to be the conclusion, we would have stopped the debate
about two hours earlier than we did, and all walked away even madder than
we did.
The polls that I took had nothing to do with perspectives hallowed by ANSI
involvement; if they had, a multi-month review period, mandatory written
reponses to "NO" votes, and many other procedures beyond straw polls would
have been required.
>> 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.
>>
>If this option is chosen, much more than a single sentence will need to
>be added.
>
>In fact, much of the draft will need to be re-written, and many warning
>messages will need to be added, since Protocol-Reject, Compression,
>Reliable operation, Authentication, and several LCP options (MRU, PFC,
>Self-Describing-Padding, and Compound-Frames) would be broken. Also,
>specific requirements of PPP operation phases would be invalidated.
It would probably be helpful if you documented the technical problems in a
manner that we can all objectively consider and discuss, as this is the
heart of the issue before us.
>I thank the esteemed Chair for his editorial note. Perhaps the
>discussion which ensues will obviate the need for a formal procedural
>objection to be filed with the IAB, and a formal motion for impeachment
>of the IESG member involved.
The mechanisms you require are available to you as they are to anyone else.
Plan on your own behavior in context being reviewed as well.
=============================================================================
Don't blame ACC; they think I'm nuts too!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14754;
28 Nov 93 14:39 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14750;
28 Nov 93 14:39 EST
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa25771;
28 Nov 93 14:39 EST
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.4/1.2)
id MAA22103; Sun, 28 Nov 1993 12:39:22 -0700
Received: from localhost by noc-gw.lanl.gov (8.6.4/SMI-4.1)
id MAA14106; Sun, 28 Nov 1993 12:39:20 -0700
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.4/SMI-4.1)
id MAA14103; Sun, 28 Nov 1993 12:39:19 -0700
Received: from worldlink.worldlink.com by mailhost.lanl.gov (8.6.4/1.2)
id MAA22090; Sun, 28 Nov 1993 12:38:06 -0700
Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink)
id AA04309; Sun, 28 Nov 93 14:38:03 -0500
Date: Sun, 28 Nov 93 14:38:03 -0500
Message-Id: <9311281938.AA04309@worldlink.worldlink.com>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: David Piscitello
To: iesg@CNRI.Reston.VA.US, tuba@lanl.gov, atm@hpl.hp.com
Cc: ietf-ppp@ucdavis.edu, iplpdn@CNRI.Reston.VA.US,
big-internet@munnari.oz.au
Subject: confirming rumors...
Hi,
Some of you may have heard that I've resigned from Bellcore,
to pursue a new career. I will continue to serve as an INT
AD at least until my term is over. Stev Knowles has picked up
a great deal of the load while I've sorted things out, and
I want to publicly thank him. I expect to be up and operational
by December 4, 1993.
I'll also continue to participate in IPng activities, esp. TUBA.
Thanks for your patience over the last month. I've allowed
some things to fall into a black hole, and for this I apologize;
I'm slowly crawling out of the hole, so if you can bear with
me for one more week, I'd appreciate it.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28766;
29 Nov 93 10:47 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28762;
29 Nov 93 10:47 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12456;
29 Nov 93 10:47 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28739;
29 Nov 93 10:47 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28735;
29 Nov 93 10:46 EST
Received: from corp.timeplex.com by CNRI.Reston.VA.US id aa12443;
29 Nov 93 10:46 EST
Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF #2740 ) id
<01H5VV8CNJ9C90MTLP@sys30.timeplex.com>; Mon, 29 Nov 1993 10:43:10 EDT
Received: from localhost by maelstrom.timeplex.com (4.1/SMI-4.1) id AA14578;
Mon, 29 Nov 93 08:12:08 EST
Date: 29 Nov 1993 08:12:07 -0500
X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andy Malis
Subject: Re: confirming rumors...
In-reply-to: Your message of "Sun, 28 Nov 1993 14:38:03 EST."
<9311281938.AA04309@worldlink.worldlink.com>
To: David Piscitello
Cc: ietf-ppp@ucdavis.edu, iplpdn@CNRI.Reston.VA.US,
big-internet@munnari.oz.au, malis@maelstrom.timeplex.com
Message-id: <9311291312.AA14578@maelstrom.timeplex.com>
Content-transfer-encoding: 7BIT
Dave,
Congrats! Are you ready to publicly state what you're going to be doing?
Cheers,
Andy