Subject: Notes from 49th IETF L2TPEXT in San Diego

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 05 Jan 2001 03:39:10 -0500

Apologies for the delay in posting.

It should be noted that this time I forgot to ensure that a ready,
willing and astute minute-taker be identified until after the meeting
was underway. Ross Wheeler sent me the notes he had taken up to this
point, plus additional minutes after being appointed as the on the spot
secretary. I took these and filled them out based upon my memory of the
meeting. If I left anything out, or got anything wrong, I humbly request
that those present correct me forthwith.

Thanks, and next time feel free to rudely stop and ask me if anyone is
taking minutes when I step up to the mic in MN.

-----

Mark Townsley, Bashed agenda items and future work with no questions -
session
info and link info need to be resubmitted

Danny McPherson, Service Type draft. 

- Use of the M-bit questioned. This was discussed at length among the
authors, an explanation to the list will be posted and perhaps
additional explanatory text in the draft if needed. Primary motivation
was to preserve backward compatibility as much as possible.
	
- Order dependency of AVPs questioned. The Service Type AVP states that
it MUST be present following the Message Type AVP. Currently, the
Message Type AVP is the only AVP that is required to be at the beginning
of the AVP list. The primary argument for this was that interpretation
of AVPs within a message is dependent upon the Message Type AVP.
Similarly, the Service Type AVP has direct affect on some AVPs which may
follow in the message, hence the ordering requirement. Of course, we can
relax this. Consensus should rule as always, comments welcome.

Danny McPherson, Differential services

- Much discussion about applicability. Taking it offline to the list due
to the length of discussion, scope and relevance to L2TP. Mark mentioned
that PHB work should provide a layer of abstraction between L2TP and
actual DSCP bits. There seemed to be general agreement among the
Diffserv experts present that this was at least the proper goal. There
still may be issues with regard to tunnels that cross multiple domains
that need to be addressed in the draft.

Bill Palter, Ethernet over l2tp draft

- New avp (refer to the draft) which contains source mac address.
Primary motivation was for PPPoE to be transported over L2TP, but may
also be used for Ethernet bridging applications for L2TP. 

- Why can't we use BCP? Answer: Possible, but PPP would have to be built
in where not necessarily needed. The initiating device may not even have
a PPP stack. Mark mentioned that this was brought up at the last IETF
meeting as well.

- Mark requested more deployment model text for the two cases, bridged
ethernet and PPPoE. Also, implementation notes for whether to keep the
sessions up forever or recommend a mechanism for when to release state.

- Jim suggested looking at 802.x drafts regarding timeouts for sessions
regarding above.

- Does draft cover spanning tree, rings etc.? - Bill says no

Mark Townsley, l2tp-bis draft

More, mostly minor changes. Use wdiff if you are really curious. Mark
will post change summary to the list as well. 

- There was some more discussion regarding the recent thread on when to
begin sending data packet at the LAC (e.g. before or after an ICCN is
acked). Tom mentioned that this is okay to do, although historically we
chose against it.

Bill Palter - Layering problem. We are now including the ack of a
message as an action where before this was kept separate from the L2TP
state machine. Mark acknowledged that this was true, and is why it is
not a MUST. 

- Mark mentioned that the motivation for this is specifically to appease
the behavior of a particular PPP stack that happens to widely deployed.
This was detailed in a message from Mark to the list recently, which no
one answered. Mark asked that this thread be revived on the list if we
need to discuss it further.

- Glen suggested that since L2TP will now be carrying Layer 2 protocols
other than PPP, whether we should break L2TP into a core L2TP document,
with separate PPP, ATM, FR, Ethernet, etc. documents for each. Mark
acknowledged this as quite a good goal, but we should not rush into it
before determining whether the current interoperability that we enjoy
would be hindered by such an overhaul. Consensus was fairly clear that
ideally this is the best thing to do, but Mark wanted some time for us
to look at the RFC and be sure that breaking it up would not so much of
a change as to inhibit interoperability of future PPP/L2TP
implementations with those existing now. Thomas mentioned that a similar
argument was given for the draft-13+ rewrites, and that we managed to
pull it off without too much pain. This is a good argument that we could
probably do it again. Glen mentioned that the sheer editorial effort
should not be a factor.

---

From: James Carlson <[email-masked]>
Date: Fri, 5 Jan 2001 07:58:52 -0500 (EST)

> Bill Palter, Ethernet over l2tp draft
[...]
> a PPP stack. Mark mentioned that this was brought up at the last IETF

I'm one of the people who brought this up.  The point here is that not
wanting to implement a Standards Track protocol is not sufficient
justification for creating a duplicate mechanism.  The harm --
potentially forcing many other vendors to implement both protocols --
far outweighs any good.

> with separate PPP, ATM, FR, Ethernet, etc. documents for each.

