Subject: PPP over AAL5 v05 ID

From: [email-masked] (luna3!gmg)
Date: Fri, 10 Apr 1998 22:41:05 -0400

Hi,
	Attached below is a copy of an E-mail thread between David Allan,
myself, the co-authors, and others concerning section 8 within v05 of the
ID. It is repro'd here with Dave's permission, but with most E-mail headers
snipped for the sake of brevity. The first E-mail also has the diffs between
v04 and v05.

	I'm posting this E-mail exchange to the list because it discusses how
to respond to the PPP encapsulation changing unexpectedly. Since v05 mandates
support of *both* VC-mux'd and LCC encapsulated PPP, the procedure described
in section 8 has become important so that implementations can assure recovery
from PVC configuration mistakes.

	George
=========
>From gmg Fri Apr  3 10:34 EST 1998
Date: Fri, 3 Apr 1998 10:34:10 -0500
From: [email-masked] (luna3!gmg)
To: [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked]
Cc: [email-masked]
Subject: PPP over AAL5 ID v05
Content-Length: 25509

Hi folks,

	As per our discussions in Los Angles, I've revised the PPP over AAL5
Internet Draft to version 5. To make sure we're all in sync before doing the
wider publication, I've sent this E-mail to both the co-authors and all those
parties who were present at L. A. whom I think would have an interest in the
revisions. If there are additional stakeholders whom I've missed, please
contact me.

	The ID's complete text is attached below, after the "diff" output.
I've snipped out of the "diff" output all the irrelevant changes. The v05
text is marked with "<" and the v04 text is marked with ">".

	Please review at your earliest convienance.  I will be sending
the final v05 edition to [email-masked] with all of your comments
folded in at COB next Tuesday.

Thank you.

	George
	(908) 580-4589

The main V5 versus V4 change is in section 4:

182,185c161,163
<      2. MUST support LLC encapsulated PPP payloads on PVCs as described
<      in section 6 below by mutual configuration or negotiation of both
<      end points.  This technique is referred to as "LLC encapsulated
<      PPP".
---
>      2.  MAY use LLC encapsulated PPP payloads on PVCs as described in
>      section 6 below by mutual configuration or negotiation of both end
>      points.  This technique is referred to as "LLC encapsulated PPP".

195,199c181,183
< use LLC encapsulated PPP payloads.  Frame Relay/ATM FRF.8 inter-working
< units are exempted from the requirement to support VC-multiplexed PPP.
< This exemption allows the FR/ATM IWU to remain compliant with FRF.8 when
< the PPP over AAL5 end point is inter-operating with an RFC1973 end
< point.
---
> use LLC encapsulated PPP payloads.  Implementations that wish to inter-
> operate with all potential end points MUST implement LLC-encapsulated
> payloads.

In section 6, a redundant sentance was deleted:
271c256,258
< multiplexed PPP over AAL5.
---
> multiplexed PPP over AAL5.  LLC encapsulated PPP minimizes the ATM/Frame
> Relay inter-working translation complexity that occurs when a VCC is
> connected to an RFC 1973 compliant end point.

Section 6 is clarified as per a comment from Dirk Van Aken of Alcatel and
Phil Rakity of Flowpoint (figure 3 was also changed):
293c274
<      4. followed by the PPP information field as per Figure 2.
---
>      4. followed by the PPP information field.

Section 7 entitled "Out-Of-Band Control Plane Signaling":
354c344
< offers LLC-encapsulated PPP in the caller's request.  The called
---
> offers VC-multiplexed PPP in the caller's request.  The called

358c348
< negotiate the use of LLC-encapsulated PPP.
---
> negotiate the use of VC-multiplexed PPP.

Added to section 9, "LCP Configuration Options" to reflect UNH IOL
experience:
441,454d430
< Implementation Note:
<      When an ATM AAL5 PVC is in the "Stopped" state, it is recommended
<      that the implementation wait for Configure-Requests.  See the
<      implementation option in reference [1] section 4.2, the "Stopped
<      State" sub-section.

... snip draft-ietf-pppext-aal5-05.text....

>From [email-masked] Wed Apr  8 15:13 EDT 1998
... snip E-mail header ....
Subject: RE: PPP over AAL5 ID v05
Date: Wed, 8 Apr 1998 13:12:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Content-Length: 900
Status: R

George et al:

In general I am happy with the I-D but section 8 still confuses me. If
encapsulation is negotiated or provisioned, then it cannot unexpectedly
change state, and expecting some form of heuristic to recognize some
allegedly valid change seems a bit perverse. 

