Subject: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 8 May 2007 03:37:49 -0700

Hi everyone,

The following draft extends draft-yegani-gre-key-extension-02.txt for a
slightly different use of GRE-keys in PMIPv4. 

Let me know if you have any comments.

Best Regards
George 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, May 07, 2007 11:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt 

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

	Title		: GRE-based L2 Tunneling with PMIPv4
	Author(s)	: G. Tsirtsis, V. Park
	Filename	: draft-tsirtsis-l2gre-pmipv4-00.txt
	Pages		: 15
	Date		: 2007-5-7
	
   This specification introduces mechanisms for creating a GRE-based L2
   Tunnel with PMIPv4.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-tsirtsis-l2gre-pmipv4-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-tsirtsis-l2gre-pmipv4-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.
-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 11 May 2007 01:40:33 -0400

George,

A general question for clarification: is PMIPv4 accepted as a work item
in IETF? If not, I am not sure what is the goal of this (yet another
PMIP4 related) document.

-Kuntal

> From: Tsirtsis, George [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2007 5:38 AM
> To: [email-masked]
> Subject: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt
> 
> Hi everyone,
>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 11 May 2007 07:12:00 -0700

Kuntal,

As you know, at this point, PMIPv4 is not part of any WG charter.

As far as I understand, however, anyone can submit a personal draft. All
work in the IETF, in fact, starts with personal drafts. I hope you do
not have a problem with that.

Regards
George

-----Original Message-----
From: Chowdhury, Kuntal [mailto:[email-masked]] 
Sent: Friday, May 11, 2007 6:41 AM
To: Tsirtsis, George; [email-masked]
Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt 

George,

-Kuntal

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 May 2007 09:47:48 -0500

Hi George,

I am not sure how did you categorize the proposed functionality in this
draft as a slightly different use from the functionality proposed by
draft-yegani-gre-key-extension-02 draft. In my understanding all IP
mobility protocol is used to establish L-3 mobility via allowing the
Mobile Node to be able to use its IP address (Home) regardless of the
point of attachment. However, it seems to me that what you are trying to
propose here is to use PMIPv4, which is a network based IP mobility
protocol, to establish a layer-2 tunnel, I may say a L-2 mobility, by
violating the very basic principle of IP mobility.

Are you suggesting here a new protocol using messages that already
defined in IP Mobility v4 space?

Thanks.

Regards,
Ahmad

> Sent: Tuesday, May 08, 2007 3:38 AM
> To: [email-masked]
> The following draft extends 
> draft-yegani-gre-key-extension-02.txt for a slightly 
> different use of GRE-keys in PMIPv4. 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 24 May 2007 03:43:06 -0700

Hi Ahmad,

Sorry for the delay in responding to you.

GRE is an encapsulation method that can be used to transport any number
of protocols on top of it (not limited to IP). The IETF has defined a
number of mechanisms including L2TP, Pseudowires, MPLS etc, all of which
are building L2 tunnels over IP, so I am not sure to what exactly you
object.

In any case, the intention of the draft is, in fact, much more "IP
friendly" than you think....although IP friendliness is not a clear
requirement for IDs I think :-) 

Let me explain. Take as an example a PMIPv4 based network. In some such
networks, when the network detects that a node attaches, the MPA
registers to the HA. This typically creates a MPA-HA tunnel, connecting
the mobile to the HA via the MPA, and it also allocates an IPv4 address
to that mobile.

If in the same network one wants to support IPv4, IPv6 and Dual Stack
mobiles, the following problem arises. PMIPv4 (even extended with
DSMIPv4), ALWAYS allocates an IPv4 address to the mobile, whether the
mobile needs it or not, and even if the mobile is IPv6 only or if it is
Dual Stack but it does not use the IPv4 stack.

Note that when PMIPv6 is used this may not be such a concern because one
can "waste" some IPv6 addresses or even /64 prefixes to keep things
simple. In IPv4, however, due to the shortage of IPv4 addresses, such
waste is some times not acceptable.

The draft, allows PMIPv4 to set-up a tunnel without allocating an IPv4
address to the mobile. The mobile can then run DHCPv4, DHCPv6, RS/RA, or
whatever address configuration mode it supports to configure its IP
stack, so the "waste" of addresses is avoided.