The working group charter appears to disagree.  It says nothing about
carrying anything other than PPP over L2TP.

	The Layer 2 Tunneling Protocol (L2TP), defined in RFC2661
	(http://www.ietf.org/rfc/rfc2661.txt) is a protocol for
	tunneling PPP (RFC 1661) sessions over various network
	types. The group will provide a forum for discussion and
	development of extensions to L2TP, and actively advance the
	L2TP base protocol to Internet Standard.

Has a new group charter been adopted but not yet posted to the IETF
web site?

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 05 Jan 2001 11:44:25 -0500

> potentially forcing many other vendors to implement both protocols --

There are arguments on both sides here, and I will leave it to the
authors to please jump in and present these on the list. I have heard
some of them in the meetings, but we need to get them on record.

> Has a new group charter been adopted but not yet posted to the IETF

But it does say that the group will extend L2TP as necessary. It just
happens to state before this that RFC2661 is a mechanism for tunneling
PPP. You'll notice that l2tp-bis now makes provision in its introductory
text that it may tunnel other layer two frames. I am not disagreeing
with you though, so please read on.

Consensus at the 48th IETF meeting was to allow L2TP to tunnel Layer 2
encapsulations other than PPP. This seems to have held true through this
last meeting and the list, and has support of at least the one Area
Director that I have discussed this with. I believe you are correct in
that it would be best to adjust the charter to reflect this more
accurately, something that I have already discussed with this AD,
mentioned in Pittsburg, and discussed with the authors which originally
brought the requests to the group. I simply wanted to be sure that there
was serious interest, and not just a fleeting set of drafts for this
before bothering the IESG with a charter revision.

A charter revision requires consensus of the WG (which I believe we
have) and approval of the IESG (which needs to be done). I will post a
new charter to the list for presentation to the IESG.

Thanks,

- Mark

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 5 Jan 2001 09:18:24 -0800 (PST)

> new charter to the list for presentation to the IESG.
I agree that the best approach is to create a new charter, and have the WG and
IESG approve it. Some text hidden in one I-D is not justification for adding
new work to the WG.

Also, I am not really in favor of multiple options that achieve the same goal.
If ethernet can be sent through L2TP via BCP, then I agree with James that a
new method will only create interoperability problems in the field. If the
authors cannot come up with an actual reason why BCP won't work, which btw
DOES NOT require a charter change, and DOES NOT require any engineering
efforts, then we should reconsider this work.

The goal of the WG should not be to see how long it can live, but how it can
successfully shutdown.

PatC

---

From: Suhail Nanji <[email-masked]>
Date: Tue, 9 Jan 2001 17:26:05 -0800 (PST)

> potentially forcing many other vendors to implement both protocols --

Please note, I am not comparing BCP/PPP to EoL2TP.  I am comparing
transporting Ethernet frames over L2TP using BCP/PPP or EoL2TP.  There are
a few reasons why BCP/PPP over L2TP is not better than EoL2TP.

First, the Ethernet frames may not be transported to/from the LAC using
BCP/PPP.  In most cases that I have worked with, the Ethernet LAN is either
directly connected to the LAC or RFC1483 encapsulation is used by a remote
CPE device for Ethernet frames.  In either scenario, the LAC would have to
implement a virtual BCP/PPP endpoint inside the LAC for the LNS to
communicate with. I think this is a cumbersome and ineffecient way to
transport Ethernet frames over an L2TP session in the name of using a
Standard Track protocol. If the standard does not make sense for an
application, then to force its use is more harmful than good.

Second, EoL2TP is not a method of connecting Remote Bridges.  Like PPP over
L2TP, it is a means of separating the physical termination of Ethernet
frames from the processing of those frames.  The processing is to be done
on the LNS and does not have to be bridging. For instance, the processing
could be restricted to PPPoE or IP packets only.  This is similar to the
LAC being unaware of which NCP is running between the LNS and PPP client.
Thus, vedors would not have to implement both BCP/PPP over L2TP and EoL2TP
as you suggest.

Finally, BCP/PPP over L2TP would add some overhead bytes to the Ethernet
payload which are not necessary for EoL2TP.  There are only a few bytes,
but it is additional overhead.

---

From: Suhail Nanji <[email-masked]>
Date: Tue, 9 Jan 2001 18:04:33 -0800 (PST)

> efforts, then we should reconsider this work.

Please see my earlier email for arguments why I think EoL2TP is a better
way to transport Ethernet frames over L2TP.

Furthermore, EoL2TP is not the only reason the charter is being changed.
The drafts for transporting ATM and FR frames over L2TP would require the
charter to be changed.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 9 Jan 2001 18:52:07 -0800 (PST)

> The drafts for transporting ATM and FR frames over L2TP would require the

Perhaps I've been out of the loop, but when did we decide that FR and ATM
would be encapsulated directly within L2TP? I thought the work was to allow
L2TP to run *over* the circuit switched networks.

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 9 Jan 2001 20:26:16 -0800

Pat Calhoun [mailto:[email-masked]] writes:

> would be encapsulated directly within L2TP?

Pittsburgh, I believe.  As I recall, draft-ietf-l2tpext-svctype-00.txt came
about because there were several drafts that talked about doing basically
the same thing w/ATM, FR and Ethernet.

> I thought the work
> was to allow

That, too: ATM/L2TP/ATM ;-)

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 9 Jan 2001 20:26:49 -0800

---

From: James Carlson <[email-masked]>
Date: Wed, 10 Jan 2001 08:56:30 -0500 (EST)

> the same thing w/ATM, FR and Ethernet.

It was suggested as a way to unify the proliferation of Foo-Over-L2TP
drafts.  With the assumption that arbitrary tunneling using L2TP is a
Good Thing, I agree that the service type extension is a fair way to
accomplish that goal.

What I don't recall happening was any sort of working group or IESG
survey for consensus on this notion.  The idea of carrying anything
other than PPP over L2TP is in conflict with the working group
charter.  I believe this idea requires separate consideration before
optimizations of the mechanisms should be considered working group
items.

    The Layer 2 Tunneling Protocol (L2TP), defined in RFC2661
    (http://www.ietf.org/rfc/rfc2661.txt) is a protocol for tunneling
    PPP (RFC 1661) sessions over various network types. The group will
    provide a forum for discussion and development of extensions to
    L2TP, and actively advance the L2TP base protocol to Internet
    Standard.

    The group will:

	Define and advance standard MIB for L2TP management.

	Produce documents describing how L2TP operates over link types
	other than IP (e.g., ATM, Frame Relay, etc.)

	Identify and define specific parameters and modes of IPsec in
	order to aid interoperability when IPsec is used to secure
	L2TP traffic.

	Define and review the definition of any additional IETF AVPs
	which are of interest to the group.

---

From: James Carlson <[email-masked]>
Date: Wed, 10 Jan 2001 09:51:34 -0500 (EST)

Suhail Nanji writes:
> CPE device for Ethernet frames.

That's certainly as I assumed the case to be.  However, that's not to
say that the LAC cannot run the PPP "client" (with BCP) itself.
Having a coresident LAC and client does not require a new protocol or
changes to the L2TP working group charter.  It doesn't even require a
new draft.

>  In either scenario, the LAC would have to
> communicate with.

It's not virtual; it's real.  You'd run a real PPP implementation.

> I think this is a cumbersome and ineffecient way to
> Standard Track protocol.

I fail to see either the encumbrance or the inefficiency.  BCP
provides defined ways to handle things that are missing from EoL2TP
(such as configuration verification, CRC handling, and bit-ordering
conventions), and PPP's LCP state machine is less complex than L2TP's
control channel.

> If the standard does not make sense for an

Since Ethernet inarguably does run properly over BCP, can you explain
how it does not make sense for this particular application?

Assuming an application-specific design, you could easily trim PPP's
LCP and BCP down to just the bits required.  For LCP, implement only
ACFC and PFC (even though RFC 2878 recommends Magic Number and LQM as
well).  For BCP, support only the Tinygram-Compression option.

(That is to say, I think it's a better idea to omit options from your
own implementation in order to fit market constraints than to force
other manufacturers to implement a new protocol.)

> LAC being unaware of which NCP is running between the LNS and PPP client.

Connecting one Ethernet segment to another using MAC-level forwarding
is "bridging."  There may be sharp optimizations available for
particular deployment models, but (1) that's no reason to have yet
another protocol and (2) IETF protocols ought to be designed to be
generally useful rather than market-specific.

> Thus, vedors would not have to implement both BCP/PPP over L2TP and EoL2TP

That's false.  There are three cases that I can think of here:

	1.  EoL2TP becomes popular and requested by customers.
            Equipment vendors are then forced to comply with the
            market by offering both BCP (the extant solution) and
            EoL2TP -- adding to overall software complexity and
            failure rates.

	2.  EoL2TP becomes a "point solution" in a particular market
            for a particular class of customer (a la PPPoE).

	3.  EoL2TP vanishes.

I think you're arguing for case 2.

It's easy to see, though, that this quickly devolves to case (1) for
any vendor that sells to multiple customers.  Otherwise, the
assumption must be that these customers comprise a captive market that
doesn't mind being in a non-standard ghetto.  I don't think that model
is appropriate for IETF-sanctioned protocols.

> but it is additional overhead.

This is not necessarily true.

An Ethernet frame over L2TP looks like this (note that I've added the
lines with "*" for clarity; the draft omits them but requires the LAN
FCS in the text):

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tunnel ID           |           Session ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Ns (opt)          |             Nr (opt)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Offset Size (opt)        |    Offset pad... (opt)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination MAC Address
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              Source MAC Address                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Protocol            |             Data...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
**    |                            CRC-32                             |
**    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

An Ethernet frame bridged over BCP (with ACFC and PFC enabled and F
bit set to 0) looks like this:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tunnel ID           |           Session ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Ns (opt)          |             Nr (opt)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Offset Size (opt)        |    Offset pad... (opt)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0x31     |0|0|Z|0| Pads  |    MAC Type   | Dest MAC Addr |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Destination MAC Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Dest MAC Addr |             Source MAC Address                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Source MAC Address                        |  Length/Type  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Length/Type  |               LLC data       ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that this adds three octets, but removes 4 octets of LAN FCS.
The result is one octet shorter.

On top of this, BCP has tinygram compression, and EoL2TP does not.
This means that all EoL2TP packets are at least 64+L2TP+transport
octets long.  For short (~40 byte) packets, this EoL2TP overhead will
be significant.

If you do want to carry the LAN FCS end-to-end, then BCP does have an
overhead of three octets compared to Ethernet/L2TP when using long
(>64 octet) frames.  I would argue though that this pales in
comparison to the L2TP overhead (likely 10 octets, since data channel
sequencing is likely necessary to discard duplicated and reordered
packets) and the UDP/IP overhead (28 octets).

So, as I see it, the potential benefit on the wire is (at best) 3 out
of 31 octets of per-packet overhead, but the cost is forcing most or
all other manufacturers to design, implement, document, test, and
support at least two ways to do the same thing.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 10 Jan 2001 12:54:38 -0500

> optimizations of the mechanisms should be considered working group

James, you mentioned this a few days ago as well, my reply was:

http://www.diameter.org/cgi-bin/lwgate/L2TP/archives/l2tp.archive.0101/date/article-4.html

As far as this action in the WG, the activities in Pittsburg on this
matter were documented below for all on the list to comment on. This is
particularly clear in the synopsis I constructed and sent to the list
and copied to both Intenet Area Directors. I have not seen any strong
arguments as to why it is a BAD idea to use L2TP as a transport for
circuit emulation over IP beyond it being outside the scope of the
existing charter. Charter's may be modified when necessary, and the one
most to blame for the l2tpext charter not being modified and posted thus
far is probably me as I have not written a new one up and given it to
Thomas yet. 

http://www.diameter.org/cgi-bin/lwgate/L2TP/archives/l2tp.archive.0008/date/article-24.html
http://www.diameter.org/cgi-bin/lwgate/L2TP/archives/l2tp.archive.0008/date/article-23.html

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 10 Jan 2001 13:16:00 -0500

> changes to the L2TP working group charter.  It doesn't even require a

A very compelling argument. However, one might write a very small draft
as an applicability statement or BCP (no pun intended) though. 

> conventions), and PPP's LCP state machine is less complex than L2TP's

