Subject: PPPEXT WG minutes from LA

From: Matt Holdrege <[email-masked]>
Date: Wed, 01 Apr 1998 16:07:35 -0800

Point-to-Point Protocol Extensions Working Group Minutes

The PPPext working group met in two sessions, Monday 30 March 1998 at
15:30 - 17:30, and Tuesday 31 March 1998 from 09:00 to 10:00.  Matt
Holdrege was chairing in place of Karl Fox, who was unable to attend.
Minutes were taken by Andy Malis.

Session 1:

Ken Peirce presented L2TP integration with MPLS

Ken gave an overview of MPLS and how it and L2TP could relate to each
other. The purpose of his draft is to see if the MPLS label could be
used to provide a gross-level QoS and performance specifier on the path.
Two possible uses are:

1. Allow the LNS to take advantage of knowledge of existing label
   switched paths - explicit routes for load balancing.
2. Allow the LNS to "seed" the MPLS mlabel stack to permit fast flow
   recognition when it reaches the LNS from the LAC.

Question during discussion: L2TP has a protocol to allow you to
negotiate the mlabel through the AVP.  Is there precedent for this, and
can other protocols do this?  Answer: Not yet, but a similar approach
has been discussed in the MPLS group regarding RSVP.  You can use this
method to set up an explicit route for the tunnel.

Ken Peirce also presented L2TP and Differential Services.

Ken gave an introduction to the work in the diff-serv working group.
The current strawman proposal uses a five-bit "Per-hop behavior", one
bit of "In/Out", and two currently unused bits (N.B.: the diff-serv
group dropped the "In/Out" bit later in the week).

A host will make an explicit bandwidth request to a bandwidth broker.
The LNS will use the diff-serv byte to tell the LAC the appropriate
value of the byte in the IPv4 header for a call.  The LAC may suggest a
value, but should consider a value suggested by the LNS to take
precedence.

The diff-serv octet allows differentiated services to be applied on a
per-call basis.   You can do differentiated services within a tunnel,
and then put a diff-serv octet on the packets for the tunnel itself.

Ken intends to ask the PPPext WG to standardize these two drafts.

Dave Allan presented his MARS Proxy draft.

This was originally presented at the ADSL BOF at the Washington IETF
meeting.  Starting with the PPP over ATM model for ADSL, this draft
allows the provider to add IP multicast for bandwidth-intensive
applications.  It will use an ATM point-to-multipoint tree instead of
PPP over ATM point-to-point connections for the data path.

Direct end-host access to MARS has several issues, including
provisioning, authentication, and VC frugality, so he is proposing that
a proxy be used on behalf of the end users.  His proposal is to use a
PAP/CHAP authenticated PPP/ATM VC and IGMP.  The RAS interworks the IGMP
and MARS interaction.

The draft allows you to use ATM multicasting or a multicast server
(MCS).  The MARS proxy will be run by the server provider on behalf of
the clients, which have a PPP connection to the proxy.  The client uses
IGMP to interact with the proxy, just as if it were on a LAN.  The MARS
proxy then interworks that into the MARS protocol on behalf of the end
client.

There are several issues:
1. Redirected packet detection.  This needs to use type 2 encapsulation,
   which has MTU implications.
2. The subnet model is broken by this approach.  PPP uses host routes,
   there is no subnet.
3. Use of the source host address and source protocol address changes to
   permit a proxy to issue a join on behalf of a client.
4. MARS implementations must track group membership by cluster member
   ID, not ATM address.
5. The MARS client must be able to accept incoming calls - there is not
   current mechanism to authenticate those calls.

There was one question from the audience: You've requested some changes
to MARS multicast infrastructure.  You are augmenting the PPP session
with the multicast service, but this would have been better presented in
the ION group?   Andy Malis answered this question, stating that this
isn't possible due to the current IESG policy to not take on new work in
the ion working group, to give the group a chance to get implementation
and interoperability experience with its current set of protocols.

Bill Palter and Mark Townsley presented an L2TP update.

The current L2TP schedule is:

2/23: PPP CIUG interoperability workshop, third workshop with L2TP
implementations present, numerous interoperable implementations

3/14: draft 10 was posted to the L2TP mailing list.   No bits on the
wire changed, just clarifications in the text.

3/15: Karl Fox issued a 2nd WG last call.

3/19: Draft 10 rev II (aka draft 11) was posted to the L2TP mailing list
with apologies.

3/20: Karl sent email to the area directors to recommend that L2TP be
published as a Proposed Standard RFC.  This will occur once the internet
draft blackout period ends, and the final version of the draft is
available in the internet-drafts directory.

There is already lots of interoperability experience; however, there
will be another interoperability bakeoff after the next IETF.

Question from George Gross: Since this moving to Proposed status, can
the framing issue (how to carry non-HLDC framing over L2TP) be
revisited?  Answer: No, not at this time, but later.  But it would need
a lot of consensus to change at this time, and would need to be done in
a separate document.  This would really be an extension that can be in a
separate draft.

