Subject: RE: Do we want a new L2TP Header?

From: "Umesh Sirsiwal" <[email-masked]>
Date: Tue, 22 May 2001 11:01:33 -0400

I will agree that a fixed header would make microcoded
engines lot easier to implement and will improve overall
performance. 

When we are at it... I have another question with respect
to L2TP. That involves ineraction of L2TP with
draft-ietf-l2tpext-ds-03.txt.
This draft addresses issue with respect to DS based differentiation
between different tunnels which means differentiation 
between different subscribers. In a QoS enabled world
it is essential to differentiate between differnt types 
of traffic from the same subscriber. That can be used
for VoIP, video delivery, etc. 

I know it is somewhat confusing with respect to layering
violations. However, I do not know where else to address
this issue. L2TP provides L2 tunneling, and should also
address issues with respect to differentiation of different
types of traffic in a tunnel. 

Comments?

-Umesh

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Monday, May 21, 2001 3:00 PM
To: [email-masked]
Subject: Do we want a new L2TP Header?

L2TP currently has two classes of headers. (1) Those defined in RFC2661,
and (2) those defined in draft-ietf-l2tpext-l2tphc-03.txt. Within each
class, we have more than one header we have to recognize, based on the
bits set in the beginning of the header or signaling that occurred at
session establishment (particularly for the case of l2tphc). 

Even in light of this complexity, we enjoy exceptional interoperability
among so many independent implementations that I lost count a long time
ago. Also, like many protocols, the variability defined in the original
specification has begun to converge into a more static subset of fields
that we most often see in L2TP deployments today. Rather than letting
nature continue to take its course for better or worse and require all
new implementations to continue to include code for what are
increasingly rare expectations, I would like to get a sense of the group
as to whether we should entertain definition of a new, fixed, header
with L2TP. Many of you have approached me offline about this, so I
thought that bringing the idea to the list would be appropriate.

An easy transition to a new header would be aided by the signaling that
we all support. We would simply advertise support for the new header at
tunnel and session establishment, much like we do for l2tphc. The hope
would be that, one day, all implementations would converge on this
header and that our hardware, ASICs, etc. only have to support this
rather than than the various headers we have today that are identified
on a per-packet basis. 

In the past, I have rejected a major change like this, citing that any
improvement in the header would not be worth disrupting our existing
interoperable codebases. However, with the open-heart surgery that is
ongoing in RFC2661 to separate the L2TP tunneling plane from PPP and
more and more people pushing L2TP processing down into microcode and
ASICs (essentially requiring a rewrite of our data paths anyway), I
wonder now is the time to go ahead and apply what we have learned over
the past 5 years with hope of paving a way for the next 5 years. 

I have a set of ideas that have culminated over the past couple of years
that I would be happy to post to the list to initiate discussion, but
only if there is interest and consensus that definition of a new header
for L2TP is a Good Thing to do.

Comments appreciated,

- Mark