Well, you have to run L2TP anyway to allow the PPP LCP State machine to
operate between the LAC and LNS. As far as which is more complex,
really, let's not go there...

> other manufacturers to implement a new protocol.)

Another very compelling point.

---

From: "Ajoy Singh" <[email-masked]>
Date: Wed, 10 Jan 2001 12:23:08 -0600

Hello Mark,

What is the status of L2TP over AAL5 and L2TP over FR draft? I guess
you gave last call for these two drafts during IETF Pittsburgh meeting.

regards,
ajoy

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf
>Of Pat Calhoun
>Sent: Tuesday, January 09, 2001 8:52 PM
>To: Suhail Nanji
>Cc: Pat Calhoun; W. Mark Townsley; James Carlson; [email-masked]
>Subject: Re: Notes from 49th IETF L2TPEXT in San Diego
>
>
>>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 10 Jan 2001 13:27:06 -0500

> you gave last call for these two drafts during IETF Pittsburgh meeting.

WG last call was given for this and several other drafts on the list
here. You cannot issue last call at a meeting.

FR draft has been approved (I just sent the notice I received to the
list)

There is still some discussion ongoing between the IESG and the authors
of the ATM draft.

- Mark

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 10 Jan 2001 17:36:23 -0800

> Good Thing, I agree that the service type extension is a fair way to

Agree.

> survey for consensus on this notion.  

I don't recall that it was brought up on the list, at least.

> The idea of carrying anything
> charter.  

Yes, a charter revision is necessary before this work is adpted by the WG.

> I believe this idea requires separate consideration before

<text deleted>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 10 Jan 2001 21:03:34 -0500

> I don't recall that it was brought up on the list, at least.

Here you go:

Not to mention submission of several drafts on the subject over the past
six months at least. 

> Yes, a charter revision is necessary before this work is adpted by the WG.

Working on it.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 11 Jan 2001 11:40:35 -0800

> http://www.diameter.org/cgi-bin/lwgate/L2TP/archives/l2tp.archive.
0008/date/article-24.html
http://www.diameter.org/cgi-bin/lwgate/L2TP/archives/l2tp.archive.0008/date/
article-23.html

OK.  However, the mention of charter revision therein is rather subtle (to
be generous ;-).

> Not to mention submission of several drafts on the subject over the past

The notion I was talking about, at least, was the one of charter
modification.  I do recall that this question was explicitly asked at the
meeting, but I think it needs to be explicitly asked on the list as well, by
the WG Chair.

Working on it.

---

From: Mitsuru Higashiyama <[email-masked]>
Date: Sat, 13 Jan 2001 00:37:58 +0900

Hello,

I have one question.

> It's not virtual; it's real.  You'd run a real PPP implementation.

I think what you said is assume below configuration.

                                                    [Home LAN]
                                                        |
                              __________                +--[Host]
                             |          |               |
               [LAC]---------| Internet |-----[LNS]-----+
                 |           |__________|               |
            _____|_____                                 :
           |           |
           |  PSTN     |
           |  Cloud    |
           |           |                   
           |_____ _____|                          
                 |
                 |
             [BCP/PPP]
                 |
          ---+---+-------
             |
          [Host]

Does BCP/PPP process need in LAC ?
As my understanding, LAC just tunnel PPP session and is not required
BCP/PPP process.

Best regards,
Mitsuru
----
Mitsuru Higashiyama
Anritsu Corp.

---

From: James Carlson <[email-masked]>
Date: Fri, 12 Jan 2001 11:12:13 -0500 (EST)

> I think what you said is assume below configuration.

No.  To conform with the original author's intent, I was proposing
a scenario that looks like this:

   Remote
    Ethernet                             Home
     Network                            Network
     ___                                  ___
      |                                    |
      |                                    |
      |                                    |
      +---[LAC]---- IP Network ----[LNS]---+
      |                                    |
      |                                    |
      |                                    |
     ---                                  ---

Both the LAC and LNS implement BCP/PPP/L2TP and perform bridging.

> Does BCP/PPP process need in LAC ?

