Subject: RE: [L2tpext] L2TP Header Compression L2TPHC-PPP-Protocol optiona l AVP

From: "Jitender Arora"<[email-masked]>
Date: Mon, 28 Jan 2002 07:37:02 -0800

Hello ,

     As far as as i have understood , If we use the L2TPHC-PPP-Protocol AVP
, then before that we must have sent the L2TPHC-No-Header , and it is
written in the draft that if we use the L2TPHC-No-Header AVP then we can
have only one session ( with the session id  equal to 0 ) ...SO there can't
be multiple sessions in that tunnel , there will be only one session .
      I am also having the same doubt that if we send the Protocol field
with this AVP , then how can we use LCP,CCPand NCP protocols for that
session .......means how are we going to switch from LCP to CCP and from CCP
to NCP....... 

Thanks and Regards,
jitender 

-----Original Message-----
From: Daniel Feldman [mailto:[email-masked]]
Sent: Monday, January 28, 2002 2:35 AM
To: [email-masked]; [email-masked]
Subject: [L2tpext] L2TP Header Compression L2TPHC-PPP-Protocol optional
AVP

	Dear Mr. Valencia and L2TPers,
	reading
http://search.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tphc-04.txt,
I didn't quite understand the usage of the L2TPHC-PPP-Protocol optional
AVP.
	The draft says: 
"Another optional AVP, ``L2TPHC-PPP-Protocol'', may be sent immediately
following the ``L2TPHC-No-Header''. If both sent and received, its Value
field indicates the PPP protocol number which will be the single value
carried in the payload of all PPP packets, and the payload transmitted
through L2TPHC will omit PPP HDLC flags and control, as well as the one
or two byte protocol field. The receiving side would then have to
recreate a suitable PPP header and insert it onto received payload."
	Does this mean that:
a) Only one NCP can run at a given time on the many sessions of the
Tunnel? Or is it per session?
b) There will be absolutely NO LCP packets on this tunnel? Else, how can
they be identified? 

	Thanks in advance,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Feldman
System Architecture Team Leader, IC4IC Ltd.
office: +972(4)959-4644 ext. 121
mobile: +972(55)99-0299
fax:    +972(4)959-4944
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Andy Valencia <[email-masked]>
Date: Thu, 31 Jan 2002 08:07:48 -0800

["Jitender Arora"<[email-masked]> writes:]

>...

In its minimal form, the intent was that the HC session handled only the
single, payload intensive part of the session.  All others would continue to
use L2TP over UDP.

However, based on pushback from our IESG representative, L2TPHC is unlikely
to move forward as a standard.  If this WG wants a standards-track document,
someone will most likely have to come forward and develop a protocol based
on RFC 3095.  3095 didn't exist when HC first passed last call, but it was
delayed enough that 3095 is a done deal, and HC isn't, and that's the way
the game is played.

I, personally, have no interest in being the person to work on this
3095-based scheme.  If there are companies who have actually sold and
deployed L2TPHC, then at most I'm willing to see HC end up as an
Informational status.  Otherwise I'm ready to put HC on the shelf and let
somebody else pursue the quest for a reduced L2TP header.

Andy Valencia

---

From: Skip Booth <[email-masked]>
Date: Thu, 31 Jan 2002 14:40:35 -0500

> somebody else pursue the quest for a reduced L2TP header.

With L2TPv3 running directly over IP, the default header is only 4 bytes so
I'm not so sure that HC has much of a life anyway (unless someone really
want's to save 3 bytes).

-Skip

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 31 Jan 2002 23:16:15 +0100

> I'm not so sure that HC has much of a life anyway (unless someone really

Well, 4 bytes + at least 1 more from the PPP header (there was a mode that
negotiated away the PPP protocol field as well). 

There was a time when, yes, people really did want to save a few bytes per
header, and I have some indication that l2tphc was implemented by those
(deployed is another story altogether). It's sort of in the same limbo that l2tp
over ATM is, e.g. something that was important at one time, was implemented
according to the draft, but has since fallen by the wayside of active
development... It probably should have become an RFC a long time ago back when
people were implementing it, and now we would simply be discussing whether or
not to move it to historic status or not.