Subject: I-D ACTION:draft-elwin-l2tpext-ppvpn-00.txt

From: [email-masked]
Date: Tue, 20 Nov 2001 07:13:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: L2TP Extensions for PPVPN
	Author(s)	: E. Stelzer, N. Gowda
	Filename	: draft-elwin-l2tpext-ppvpn-00.txt
	Pages		: 8
	Date		: 19-Nov-01
	
Provider Provisioned  VPNs (PPVPNs)  need  a  tunneling  mechanism and a
means to automatically discover VPN membership and signal these tunnels.
This draft  elaborates the use of  L2TP as the  tunneling mechanism, and
defines  extensions  to  L2TP  to  handle  VPN  membership  discovery to
leverage  PPVPNs.  Additional AVPs  are defined, and their behaviour are
explained.  The solution presented here  is applicable  for both L3 VPNs
and L2 VPNs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-elwin-l2tpext-ppvpn-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-elwin-l2tpext-ppvpn-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-elwin-l2tpext-ppvpn-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 20 Nov 2001 11:21:05 -0800

>5.2 PPVPN-Control AVP
>
>This AVP is sent to the peer to inform about creation of PPVPN Control
>tunnel. This AVP MUST be present in SCCRQ and SCCRP to support L2TP
>extensions for PPVPN. The initiator of Control Tunnel will send this AVP
>in SCCRQ with M-bit set. Upon receiving SCCRQ, the peer MUST send
>StopCCN if it doesn't support PPVPN extension, or MUST reply with SCCRP.
>If the initiator gets StopCCN then it MUST not attempt to create Control
>Tunnel with the same peer. If the initiator recevies SCCRP, then it can
>send SCCCN to get the Control Tunnel to Established State.
>
>    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
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |M|H| rsvd  |      Length       |           Vendor ID           |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         Attribute Type        |         Reserved              |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>This AVP MAY be hidden (the H-bit set to 0 or 1) and is mandatory 
>(M-bit set). The length (before hiding) of this AVP is 8.

If the M-bit was clear instead of set, then the L2TP control connection
could be shared between PPVPN and non-PPVPN sessions.

In other words, I think a better solution is to have the M-bit clear (0),
then upon receiving an SCCRQ, if you only want to support PPVPN and the
remote didn't offer it, you can drop the tunnel altogether. On the other
hand, if you can support both PPVPN and regular L2TP traffic, then you
can proceed to signal the remote that you can do that by adding this
AVP into your own SCCRP.

Upon receiving an SCCRP without this AVP (after sending an SCCRQ _with_
this AVP), then the LCCE can decide whether this acceptable or not.

IMHO, it is much better if these decisions are done based on
configuration rather than protocol design. If nothing else, it will allow
for cleaner interoperability.

-Ignacio

---

From: Elwin Eliazer <[email-masked]>
Date: Wed, 21 Nov 2001 17:52:52 -0800 (PST)

Hi Ignacio,

Thanks for your feedback.
We did analyze the scenario that you are referring
here, and we think keeping things separate makes it
more clear, and also helps in implementation. 
For example clearing all PPVPN related tunnels will
not disturb non-PPVPN tunnels.

More comments inlined.

cheers,
Elwin.

--- Ignacio Goyret <[email-masked]> wrote:
> >    0                   1                   2      
>             3
> could be shared between PPVPN and non-PPVPN

Could you elaborate any specific advantage in this
sharing? Is it not better (and easier to implement) to
have separate tunnels for each purpose.
Also note that perVPN tunnels, are not just sessions,
but with a tunnel (control connection) also. Note that
each of the perVPN tunnel can have a separate
keepalive.

> for cleaner interoperability.

Could you describe this more. We think the other way.

> -Ignacio

=====
-------
Elwin Stelzer Eliazer
Corona Networks
-------

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1