The original authors were considering a deployment where the Ethernet
to be bridged was attached directly to the LAC, and no dial-up PSTN
was involved.  You're right that for other deployment models, a PSTN
may well be there.

This brings up a very important point.  The Ethernet over L2TP draft
fails badly on the test of general applicability and usefulness.  If
you must do bridging in the PC-PSTN-LAC case using BCP over PPP --
since there's no way for that remote node (which has only PPP, no
L2TP, and is not coresident with the LAC) to negotiate or use Ethernet
over L2TP frames, then why would you use a different, incompatible
protocol in an only slightly different case?

Ethernet over L2TP is thus a much narrower and more inflexible
solution than the existing standards-track alternative.  It fails
principle 3:

http://www.ietf.org/internet-drafts/draft-ietf-poisson-code-01.txt

> As my understanding, LAC just tunnel PPP session and is not required

It's not required in general, but for a given *deployment* you may
need to make the LAC and PPP implementation co-resident.

On example of a good use for this in deployment is with roaming
corporate users who dial into ISPs that do not support L2TP (or do not
have a contract with the corporate site).  These users can dial into
any convenient ISP and use L2TP (presumably with IPSec) to tunnel back
to the home site without requiring the cooperation of the ISP.  (Yes,
the stack does look like IP/PPP/L2TP/UDP/IPSec/PPP in this case.)
(Yes, Mobile IP also supports these users, but generally requires ISP
support and is apparently less available.)

This case can also be used on non-PPP media.  For example, most modern
hotels provide Internet access via Ethernet.  You can tunnel back to a
home site using L2TP over that connection as well.  Again, the hotel's
IP provider doesn't need to get involved (and doesn't get a chance to
charge extra ;-}).

---

From: Mitsuru Higashiyama <[email-masked]>
Date: Tue, 16 Jan 2001 03:57:21 +0900

Hello James,

Thank you for your reply.

> was involved.  You're right that for other deployment models, a PSTN

O.K. I see.

But under the situation I have shown in original my email.
The BCP will be appricablly with PSTN and PPP, won't it ?

Best regards,
Mitsuru
----
Mitsuru Higashiyama
Anritsu Corp.

---

From: Suhail Nanji <[email-masked]>
Date: Mon, 15 Jan 2001 12:11:29 -0800 (PST)

> The BCP will be appricablly with PSTN and PPP, won't it ?

Yes, the LAC would tunnel the BCP/PPP session as per RFC 2661.

---

From: Suhail Nanji <[email-masked]>
Date: Mon, 15 Jan 2001 11:55:46 -0800 (PST)

> I think what you said is assume below configuration.

No, my configuration assumes the LAC is receiving and sending Ethernet
frames to a client (for example via RFC1483) or a directly attached LAN
without BCP/PPP.

---

From: Suhail Nanji <[email-masked]>
Date: Mon, 15 Jan 2001 11:48:19 -0800 (PST)

> changes to the L2TP working group charter.  It doesn't even require a

Again, the working group charter is not being modified just for Ethernet
over L2TP.  The EoL2TP draft builds upon the Service Type draft and defines
new AVPs for an Ethernet Service Type.  In the EoL2TP draft, there are no
new headers, no new state machine and the L2TP state machine does not get
modified.  As I outline below, having a coresident BCP/PPP client on the
LAC has it own implementation and performance costs.

> It's not virtual; it's real.  You'd run a real PPP implementation.

Of course the PPP implementation is real.  The BCP/PPP implementation is
virtual in that it is created within the LAC for the purpose of
transporting Ethernet frames and it is not running on an external physical
device.
 
> conventions), and PPP's LCP state machine is less complex than L2TP's

The inefficiencies with running BCP/PPP in the manner you describe are: 
 
a) forced introduction of an LCP state machine on the LAC & LNS per session
 
b) forced introduction of a BCP state machine on the LAC & LNS per session
 
c) both (a) & (b) are in the data forwarding path of L2TP sessions on the 
LAC

For current LAC implementations, there is no need for this kind of
processing in the forwarding path to an external PPP device.  Once the L2TP
session has been established, a LAC simply shuttles the PPP frames between
the L2TP session and the PPP client device.  For transporting Ethernet
frames with a coresident BCP/PPP endpoint, this simple type of forwarding
in not possible.  With EoL2TP, this type of forwarding remains intact for
Ethernet frames.  The data forwarding path of the LAC needs minor
modifications and most likely no major architectural changes. These
attributes of EoL2TP help it scale better.

In addition, a LAC may not have a BCP implementation at all.  In this
sceanario, development work would be needed to implement BCP or EoL2TP.
Even if a LAC does have a BCP implementation for use with external PPP
clients, it needs to modify it data forwarding path to accommodate a
coresident BCP/PPP endpoint.

> other manufacturers to implement a new protocol.)

A LAC can tunnel a BCP/PPP client without a BCP implementation.  If a
manufacturer has decided not to implement BCP on its LAC or LNS, there is
no opportunity "to omit from your own implementation".

> generally useful rather than market-specific.

I am not sure what you mean by "market-specific".  If you mean PPPoE
support only, it is just one of the Ethernet protocols which may take
advantage of EoL2TP.  For instance, the LNS could be an IP endpoint for
Ethernet frames from a client which uses RFC1483 to communicate with a
LAC.

>             EoL2TP -- adding to overall software complexity and

Nobody *has* to use EoL2TP; BCP is still an alternative which the
vendor may choose.  Now, if EoL2TP "becomes popular" then it must have some
value otherwise BCP/PPP would get used for transporting Ethernet over L2TP.

Also, BCP is the extant *protocol*.  It does not mean it has been
implemented on the LAC or in the data forwarding path to transport Ethernet
over L2TP.  Depending on the LAC, there may be little to lots of
implementation effort required to use BCP/PPP to transport Ethernet over
L2TP.

>             for a particular class of customer (a la PPPoE).

I am not arguing for this case, but this obviously does not force anybody
to implement EoL2TP.

> lines with "*" for clarity; the draft omits them but requires the LAN

I was referring to this scenario.  I agree the overhead is not significant
but it is there.

> support at least two ways to do the same thing.

Again there is no force to implement both standards.  Do all PPP
implementations support all NCPs?

---

From: James Carlson <[email-masked]>
Date: Mon, 15 Jan 2001 16:12:35 -0500 (EST)

> The BCP will be appricablly with PSTN and PPP, won't it ?

Yes, under the situation you described, BCP in the "client" PPP would
properly support bridging, no special support would be required in the
LAC (if any), and PPP does operate properly over the PSTN.

-- 
James Carlson                                  <[email-masked]>
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: James Carlson <[email-masked]>
Date: Tue, 16 Jan 2001 07:54:31 -0500 (EST)

> LAC has it own implementation and performance costs.

If I recall correctly, Ethernet over L2TP was the first of these
non-PPP cases, and inspired the service-type draft.

In any event, there's a circular argument here that's making the
discussion very difficult to advance.  The justification for "Service
Type" is the Ethernet over L2TP draft in concert with a few lesser
drafts.  It's therefore not reasonable to say that having Service Type
available justifies the addition of Ethernet over L2TP.