Glen Zorn spoke on MS-MPPE, MS-CHAP, and character set/language
negotiation in LCP.

The Microsoft specifications are informational documents describing
proprietary documents, and the only comments allowed are regarding their
completeness or understandability.  The important part is that people be
able to implement the protocols as documented.

He asked for comments on the MS-CHAP document.  There were none.

He asked for comments on the MS-MPPE document.  He's already received a
number of comments, and has revised it twice already.  Most of the
changes are clarifications and examples.

The third draft is non-proprietary and standards track, and technical
comments are invited.  Question from Craig Fox: There was concern
regarding string matching in the options in the specification, and
whether we can at least list the valid strings, and have numbers
associated with them.  However, there is a problem with this: there is
already a list of character sets and languages with IANA, and we would
have to ask IANA to number them and publish them with their numbers.
Answer: This will be investigated.  Craig volunteered to enumerate the
character sets in order to present the enumerated list to IANA.  This
would modify the draft to make the length of the string three or four,
and just use the numbers.  There was also discussion on possibly
improving the negotiation procedure.  The spec will allow multiple
languages and character sets in a single request, and if you ACK more
than one, then the first one in the ACK will be the one used.  There was
a comment that this may conflict with standard PPP option mechanisms.
If the option is rejected, it goes to the default.

There was a suggestion to support more than one option in the configure
request, because you don't know how the server is going to be
configured.  This will be taken to the list - there was no final
decision made in the group.

There were several questions concerning details in the MPPE draft, which
Glen answered.  What does the MPPE receiver do when the flush bit is set
because of compression expansion?  Does the key get updated, or does it
go back to the original key?  A: The key only gets updated whenever
there is data loss, or when the flush bit is set (it is being treated as
packet loss).  Q: You're initializing with the current key, rather than
rekeying?  A: The receiver must reinitialize its tables but does not
rekey.  But you do rekey in stateless mode on every packet. This will be
further discussed offline and then they will let the list know the
result.

George Gross spoke on PPP over AAL5.  George announced a compromise
agreement for PPP over AAL5 to allow the draft to be approved by the
IESG.  The IESG was concerned about interoperability, especially when
interworking with an RFC 1973 (PPP over FR) endpoint.  The essence is
that the internet draft will require both VC-multiplexed and
multiprotocol-encapsulated PPP in order to be conformant.  There will
also be modifications on the signaling section, and an exception to the
VC-multiplexed requirement for interworking with RFC 1973.

There was an interoperability testing event at UNH last week, and George
will be making some updates to the draft based upon that experience.

Matt Holdrege asked the group whether L2TP over non-IP media, such as
AAL5, is important, and whether the WG should be working on L2TP over
AAL5 in particular.  This was felt to be important several years ago,
but it seems to have cooled off somewhat.  A comment was made that L2TP
over FR might make more sense than AAL5.  There was another comment made
that there needs to be a multiplexing mechanism to allow multiple L2TP
sessions.  There are also people looking at L2TP bridges.  Rohit Verma
said that he would be willing to work on L2TP over non-IP networks.
Mark said that the L2TP draft is already pretty self-sufficient (just
section 8 is IP-specific).  Rohit said that there were some open issues
that could be discussed in the draft.

Carsten Bormann spoke about ISSLOW issues: Integrated Services on
low-bitrate links.

Up to now, Integrated Services has been on high-speed links only.
ISSLOW was meant to extend this to modem lines up to 56 Kbps, ISDN, low
speed leased lines up to 128K, fractional T1, etc.

The three problems are:
1. Low-speed links blocked by large frames, which kill latency for
   real-time packets, fixed by fragmentation and suspend/resume;
2. The header overhead, fixed with header compression;
3. It's difficult to reserve bandwidth when header compression produces
   variable results.  This is still an open issue.

One thing that may come up in this group to help support ISSLOW is link
characteristic determination, such as round-trip delay.

Another open issue is real-time encapsulation, which is need to minimize
worst case end-to-end delay for real-time streams, maximize available
bandwidth, minimize overhead, and be predicable enough for admission
control.  It cooperate nicely with PPP, work with existing chips and
router systems, and be future proof (for example, modem protocol
developments).

The possible design avenues are abort/suspend, cell-oriented + final bit
vs. suspend/resume,  where to place the suspend information, how many
priorities, and where to put error control.

Two solutions need to be provided:
1. Transmitter fragments large packets down to the latency goal (for
   example, about 128 bytes).  You must pay fragment overhead (similar
   to cell tax for ATM).  PPP multilink is almost it.
2. For the best latency, send an interrupt packet immediately.  You need
   a way to suspend the frame being sent.

Challenge: Define a scheme where fragmenters and suspenders can happily
interoperate.  Fortunately, this is just a differentiation on the
sending side.

PPP multilink has one problem: the serial sequence numbering does not
allow suspension, but you can still send intervening non-multilink
packets.  So you can send two multilink fragments separated by a
non-multilink packet.  However, this only provides a single level of
priority.