I hope this helps.
George

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Thursday, May 17, 2007 3:48 PM
To: Tsirtsis, George; [email-masked]
Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt

Hi George,

Thanks.

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 24 May 2007 12:13:22 -0500

Hi George,
Please see comments inline.

Regards,
Ahmad
 
> Sorry for the delay in responding to you.

[Ahmad]
np.

> 
> GRE is an encapsulation method that can be used to transport 
> any number of protocols on top of it (not limited to IP). The 

[Ahmad]
We do not disagree here. As a reference, the following text is extracted
from RFC1701:

"
Abstract

   This document specifies a protocol for performing encapsulation of an
   arbitrary network layer protocol over another arbitrary network layer
   protocol.
"

> IETF has defined a number of mechanisms including L2TP, 
> Pseudowires, MPLS etc, all of which are building L2 tunnels 
> over IP, so I am not sure to what exactly you object.

[Ahmad]
I do not think I raised the issue of what GRE is used for. Please reread
my posting.
> 
> In any case, the intention of the draft is, in fact, much 
> more "IP friendly" than you think....although IP friendliness 
> is not a clear requirement for IDs I think :-)

[Ahmad]
It has nothing to do with IP friendly or not, IMO. However, when you
announce the publication of your ID on MIP4 mailing list, you, I guess,
expect people to point out if the ID use of MIP4/PMIP4 is not inline
with what these protocol are developed for. 
 
> 
> Let me explain. Take as an example a PMIPv4 based network. In 
> some such networks, when the network detects that a node 
> attaches, the MPA registers to the HA. This typically creates 
> a MPA-HA tunnel, connecting the mobile to the HA via the MPA, 
> and it also allocates an IPv4 address to that mobile.

[Ahmad]
Ok.
> 
> If in the same network one wants to support IPv4, IPv6 and 
> Dual Stack mobiles, the following problem arises. PMIPv4 
> (even extended with DSMIPv4), ALWAYS allocates an IPv4 
> address to the mobile, whether the mobile needs it or not, 
> and even if the mobile is IPv6 only or if it is Dual Stack 
> but it does not use the IPv4 stack.

[Ahmad]
Few points here:
1. PMIPv4 is NOT a standard yet, so I am not sure how to judge what you
are citing here. 
2. Are you aware of any PMIPv4 deployment which address IPv6 ONLY MN. I
doubt that operators have extra IPv4 to waste.
3. In comparison, PMIPv6, which on standard track, should not have the
same problem, IMO.
4. For the sake of this argument, let us assume what you said about
PMIPv4. I would like to remind you here, that the allocated IPv4 address
is still topologically correct and can be used to reference the MN
binding. i.e. that IPv4 address is still routable if necessary.

> 
> Note that when PMIPv6 is used this may not be such a concern 
> because one can "waste" some IPv6 addresses or even /64 
> prefixes to keep things simple. In IPv4, however, due to the 
> shortage of IPv4 addresses, such waste is some times not acceptable.

[Ahmad]
I think this is irrelevant to the discussion. We are not comparing how
PMIPv4 vs. PMIPv6 would be used to establish dynamic L-2 GRE tunnel.
 
> The draft, allows PMIPv4 to set-up a tunnel without 
> allocating an IPv4 address to the mobile. The mobile can then 
> run DHCPv4, DHCPv6, RS/RA, or whatever address configuration 
> mode it supports to configure its IP stack, so the "waste" of 
> addresses is avoided.

[Ahmad]
Again, I am not debating the value of generating a dynamic GRE keys to
establish GRE tunnel dynamically. I think that functionality is a good
one. My point here is you are using PMIPv4 to establish GRE tunneling
dynamically. That is against the basic principle of PMIPv4, assuming it
is an extension to MIPv4 for now.

Let me explain a little more here:
1. GRE encapsulation as per RFC1701, although it is not mentioned
explicitly, but the assumption is the key is static. But still, RFC2890
stated that is out of scope.
2. Anyway, we need to distinguish between two cases here:
2.1. using MIPv4/PMIPv4 to exchange GRE keys between peers while
establishing a MIPv4/PMIPv4 session, for example to identify a private
IPv4 address session.
2.2. using MIPv4/PMIPv4 to establish a per MN dynamic layer-2 tunnel.
That is NOT within the scope of IP mobility.