> b) forced introduction of a BCP state machine on the LAC & LNS per session

Note that these two are the very same state machine.  There is no
separate LCP and BCP state machine.

> c) both (a) & (b) are in the data forwarding path of L2TP sessions on the 

Unless the implementation in question is very poor, this is simply
false.  The PPP state machine, like the L2TP state machine, is not on
the data forwarding path.  *Detection* of the signaling packets is on
the data forwarding path, but that logic must already exist for L2TP
signaling.

If your argument works for PPP's complexity, then why doesn't it work
for L2TP?  That is to say, if you're going to invent something new and
proprietary, then why not simplify further?  Eliminate L2TP, and run
Ethernet frames over a well-known UDP port.

> processing in the forwarding path to an external PPP device.

This is also false.  Most currently deployed LAC implementations
include PPP because negotiation of LCP is necessary in order to set up
the tunnel.  I'll agree that it's *possible* to tunnel prior to LCP
start-up, but I can't agree that there's *no need* for LCP in current
implementations.

>  Once the L2TP
> in not possible.

The forwarding is still quite simple, and essentially equivalent
between the two proposals (BCP/PPP/L2TP and EoL2TP).  Don't confuse
the negotiation state machine (for which you must pay in both L2TP and
PPP) with the forwarding path.

> In addition, a LAC may not have a BCP implementation at all.

LACs don't need BCP.  However, PPP systems that do bridging *do* need
BCP.  That's the point.

>  In this

False on at least two counts.  First, BCP already exists in multiple
implementations and for those vendors represents no new work.  Second,
if this proposal is widely deployed, then implementations will need to
support *BOTH* BCP and EoL2TP, not either-or.

> coresident BCP/PPP endpoint.

I'm afraid I don't understand that comment.  Either BCP and the PPP
client are coresident with the LAC or they are not.  I don't
understand what a LAC would do with BCP if it doesn't have the PPP
endpoint coresident.  (Are you talking about stateful inspection?
Why?)

I also don't understand what the data forwarding path modifications
would be here.  I suspect that you're talking about the effort
required to integrate BCP/PPP into an existing L2TP LAC in order to do
bridging.  That effort, I submit, is no different from the effort
required to implement a new L2TP transport mode for Ethernet and link
this into all of the other subsystems required in a typical
implementation (configuration, authorization, monitoring, filtering,
and so forth).

> A LAC can tunnel a BCP/PPP client without a BCP implementation.

Of course.  Actually, a LAC can tunnel *arbitrary* PPP data without
requiring the upper-layer negotiation.  This is beside the point.

>  If a

I think you may have misunderstood what I wrote.  What I was
suggesting was that if you need a stripped-down, barely functional
implementation of Ethernet bridging, you can accomplish this by
adopting BCP and LCP, but removing the optional parts that you do not
require.  Doing this is far better than forcing all other vendors to
implement two protocols to do essentially the same thing.

> Ethernet frames from a client which uses RFC1483 to communicate with a

No, that's not what I mean.  I mean that Ethernet over L2TP doesn't
work in many perfectly reasonable deployments, but that BCP/PPP does.
For instance, consider this:

    Ethernet <--bridge--> PPP/PSTN <--LAC--> Internet <--LNS--> Ethernet

In this case, Ethernet over L2TP cannot be made to work without
protocol translation between BCP and EoL2TP at the LAC.  BCP over PPP,
though, works precisely as intended without special effort.  In fact,
the only case where Ethernet over L2TP works as intended is the
following case, and this is also a case where BCP over PPP works:

    Ethernet <--LAC--> Internet <--LNS--> Ethernet

For this reason, I consider Ethernet over L2TP to be a solution with a
very limited market.

(For the specific case of PPPoE, it would be far better to describe a
mechanism to translate between PPPoE and L2TP than to carry PPPoE
itself tunneled with all of the Ethernet overhead.  Of course, given
the many flaws in PPPoE, the folks using that protocol would be better
served by either L2TP or simple DHCP addressing, but that's another
topic entirely.)

> vendor may choose.

That's simply false and ignores the way the marketplace works.
Vendors that are fortunate enough to have a tiny captive market will
have the luxury of implementing just one of these two protocols.  The
rest of us do not have that luxury and will be forced to design,
implement, test, document, and maintain both.

>  Now, if EoL2TP "becomes popular" then it must have some

False.  Marketing force does not equal technical adequacy.  Examples
are readily available.

> over L2TP.

I have not suggested implementing BCP in the data forwarding path.
That doesn't make sense.

>  Depending on the LAC, there may be little to lots of

The effort that you personally expend doing this pales in comparison
to the combined efforts of the hundreds of people employed by dozens
of vendors, all of whom would be affected.

> I was referring to this scenario.  I agree the overhead is not significant

As I noted before, this overhead can be eliminated using the features
already available in BCP.  In fact, when the overhead is minimized,
the BCP packets are *at least* one octet smaller than Ethernet over
L2TP, and even better than that when tinygrams are present.

If, for a given market or deployment, the BCP overhead matters, then
it's a matter only for your implementation to make certain that the
overhead is minimized within the existing protocols.  I do not see how
this helps justify the creation of a new protocol.

> implementations support all NCPs?

No.  That's because the NCPs in general don't duplicate each other's
features.  You have a choice only when you have different features to
support.  Once you've chosen to support a single feature (say,
Ethernet bridging), it does become necessary to support all of the
mechanisms that customers expect.

For some examples that prove the point, communication server vendors
typically must support both BOOTP over PPP and Microsoft's RFC 1877
DNS addressing, and must support both normal RFC 1570 callback and
Microsoft's CBCP.  Each must be tested and maintained separately.
This is because of unwarranted protocol duplication, and it's not a
good thing.

---

From: Rene Tio <[email-masked]>
Date: Tue, 16 Jan 2001 15:32:15 -0800

On Tue, Jan 16, 2001 at 07:54:31AM -0500, James Carlson wrote:
> false.
[...snip]

I have to agree with James on this point.  Control packets only matter
for poor data forwarding implementations which do not take the
processing of these packets off the datapath.

However, Suhail's earlier point that per-session PPP state is a serious
limitation to scalability still stands.  Ethernet is stateless and for
this application there is no need at all to introduce per session state
beyond a session ID.

> Ethernet frames over a well-known UDP port.

Sure, but we want a form of LAC-LNS authentication, and either way we
need some form of tunnelling.  Since most LACs already have L2TP it
makes sense to re-use that.  We don't like inventing new protocols any
more than the next guy.

> start-up, but I can't agree that there's *no need* for LCP in current

... only if you insist that L2TP tunnels PPP only.  Otherwise this
argument is false.

> LACs don't need BCP.  However, PPP systems that do bridging *do* need

And our point is that neither the client nor the LAC is a PPP system.

> implementations and for those vendors represents no new work.

Incorrect.  BCP voluntary tunneling does not in many vendors.  Even if
it does, the per-session state-keeping makes this type of service all
but useless except for small scale deployments.  Most vendors count PPP
scalability in terms of PPP sessions.  Unless you can strip BCP/LCP of
PPP state, no amount of simplification will suffice.

