Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

From: Klausberger Walter <[email-masked]>
Date: Wed, 13 Jun 2001 15:27:55 +0200

> Jeff Mcadams wrote
snip...
> Indeed...and those are some pretty big "ifs" there.  This is all a bit
> of blue sky thinking I guess.  For the DS discussion though, it looks
> like a change to the sequence number fields and/or S bit is going to be
> necessary, so this would be a good time to get at least this part right.
> Going on and changing other parts of the header may be a bit much to
> tackle at this point...unless we do take this, and l2tphc, and maybe
> some of the other drafts and roll them into a new version of 
> L2TP as you mentioned.  The more I think about it, the more that idea
begins to
> appeal to me.  That's really a major project though and probably not
> something we really even need to consider at the moment...let these
> proposals live on a drafts and move down the track that they're on and
> down the road we can roll them all together into a new L2TP version if
> we like.  *shrug*
snip...

I totally agree with Jeff. Scanning the mailing list, I see that there are a
lot of discussions regarding DS, fixed header, header compression going on.
All this should and will lead to some kind of redefinition of L2TP and I
also see a huge amount of work to do. To keep discussion going on and come
to some results, drafts are a good way to go, but I think we will need a new
basic L2TP RFC to summerize all the changes needed and some additional ones
to define PPP over L2TP, Ethernet over L2TP and the like.

Using a new UDP port seems a bit too much to me, but if this necessity comes
out of the drafts we will have to consider it.

regards
- walter

---

From: Skip Booth <[email-masked]>
Date: Wed, 13 Jun 2001 09:34:36 -0400

> out of the drafts we will have to consider it.

We should have used a different UDP port to start with.  Personally I'd be
in favor of this.  I can't stand having to do that L2F versus L2TP check in
our code.  Staying on the same port with a yet another header means one
more check in the fastpath.  As long as we are talking about ports, I'd
like to see us define a separate port for the control channel than the data
channel.  Or take the L2TP HC route and run L2TP directly on top of IP.
Again there are advantages to this approach in both the fastpath (less
checks) and also it allows you to provide different levels of security for
your control path versus your data packets.

-Skip

---

From: Ignacio Goyret <[email-masked]>
Date: Wed, 13 Jun 2001 09:39:34 -0700

At 09:34 AM 6/13/01 -0400, Skip Booth wrote:
>channel.

Amen, Brother!

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 13 Jun 2001 14:17:18 -0500

> >like to see us define a separate port for the control channel than the data

For History's sake, let's not forget the motivation of the day. Years ago we
chose to run over UDP for NAT and firewall friendliness (imagine the foresight,
as NATs become ever so prevalent on the planet and a number of other protocols
scramble to run in NAT-compatibility mode by inserting UDP). Running data and
control over the same channel actually makes this easier on both. 

As for L2F and L2TP multiplexed, yeah, we could have got a new UDP port type I
guess. But, if you are going to have a version field in your header anyway, you
still have to do a compare. So, aside of a possible layering concern with regard
to the ability to classify without peeking beyond standard IP/UDP, a new port
number would have only been a significant plus in overall header processing
speed if it was chosen in conjunction with tossing the version field, which I
don't think anyone was prepared to do at the time. 

That said, I agree that it would be nice to have what amounts to an "Alternate
Data Channel" for those that remember the -adc draft for data in those
environments that can capitalize on it.

Just goes to show you that there is always a tradeoff!

- Mark