If you need more than two levels, you need to add two "class" bits to
the standard PPP multilink header.  This allows 4 instances of the PPP
multilink protocol to run in parallel with four sequence spaces.    This
is in draft-issll-isslow-mcml-0x.txt.

Real-time framing allows suspending of packets at any time.  This is
compatible with type-2 receivers (which have basic HDLC hardware).
Multilink support is optional.  The approach is that there is a
second-level scan.  HDLC framing is unchanged, but in the payload of the
HDLC frames, there is a fragment suspend escape (FSE), 0xDE.

There is a new compressed multilink header, from three bytes to one
byte: 3-bit sequence number, 3-bit class number, one R bit (which is the
inverted B bit), and a "1" in the low bit.  The bit combination 0xFF
cannot be used, so class 7 cannot be suspended and does not need a
sequence number.  0xFF is an escape back to normal PPP headers.

When a 0xDE occurs in the data, it has to be escaped using a form of
byte stuffing so that a suspension does not occur.  There is a maximum
expansion of 25%.

There are MRU issues, and a single-automaton implementation requires a
two-byte delay for CRC.

There are two new LCP options: Multilink header format option (27), and
Prefix elision (26).  They could not use option 18 for the former
because of backwards compatibility issues.  The latter is somewhat odd,
in that it negotiates the behavior of the sender rather than the
receiver.

How does this relate to Consistent Overhead Bytes Stuffing (COBS)?  It
produces better efficiency, but is not compatible with current HDLC
chips.

It could be used instead of HDLC as the outer encapsulation of the
frames.  This is good for high-sped links such as SONET (very efficient
to implement).

In the ISSLL group, there has been a last call for the work described
here.  The purpose of this talk was to introduce the work to the group
and invite their comments to the last call.

There were several comments regarding the prefix elision option.  There
was some concern expressed because it is negotiating the sender
behavior.

There was a question why the short header negotiation was part of option
27, rather than 18.

At this point, Carsten's presentation was interrupted by the end of the
session.

Second session:

Dave Thaler quickly presented the tunnel MIB.

The tunnel MIB extends the interfaces MIB for certain rows, and the L2TP
MIB further extends the tunnel MIB.  They share the same ifIndex value
for the applicable rows.

Evan Caves presented the L2TP MIB.

There are four L2TP MIB groups, the scalar group, the tunnel group, the
session group, and the transport group.

Proposed changes and issues:

* Relationship to Dave Thaler's Tunnel MIB - this will be updated
* How is the session table instantiated?
* Tunnel Domain Group
  * Configuration Table
  * Statistics Table - more appropriate to have statistics based on
    groups of hosts
* Reduce number of objects

They intend to add a tunnel session table in the tunnel MIB to
correspond with the L2TP session table.

Comment: That approach is preferred to having to walk the entire MIB
table to find session table entries.

Comment: There need to be more statistics for the LNC, and the MIB is
IP-centric.  L2TP will be run over other media besides IP.

Matt asked that detailed comments be addressed to the list.

John Shriver presented some MIB issues that he had sent to the list.

Tunnel configuration lookup rules are a key issue - tunnel configuration
is really very different at the LAC and LNS.

It may be better to have different tables for calling and called
parties.

The row-create model of the configuration tables is completely ignored.
There needs to be a good deal more thinking about how the various parts
of configuration fit together.

There was discussion of how the tables should be indexed for best lookup
capabilities.  This will be further discussed on the list.

The discussion as a whole will be taken back to the list.  The tunnel
table will be instantiated in the ifTable.  There was no consensus on
how to instantiate the L2TP session entries, whether in the ifTable or
in the L2TP tunnel table.

Carsten Bormann continued his ISSLOW talk from the first session.

He is going to make the following updates to the spec, both regarding
option 27 (multilink header format):
* Explain multiple occurrences
* Add parameter for number of suspendable classes, so that it can be
  negotiated

The replacement text will be sent to the PPPext email list.  However,
since it has already been through last-call in ISSLL, he would propose
to end the discussion by April 20.

The prefix elision option (27) is going to be moved to a separate draft,
with more discussion, based upon yesterday's discussion.

The group discussed whether to have multiple options in LCP, or to have
one option with multiple bits to select various behaviors.  There were
concerns that these options could cause multiple rounds of option
negotiation.  There were suggestions to make certain choices mandatory,
to help options negotiation converge.

The option numbers 27 and 26 have been assigned by IANA.

Bernard Aboba spoke on L2TP security.  A new draft has been sent out.
Key management has been taken out, and replaced by a pointer to ipsec.
Please send comments to the list.  There was discussion about when the
L2TP security draft should be advanced.  Matt suggested that it have a
security review for comments, and then go to WG last call.  The
suggestion was made that the security folks are overloaded, and it might
be better to get their attention by going directly to last call.

Matt Holdrege		http://www.ascend.com	[email-masked]