> Second,

Incorrect again.  These implementations will only support EoL2TP if the
application is a SP-to-SP (note: NOT client-to-SP) transport of Ethernet
frames.

Just because BCP came first doesn't make it any better a protocol than
EoL2TP.  If L2TP had been invented before BCP, EoL2TP might very well
have come first.

[...snip]
> For this reason, I consider Ethernet over L2TP to be a solution with a

That's like saying:

	ATM <--switch--> FR

won't work without a protocol translation, and therefore we should do
without FRF.8.  You've given an ideal example for BCP in the first
example.  By the same token you've discounted the ideal example for
EoL2TP--- which just happens to be the a major market driver today--- as
a niche not worthy of addressing.

> implement, test, document, and maintain both.

Did not Ascend and Redback have a tiny captive market once?  Some people
would consider EoL2TP "innovation".

As for extending protocols in order to give advantage to smaller
vendors, I need only direct you to the hold Cisco has with BGP in order
to prove the counterpoint.

> False.  Marketing force does not equal technical adequacy.  Examples

Agreed.  By the same token, compare Macs to PCs, DOS to CP/M, Multics to
Unix, etc.  Being a technical purist can be hazardous to your company's
health.

R.

---

From: James Carlson <[email-masked]>
Date: Wed, 17 Jan 2001 08:26:26 -0500 (EST)

Rene Tio writes:
> limitation to scalability still stands.

If it is a serious limitation in some particular implementation (I
have my doubts about that), it's certainly true that this state can be
ephemeral for that implementation.  That is to say, negotiate LCP and
BCP, and then discard the state storage and keep the session active.
Depending on how you structure your option usage, you don't
necessarily need the associated state information once you're up and
running.  PPP doesn't actually do anything after the negotiation is
done.  It's not constantly active in the way L2TP is.

>  Ethernet is stateless and for

Not quite.  L2TP signaling itself is not stateless and, as Vern has
noted, Ethernet transport requires a guarantee of both non-duplication
and non-reordering.  Regular PPP provides this as a matter of
definition.  Getting the same out of L2TP requires the use of L2TP's
optional data sequence numbers, and this certainly does require
per-session stateful processing.  It's not a straight shot in the
forwarding path, as the Ethernet over L2TP advocates have said.

(This overhead exists for both BCP/PPP/L2TP and EoL2TP; the proposals
don't differ on this requirement.)

> makes sense to re-use that.  We don't like inventing new protocols any

Then why invent a new protocol for Ethernet bridging over point-to-
point sessions, but not invent a new protocol for tunneling in
general?  If you're reinventing BCP/PPP, I don't see why reinventing
L2TP is a barrier.  If you're not reinventing L2TP, I don't see why
you should reinvent BCP/PPP.

> ... only if you insist that L2TP tunnels PPP only.  Otherwise this

For the working group charter and for currently deployed and
interoperable implementations, PPP is the only thing tunneled by L2TP.
It's possible that will change, though I strongly disagree with the
reasons put forward to date for changing it.

> Incorrect.  BCP voluntary tunneling does not in many vendors.

I can't parse that statement.  Does not what?  BCP doesn't have
anything called "voluntary tunneling" (though L2TP does).

>  Even if

You already need 32 bits to track the per-session data channel
sequence numbers in L2TP, assuming you're not breaking Ethernet
semantics.  How many bits to you believe are necessary to track PPP
state for BCP/LCP?  (I believe the correct answer, assuming you use
the ephemeral state suggestion above, is 1.  If you support multiple
options, the number may rise as high as 5 or 6 bits worth of data.)

> application is a SP-to-SP (note: NOT client-to-SP) transport of Ethernet

Vendors do not set application domains; users do.  There's no obvious
way to contain this protocol so that it affects just the vendors who
believe they need to have it.  It will, without question, affect many
others.  (Myself included; I've already done PPPoE under duress.  I
don't want to add EoL2TP to the mix.)

Besides that, I see no such domain limitation in the draft or in any
of the discussions of the draft.  In general, any protocol that limits
its applicability has a red flag on it.  IETF protocols should be
designed with the widest possible applicability, not for particular
markets, no matter how big or important those buyers think they are.

> EoL2TP.  If L2TP had been invented before BCP, EoL2TP might very well

Note that BCP works in many more situations than does EoL2TP.  That
alone, I would argue, makes it a much better protocol.  (Though I
thing this tangent is mighty silly.)

> without FRF.8.

Huh?  No.  I never said or suggested such a thing.  FRF.8 and FRF.5
are defined; you can use them as needed.

Please show me the BCP<->EoL2TP IWF document.  I'm fairly sure that
such a thing does not exist.

>  You've given an ideal example for BCP in the first

That's simply untrue.  What I've said is that for addressing that
"major market," you can do just as well or better with the
standards-track BCP/PPP/L2TP protocols as you can with EoL2TP.
Therefore, there is no reason to adopt EoL2TP.

That's not at all the same as saying that this niche market isn't
important.  It just doesn't deserve its very own little protocol.

> Did not Ascend and Redback have a tiny captive market once?

Sure.  Does that mean that every little newcomer needs his own,
duplicate, incompatible, unnecessary, and proprietary protocol?

> Some people

Some folks think that of PPPoE.  It doesn't make it true.

> to prove the counterpoint.

My point has nothing to do with the marketing game.  Sure, Cisco plays
that one well.  (BGP is a good example, as is MPLS.)

That has nothing to do with this problem.  This problem is an
unwarrented duplication of effort.

> Unix, etc.  Being a technical purist can be hazardous to your company's

You seem to have forgotten something rather important.  We are here in
the IETF as individual contributors, not as employees or
representatives of some company or market.  What I or my company do in
pursuit of market share or technical purity is quite literally none of
your business.

Please (re)read:

  http://search.ietf.org/internet-drafts/draft-ietf-poisson-code-01.txt

The issues that are germane here are *only* the technical issues.  On
those merits, EoL2TP is lacking.

---

From: James Carlson <[email-masked]>
Date: Wed, 17 Jan 2001 08:35:57 -0500 (EST)

Jed Lau writes:
> So, if the LAC and LNS were to define VLANs, wouldn't only one PPP/BCP
> link be required?  The tagged frames specified by 802.1Q would provide the
> de/multiplexing of traffic that is needed.  In this way, using VLANs would
> eliminate the need to have a PPP link or L2TP session up for each
> subscriber (where a "subscriber" could actually be a number of clients,
> i.e. PCs, coming in on one Ethernet link).  Only one PPP link and L2TP
> session would need to be established, and all of the traffic from all of
> the subscribers would be de/muxed through this link using tagged VLAN
> frames.

Since I can't tell from the draft or from any of the mailing list
discussion which (if any) of BCP's failings are being addressed by
this brand new protocol, it's hard to tell if this would solve the
same problems.

If the problem does involve potentially large numbers of tunnels
between a particular pair of LAC and LNS, then VLAN support *might* be
an appropriate way to handle the aggregation.

If there is, instead, a large mesh of LACs and LNSs with only a very
few sessions between an particular pairs, then I don't think VLAN
support would help.

I think this is really in the realm of the feature list for a given
implementation rather than in the realm of L2TP specification.

---

From: Rene Tio <[email-masked]>
Date: Wed, 17 Jan 2001 13:02:38 -0800

> done.  It's not constantly active in the way L2TP is.

PPP is not active unless your box reboots or line gets cut and restored.
Yes, there are methods for throttling and graceful bring-up, but the
fact is running the PPP fsm is a non-trivial task, especially when you
are counting outages in subscriber minutes and you're aggregating many
tens or hundreds of thousands of subscribers.

> forwarding path, as the Ethernet over L2TP advocates have said.

L2TP is required for BCP as well, so it cancels out if we are discussing
EoL2TP vs. BCP+L2TP.  Besides, the only place where sequence numbers
need to be checked are on the receive path.  On the transmit the
processing is trivial.

> you should reinvent BCP/PPP.

We differ on where the line should be drawn.  We drew the line at L2TP
because that's what most LACs already run and L2TP signalling is very
useful.  If we put signalling into something like GRE we'd get flamed
about that as well :-)

> interoperable implementations, PPP is the only thing tunneled by L2TP.

Agreed.  I did separate out the charter issues from the technical,
mostly because I view that as orthogonal to this discussion.

> anything called "voluntary tunneling" (though L2TP does).

Apologies.  _L2TP_ voluntary tunneling, carrying BCP.

> options, the number may rise as high as 5 or 6 bits worth of data.)