My feeling is that some editing turn-on-off failed . My edit would be that
the first several paras. of the section should be deleted and the last 4
paras kept (starting with "Once PPP has entered...." with minor editing to
indicate that deviations from provisioned (PVC) or negotiated (SVC)
encapsulation are treated as such (call cleared-SVC or NCP/LCP tear
down-PVC) regardless of the NCP state. Suggested text:

"If a frame arrives deviating from the provisioned/negotiated encapsulation
then the PPP link MUST:..."

The rest appears fine!

Regards
Dave

-----------------------
Dave Allan
Nortel PDN Architecture Team

>From [email-masked] Wed Apr  8 21:02 EDT 1998
... snip E-mail header ...
Subject: RE: PPP over AAL5 ID v05
Date: Wed, 8 Apr 1998 19:02:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Content-Length: 2388
Status: R

Joel:

I think we are in agreement as to the general thrust (no changing of horse
in midstream), you have defined how the system would react more accurately.

So based upon your thinking, if the session is up, then a dynamic change in
encap will be percieved as garbage. I presume that this would not be
sufficient grounds to drop an SVC or terminate an NCP/LCP on a PVC
immediately. I'd just silently discard everything and assume that sanity
would eventually prevail. Actual behavior I suspect is that LCP loopbacks
would eventually crap out and the system would take some higher level
action.

If the encap is not what I expect prior to establishing a PPP session, I
will just silently discard all frames that are not well formed and (for SVC)
call clearing would be a matter of local policy and good implementations.
(If no valid PPP session established after X seconds, drop the line and
reclaim the port).

Strikes me that simple elimination of section 8 is the correct
course....does that cover it?

Regards
Dave

-----------------------
Dave Allan
Nortel PDN Architecture Team

>From gmg Thu Apr  9 11:46 EDT 1998
... snip E-mail header ....
Subject: RE: PPP over AAL5 ID v05
Content-Type: text
Content-Length: 1406

Hi Dave,
	As you might gather from the ID announcement on the IETF list, the
cow has already left the barn for v05. Sorry, but as promised I had submitted
the drafts 22:00 EST last Tuesday.

	I'm puzzled why section 8 is confusing for you. At this point, I had
been hoping not to do further edits on the ID text unless it said something
really "wrong".

	Perhaps section 8 would make more sense if one thought about a PVC
that has its LCP in the "Stopped" state (see the new implementation note
in section 9). Let's assume that the RAS is listening for an initial
"Config-Request" from an ADSL subscriber. Suppose it is possible for the
subscriber to inadvertantly and uni-laterally change their PPP encapsulation
by accident (Bart Simpson pushed the wrong u-soft PVC configuration button ;-).
The subscriber starts their "dial-up", which starts sending LCP Config-Requests
to the RAS. The RAS detects and then switchs to the new encapsulation by
examining the first several bytes of the PPP/AAL5 LCP payload. Once the LCP
negotiation completes, any subsequent change in the encapsulation causes the
PVC to flag an error and enter Termination state (or else SVC hang up)

	The only potential drawback that I could see happen is when changing
from VC-mux'd to LLC-encap PPP dynamically is introducing other LLC-encap
non-PPP protocols after the connection originally did not have them configured.

	George

>From [email-masked] Thu Apr  9 14:59 EDT 1998
... snip E-mail header ...
Subject: RE: PPP over AAL5 ID v05
Date: Thu, 9 Apr 1998 12:33:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Content-Length: 2457
Status: R

So your suggestion is that the RAS is encap. agnostic when in the "idle"
state and discovers religion once a session has started? I gather that what
you are really trying to achieve is a RAS that requires no provisioning
vis-a-vis encap. at the expense that it must parse and validate multiple
frame formats. If so, then that should have been explicitly stated.  

I am nervous about that as a general mechanism of going forward as there are
devices (e.g. FRF.8) that are exempt from meeting that (unstated)
requirement. 

Dave
-----------------------
Dave Allan
Nortel PDN Architecture Team

>From gmg Thu Apr  9 16:37 EDT 1998
... snip E-mail header ....
Subject: RE: PPP over AAL5 ID v05
Content-Type: text
Content-Length: 969
Status: R

Hi,
	In retrospect, section 8 was added in reaction to the advent of
LLC encapsulation being added to the ID. The goal was to recover from
the potential PVC configuration errors. Making the RAS end point
configuration simpler and dynamic was an unintended benefit. Unfortunately,
when Bart Simpon clicks the wrong button, and re-configures his PVC to
VC-mux'd PPP mode, then his PVC connection to an ATM/FR IWU will break.
This particular scenario is not good ;-(....

	However, I would argue that at least we've managed to reduce the
probability of a PVC mis-configuration breaking the link to near zero. This
is the best we can do, and I might add, it does *alot*. Network service
providers will probably select one PPP encapsulation across their whole
network.  Only those subscribers who over-ride that policy AND are connected
to an ATM/FR IWU are gonna get into trouble.

This discourse probably has merit being re-send to the PPP list.
Any objections?

	George

>From [email-masked] Thu Apr  9 17:53 EDT 1998
... snip E-mail header...
Subject: RE: PPP over AAL5 ID v05
Date: Thu, 9 Apr 1998 17:51:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Content-Length: 1994
Status: R

George:

I can't comment on how this affects any gate budgets as I've traditionally
been more arch-S/W oriented but I do see the value in "being generous in
what I receive". 

If there is a question, it is if there is a mechanism in FRF.8 IWUs to
actually diagnose the result of Bart's roving finger once it frappez le fan?
e.g. an uninterworkable frame count.

As for posting this, I have not problem, ultimately we are clarifying
somthing, I don't think we are creating controversy. And if we are, we'll
find out ;-)

Dave
-----------------------
Dave Allan
Nortel PDN Architecture Team