3. Having said all of the above, If you would like to use the
MIPv4/PMIPv4 signaling messages to establish a per MN Layer-2 tunnel,
that is FINE with me. However, that is totally a different animal than
calling it "using PMIPv4 protocol" In other words, my question from my
initial posting still valid:

" Are you suggesting here a new protocol using messages that already
defined in IP Mobility v4 space?"
In your response, I did not see any answer for this question.

4. Finally, with respect to you citing L2TP, MPLS, etc in this context,
I would like to mention the following:

4.1.: RFC2661, define a whole new protocol for achieving an on demand L2
tunnel, which is what you are trying to achieve in your ID using the
wrong protocol, Please take a look at the following from RFC2661:
"
   This document defines the necessary control protocol for on-demand
   creation of tunnels between two nodes and the accompanying
   encapsulation ......

> I hope this helps.

[Ahmad]
Sure it did. Please see comments above.

> I am not sure how did you categorize the proposed 
> functionality in this draft as a slightly different use from 
> the functionality proposed by
> draft-yegani-gre-key-extension-02 draft. In my understanding 
> all IP mobility protocol is used to establish L-3 mobility 
> via allowing the Mobile Node to be able to use its IP address 
> (Home) regardless of the point of attachment. However, it 
> seems to me that what you are trying to propose here is to 
> use PMIPv4, which is a network based IP mobility protocol, to 
> establish a layer-2 tunnel, I may say a L-2 mobility, by 
> Are you suggesting here a new protocol using messages that 
> already defined in IP Mobility v4 space?
> 
> Thanks.
> 
> Regards,
> Ahmad
>  
> 
> >    This specification introduces mechanisms for creating a 
> GRE-based 
> > L2
> >    Tunnel with PMIPv4.
> > 
> > 
> > logging in, type "cd internet-drafts" and then "get 
> > draft-tsirtsis-l2gre-pmipv4-00.txt".
> > 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 25 May 2007 06:39:51 -0700

Ahmad,

Some comments inline....

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Thursday, May 24, 2007 6:13 PM
To: Tsirtsis, George; [email-masked]
Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt

...

GT> Ahmad, I do not understand what you mean by "new protocol". The
draft defines an extension which, when used in combination with PMIPv4,
provides additional functionality. i.e., it allows PMIP to set-up a
GRE-based L2 Tunnel specific to a given MN.
GT> Of course PMIPv4 is not a WG document. That is fine. I point to the
appropriate personal contributions in the draft.

GT> Ahmed, I only raised L2TP and MPLS because in your earlier e-mail
you criticized the proposal as follows: " ... you are trying to propose
here is to use PMIPv4, which is a network based IP mobility protocol, to
establish a layer-2 tunnel, I may say a L-2 mobility, by violating the
very basic principle of IP mobility." So I felt oblidged to point to you
that the IETF is not shying away from defining L2 tunneling mechanism. 

GT> The draft proposal is simply a mechanism enabling mobile L2
tunneling. I am not sure why this is not obvious but L2TP can not handle
movement. i.e., if one of the peers moves then L2TP stops working. This
proposal is a bit different. It allows a system that already uses PMIP
with GRE tunnels to set-up L2 Tunnels.

Regards
George

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 25 May 2007 16:24:55 -0500

Hi George,

Regards,
Ahmad

> MIPv4/PMIPv4 signaling messages to establish a per MN Layer-2 
> tunnel, that is FINE with me. However, that is totally a 
> different animal than calling it "using PMIPv4 protocol" In 
> other words, my question from my initial posting still valid:
> 
> " Are you suggesting here a new protocol using messages that 
> already defined in IP Mobility v4 space?"
> 
> 
> draft defines an extension which, when used in combination 
> with PMIPv4, provides additional functionality. i.e., it 
> allows PMIP to set-up a GRE-based L2 Tunnel specific to a given MN.

[Ahmad]
I see some contradiction here. You just said that you are using an IP
Mobility Protocol (L-3 mobility) to establish a (L-2 Tunnel) for the
same MN. OK, let me ask a question, Does not L-3 Mobility protocol
assumes that there is already a L-2 established.