Although storage is a far lesser issue than CPU cycles, it does have
some bearing.  The FSM state requires far more than one bit to store.
Even worse it requires many CPU cycles to run.  Multiply both by 100,000
or more and it becomes significant.

> markets, no matter how big or important those buyers think they are.

We did not limit its applicability, I was pointing out a sample
application for EoL2TP, and stating that there are other scenarios where
BCP+L2TP is better.

> such a thing does not exist.

Isn't that just bridging?  And why would you use this?  In this scenario
just tunnel BCP.

There is a useful scenario for every [extant] protocol, for example, in
your reply to Jed you pointed out where VLANs would and would not make
sense.  We are certainly not discounting BCP in the bigger picture, just
stating that there is need for another way to skin a cat.

Certainly if the world were limited to PPP over modem dial the existing
L2TP would continue to service us for many more years to come.

> What I've said is that for addressing that

I suspect we will never see eye-to-eye on this point.  Our
implementational experience has shown EoL2TP to be far more scalable
than BCP/PPP/L2TP is.

> pursuit of market share or technical purity is quite literally none of

This is going down a tangent.  I would have made the same point even if
I were self-employed.  The point is that any protocol must (a) be
technically strong (b) be useful.  While we disagree on (a), I was
stressing that without (b) a protocol design is ultimately futile, as it
would never be adopted and we may as well exert ourselves in more
fruitful directions.

R.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 17 Jan 2001 16:42:24 -0500

Keep up the great debate, folks. Chiming in a bit here on a couple of
points.

Rene Tio wrote:

[ snip ]

> mostly because I view that as orthogonal to this discussion.

Yes, let's try to keep the discussions separate. Ethernet over L2TP was
not the only proposal that approached l2tpext about using L2TP to tunnel
protocols other than PPP. Even if the consensus is not to persue the
Ethernet over L2TP draft as a working group item, then there is still a
question about L2TP's use for circuit emulation.

[ snip ]

> implementational experience has shown EoL2TP to be far more scalable

I would like to drill down on this a bit, Rene. First, have you tried
both approaches, or is this intuition rather than implementation
experience? For scalability, are we just talking about PPP negotiation
and state here, or is there some other fundamental concern? If we are
talking about something else, is this scalability concern fundamental to
one of the protocols being discussed, or is it a platform-specific
issue?

Thanks,

- Mark

---

From: Suhail Nanji <[email-masked]>
Date: Wed, 17 Jan 2001 14:47:33 -0800 (PST)

> one of the protocols being discussed, or is it a platform-specific

We did not do a direct comparison between BCP/PPP/L2TP and EoL2TP.
However, we tried two approaches for external IPCP/PPP subscribers (ie,
without an endpoint created in the LAC):

	 (a) with LCP negotiation performed on the LAC

	 (b) without any LCP negotiation on the LAC (thus obviating PPP
	     negotiation & state requirements in the LAC).

The latter scaled much better in that we were able to bring up
significantly more sessions with the same memory and CPU resources.  This
is similar to comparing BCP/PPP/L2TP vs EoL2TP without taking into account
the creation for the BCP/PPP endpoint in the LAC.

For scalability concerns, we are just talking about BCP/PPP negotiation and
related state.

---

From: James Carlson <[email-masked]>
Date: Thu, 18 Jan 2001 07:54:20 -0500 (EST)

> tens or hundreds of thousands of subscribers.

Have you measured this versus the per-session signaling overhead for
L2TP?  Are the CPU cycles or the bytes of memory required for PPP+L2TP
significantly different from L2TP alone?  Numbers would be good here,
especially since you're claiming an efficiency improvement and would
like other vendors to do additional work to support your changes.

(Note that if you want to ship something proprietary outside of the
IETF, nobody will stop you.  There is no need at all to go through the
IETF in order to ship altered or extended IETF protocols.  The IETF
isn't a standards body like the ITU.  Consenting peers may do anything
they please.  Thus, by going through the IETF, you are expressly
asking [possibly many] others to adopt and support your work.  Are you
sure that's what you wanted?)

> EoL2TP vs. BCP+L2TP.

My point is that the argument about the overhead of keeping PPP state
is based on false assumptions.  The PPP state overhead, in terms of
bytes per session, is far below the inherent L2TP overhead.

>  Besides, the only place where sequence numbers

This is precisely the point.  On the data path, PPP incurs zero CPU
overhead and zero state storage overhead -- there are no per-packet
stateful operations going on.  On the data path, L2TP incurs nonzero
CPU and state storage overhead -- for this application, sequence
numbers must be assigned and checked.  So why optimize the one part of
the system that is not affecting forwarding performance?

Assuming the issue is actually session start-up and shut-down rates
(to which you alluded above), eliminating PPP is still a dubious
optimization.  The primary limiting factor in connection rates is the
L2TP per-session signaling, which should work out to window/delay/3
sessions per second (where '3' is the number of messages required to
start a connection; a conservative implementation would probably wait
until the ICCN is acked, raising that number to 4), and a very
important secondary limiting factor is the burst tolerance (queue
depth) of the devices between the LAC and LNS.

Thus, what you should see in steady-state during set-up for a very
large number of connections, is a rolling window-sized batch of
sessions being set up at one time (eg, 100 ICRQs, then 100 ICRQs and
100 ICRPs, then 100 ICRQs+ICRPs+ICCNs, then 100 ICRQs+ICRPs+ICCNs+LCP
Configure-Requests, and so on).  The net effect is that PPP
negotiation adds a latency to the total set-up time, since the last N
sessions are forced to wait for PPP to complete, but this latency is a
constant two round trip times for the LCP+BCP case, and is not
affected by the number of sessions being set up.

PPP certainly also adds to the traffic required.  However, I would
argue that the user traffic itself causes nearly the same effect
(perhaps with less determinism).  As each L2TP sesssion goes open, the
floodgates are released and user packets flow through the tunnel.
These will (unless differential queuing is involved) affect the queue
depths of the intermediate devices and the connection set-up rate over
large numbers of sessions will trend downward.  (Note that those users
may have queued requests and retransmissions that will be sent as soon
as the session becomes available again.)

For those reasons, I would submit that the proof of any gained
efficiency from the removal of PPP is on the claimant.

> useful.  If we put signalling into something like GRE we'd get flamed

Yes, that's where we differ.  I would draw the line right before
inventing a new protocol.

> Apologies.  _L2TP_ voluntary tunneling, carrying BCP.

I'm not sure I understand your point here.  BCP over PPP has multiple
interoperable implementations.  L2TP carrying PPP also has multiple
interoperable implementations.

Are you saying that because users (as far as we're given to know)
haven't yet had a need to configure BCP/PPP/L2TP that this isn't a
supported configuration?  Or are you saying that every configuration
or combination of IETF protocols requires a draft saying that this is
a legal thing to do?  (Should there be an IPXCP/PPP/L2TP draft and an
ATCP/PPP/L2TP draft?)

> some bearing.  The FSM state requires far more than one bit to store.

In that case, let us count the bits required.  We'll assume just LCP
and BCP with some "reasonable" features that are roughly equivalent to
EoL2TP.  (LCP with ACFC and PFC, BCP with no options at all.)

We'll first need two bits to represent the necessary phases (dead,
establish, network, terminate).  During LCP negotiation, we require:

	- 4 bits to represent the 9 negotiation states (could be
          trimmed to 3 bits with care)
	- 2 bits to represent local and remote ACFC state
	- 2 bits to represent local and remote PFC state

When LCP is done negotiating, we can reuse the 4 bit negotiation state
(because the establish->network phase transition encodes the fact that
LCP.state == 9) for BCP.  Once done with that, we need only one bit to
represent the "BCP is in Opened state" information (this could be
equivalently encoded as a new PPP phase, as is often done in most PPP
implementations; the state impact is the same).

Thus, during negotiation, we need 6 bits of state information plus
four ephemeral bits.  Once negotiation is complete, a total of 7 bits
are required for each running session.

(If you choose to add BCP Tinygram compression, a very useful feature
that is absent from EoL2TP, that would add 2 bits to the above.)

I'll certainly admit that 7 bits are more than 1.  However, as I noted
above, L2TP requires at least 32 bits per session for the packet
sequence numbers, and likely many more.  (Tunnel IDs are another 32
bits; and perhaps more depending on the way sessions are demultiplexed
internally.)

> or more and it becomes significant.

Please quantify that.  It's far from clear that CPU cycles are the
dominant performance factor in any reasonably modern system.

I'm always extremely skeptical of CPU performance based alterations to
networking protocols.  Experience has shown that networking protocols
vastly outlive any perceived system performance bottleneck, and that
designing with yesterday's or even today's bottleneck in mind is
short-sighted.

> application for EoL2TP, and stating that there are other scenarios where

If EoL2TP might work but BCP/PPP/L2TP is better in some scenarios,
then I assert that EoL2TP's applicability is limited from those
scenarios.  Further, since there are known cases where BCP/PPP/L2TP
works but EoL2TP does not (the separate LAC and PPP 'client' case),
EoL2TP is more limited than that.

What, precisely, is the applicability statement for EoL2TP?

> Isn't that just bridging?  And why would you use this?  In this scenario

That's exactly my point.

> stating that there is need for another way to skin a cat.

BCP already supports VLANs and requires no protocol changes.  EoL2TP
protocol is different in that respect.

> implementational experience has shown EoL2TP to be far more scalable

If you'd share that experience with the group, I'm sure many of us
(myself included) would appreciate it.  I'm always interested in
scalable solutions.

> would never be adopted and we may as well exert ourselves in more

Agreed.

---

From: Rene Tio <[email-masked]>
Date: Thu, 18 Jan 2001 16:32:58 -0800

> like other vendors to do additional work to support your changes.

James, you are as guilty as I of this.  Neither your claim that L2TP
per-session overhead versus my claim of PPP session overhead being the
limiting factor to scalability are backed up by hard numbers measured on
a production box.

What I have seen are two different vendor implementations (both popular
production boxes) under PPP session load.  One of these projects
involved legacy code, the other involved new code.  Both had trouble
with state machine flaps and timing problems when confronted with
thousands upon thousands of state transitions.

... but as you state, no numbers.

(BTW, it has been pointed out to me that this is more a "serviceability"
issue rather than a "scalability" issue.  Either way it affects the
bottom-line number of PPP sessions supported on a box.)

> sure that's what you wanted?)

If you equate "adopt and support" with "going standards track", no it
wasn't, not initially.  The draft began life as Informational.  In view
of the charter perturbation this would cause it's probably better for
all concerned to go Informational.

Beyond that I think we're at an impasse.  Your analysis below is
excellent and I have nothing to say in return except that past
experiences with large-scale PPP termination devices have shown me
otherwise.  You're absolutely right in that L2TP introduces its own
signalling overhead, I have certainly seen problems there as well.  We
simply chose to use L2TP as a baseline since most LACs already run that
but decided not to add more per-session overhead with PPP.  Networks
can't be proven mathematically and certainly my beliefs have been
coloured by my experiences.

What we will do, as you and others have requested, is add an
applicability statement.

Regards,
Rene

---

From: James Carlson <[email-masked]>
Date: Fri, 19 Jan 2001 06:33:22 -0500 (EST)

> limiting factor to scalability are backed up by hard numbers measured on

My position does have one advantage over yours: I'm not proposing this
new protocol that claims to reduce overhead.

Since it appears that you are introducing a new protocol that is
intended to repair overhead problems in existing protocols, I suggest
that the ball is in your court.

> thousands upon thousands of state transitions.

I certainly agree that it's (rather unfortunately) not uncommon to
find lousy implementations of PPP.  It's probably also the case that
some implemenations of L2TP are flawed.  I believe that all of those
holes must be plugged before discarding the standard solution.

> all concerned to go Informational.

Going to Informational basically makes the discussion moot.  You
aren't then required to seek any consensus or interoperability.  (I'm
still not happy with that, because most customers don't know the
difference between 'standards track' and 'informational,' and all of
the more annoying and flawed things I've been forced to support were
'informational.'  But there's nothing I can do.)

> but decided not to add more per-session overhead with PPP.

I wasn't necessarily suggesting that you dump L2TP, but rather that
the analysis of the source of overhead isn't simple at all, and that
for the sake of interoperability and non-duplication of effort, *ALL*
available avenues of reducing overhead in a given implementation must
be explored before a new protocol is proposed to fix the problem.

>  Networks

Point taken.

> What we will do, as you and others have requested, is add an

OK.