BTW, your draft does not defines a new extension. This extension is
already defined in another personal draft:
draft-yegani-gre-key-extension-02. I know you most probably did not mean
that but for the sake of accuracy.

[Ahmad]
Ok.
> 
> 4. Finally, with respect to you citing L2TP, MPLS, etc in 
> this context, I would like to mention the following:
> 
> 4.1.: RFC2661, define a whole new protocol for achieving an 
> on demand L2 tunnel, which is what you are trying to achieve 
> in your ID using the wrong protocol, Please take a look at 
> the following from RFC2661:
> "
> you criticized the proposal as follows: " ... you are trying 
> to propose here is to use PMIPv4, which is a network based IP 
> mobility protocol, to establish a layer-2 tunnel, I may say a 
> L-2 mobility, by violating the very basic principle of IP 
> mobility." So I felt oblidged to point to you that the IETF 
> is not shying away from defining L2 tunneling mechanism.

[Ahmad]
George, IETF has a lot of L-2 tunneling mechanisms, However, GRE
tunneling is a Generic one which can be used for Layer-2 and Layer-3
tunneling. All drafts which use IP mobility protocol to establish a GRE
tunnel or actually negotiate a GRE key, uses it for establishing what we
can be called a L-3 GRE tunnel, IP over IP to be used for identifying a
flow or to be used in case of private IP address overlapping, etc. In
your case you are suggesting using a L-3 IP Mobility protocol to
establish a Layer-2 tunnel. I believe that is different.

> tunneling. I am not sure why this is not obvious but L2TP can 
> not handle movement. i.e., if one of the peers moves then 
> L2TP stops working. 

[Ahmad]
Excellent point, MIP4/PMIP4 is a L-3 Tunnel mobility protocol (If I may
call it that way) which has certain semantics and rules to allow IP
mobility. I do not see how this protocol can be used to establish a L-2
tunnel mobility without violating the semantics and rules of the L-3
tunnel mobility protocol. I believe that you are trying to use the
signaling of that protocol (MIP4/PMIP4) with some new rules to enable it
for establishing a L-2 tunnel mobility. If you agree with this
description, I have no problem with that approach. Basically we just can
not call the new set of rules with the existing MIP4/PMIP4 signaling
messages a MIP4/PMIP4 protocol.

I hope you do not have a problem here:-)

> This proposal is a bit different. It 
> allows a system that already uses PMIP with GRE tunnels to 
> set-up L2 Tunnels.
> 
> Regards
> George
>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Sun, 27 May 2007 06:02:39 -0700

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Friday, May 25, 2007 10:25 PM
To: Tsirtsis, George; [email-masked]
Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt

Hi George,

Regards,
Ahmad

[Ahmad]

GT> Ahmad, we are going in circles. Running L2 over L4/L3 is nothing new
or strange. It is called layering. As we discussed before, L2TP and MPLS
do exactly that. i.e., they are allowing an L2 connection to be
established over IP. GRE, itself is designed to do the same thing.

GT> Yes, correct.

[Ahmad]
Ok.

[Ahmad]

GT> Yes, it is different. If it was the same, I would not have to write
a draft about it.

[Ahmad]

GT> Ahmad, we are now approaching the bizarre :-) So, in your opinion,
instead of defining a flag in an extension, I should create a whole new
protocol that is 99.99% the same with MIPv4/PMIPv4 (as well as all the
multitude of extensions defined for them) but call it something
different. I think I might not do that, thank you.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 28 May 2007 08:17:48 -0500

> different. I think I might not do that, thank you.

[Ahmad]
Ok. However, the functionality you are trying to perform is not within
the scope of MIP4/PMIP4 nor the MIP4 charter.

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 28 May 2007 07:28:22 -0700

Ahmad, I disagree but that is OK. The issue of making this draft a WG
document has not come up yet...we can discuss this again if/when this
issue becomes relevant.

Regards
George

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Monday, May 28, 2007 2:18 PM
To: Tsirtsis, George; [email-masked]
Subject: RE: [Mip4] FW: I-D ACTION:draft-tsirtsis-l2gre-pmipv4-00.txt

[Ahmad]