Subject: [nemo] The use of GRE

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 11 May 2007 15:19:30 +1000

Hi all, 

This concensus call on issue 93 made me a bit confused about the use of GRE.
I have a simple question: 

Why can't people that want to use GRE (for PMIP) run it as follows:

IP Heahder (proto 47 for GRE)
GRE Header 
UDP
....etc

Why do we need to add another layer to qualifiers instead of using the
existing allocated numbers?

It's been a couple of years since I read the GRE spec so I wanted to
understand if this format is a problem

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 10 May 2007 22:25:50 -0700

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Thursday, May 10, 2007 10:20 PM
> To: [email-masked]; [email-masked]
> Subject: [Mip6] The use of GRE
> 
> Hi all, 
> 

Problem will be with the NAT/PAT device. It wont create NAT bindings
from the UDP header encapped in the GRE header.

Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 11 May 2007 15:32:09 +1000

> from the UDP header encapped in the GRE header.

=> So you want to use GRE in a *local* domain where a NAT separates the MAG
and the LMA? 
In DSMIP we don't care or want to use GRE, therefore we don't have a NAT
problem. But are you really saying that you have a NAT problem in NETLMM ? 

I think the reasons for this are getting very slim. I was hoping to actually
see a good reason so I can say ok we've added 4 bytes but there is potenial
benefits here, but given this I think it's just wasteful to do this and make
it a default. 

If you want to use it in PMIP, I think you should add that additional UDP
header specifically for PMIP and NAT cases, I don't think normal hosts and
routers should carry the burden over the air interface for PMIP to avoid 8
bytes over a a wired network.

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 10 May 2007 22:45:52 -0700

> Sent: Thursday, May 10, 2007 10:32 PM
> To: 'Sri Gundavelli'; [email-masked]; [email-masked]
> Subject: RE: [Mip6] The use of GRE
> 
> 
> 

MIP4 has GRE support and has wide use for the MR case also 
for the FA-CCOA mode. So, we can keep PMIP out of this
discussion. IMO, GRE mode is useful for HA-MR tunnel. 

> bytes over a a wired network.

We dont have to justify this just for PMIP. Its just another
consumer, like NEMO. IMO, having a thin header, always helps,
follows the conventional way of tagging. Also, to extend this
later for NEMO, we cannot use the same port, as the old
and new implementation will have a problem dealing with UDP
payloads with GRE and no GRE headers, at the same time. Any
ways, this is my one opinion.

Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 11 May 2007 15:52:08 +1000

> discussion. IMO, GRE mode is useful for HA-MR tunnel. 

=> You can also keep MIP4 out of this discussion because we're talking about
DSMIPv6. 
If we take PMIP out of the discussion then there is no reason for GRE
whatsoever. 

 > follows the conventional way of tagging. 

=> My problem here is that you're not giving me any concrete reasons for a
use case.
Just saying "always helps" doesn't make me understand something new. There
is only two IP versions today and this is not going to change till you and I
retire, so I don't find this flexibility argument realistic. 

   Also, to extend this
 > later for NEMO, we cannot use the same port, as the old

=> Extend what for nemo??? Nemo is already supported in this spec.

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 10 May 2007 23:06:26 -0700

> retire, so I don't find this flexibility argument realistic. 

GRE header is applicable when flows from multiple nodes are carried
in the same tunnel. That's not the case for 3775 MN flows, but indeed
is the case for 3963. The GRE header has the proper semantics that
allows tunnel peers to process properly. The seq number in the header
is useful when carrying real time traffic. Is this not a good reason ?
Now, if you say there is no GRE tunneling for MIP6, off course, thats
where I say, there is a chance we will introduce GRE tunnel mode
for NEMO use cases in mind, learnt from the experience of supporting
NEMOv4 deployments and applications. Sure, supporting GRE mode helps
PMIP as well, I agree, if we apply it there. Second reason, I give
is the convention that has been followed in all protocol designs so
far, of prev header identifying the next header. No protocol is mucking
around in the payloads to determine the type. Are these not good
reasons ? Do they outweigh the 4 byte saving ? Again, this is my
opinion. We can let others comment on this.

Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 11 May 2007 16:21:04 +1000

Sri, 

 > is useful when carrying real time traffic. Is this not a 

=> This is a classic example of hacks that lingered for such long time that
it grew on people and they thought it's just the "normal" way of doing
things. 
I think your arguments above are quite confused about GRE. It's like the
very common arguments about NATs being good for security. 
The need for another abstraction layer for tunnelling was only to support
virtual routing, especially for environments that conntain overlapping IPv4
addresses. 

Everything else you talk about above is available in IP and transport
headers; and I won't even get into QoS for IP flows. You seem to think that
this is a special case for nemo because there can be "many flows", which is
not the case in a 3775 MN. This is clearly a confused view of things because
a MN can of course generate many flows, from different addresses ....etc
....sigh 

 > NEMOv4 deployments and applications. 

=> I think I've said enough on this. I don't think I can add any more. I
honestly think what you're listing above is either confused or a case of you
wanting everyone else to fit some idea in your mind, which we don't know. 

   Sure, supporting GRE mode helps
 > around in the payloads to determine the type. 

=> Mucking around? There is a very well known encoding mechanism called TLV
where you have to inspect the first byte to know the type of information
following it. I don't think that's referred to as mucking around, at least
not in specs.. ;0

enuff said from me.
Hesham

Are these not good

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 10 May 2007 23:29:52 -0700

Hi Hesham,

Ok. Thanks for the discussion. 

Sri

> Sent: Thursday, May 10, 2007 11:21 PM

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 10 May 2007 23:37:38 -0700

I'm confused by this thread - could someone explain the role of GRE for
NEMO?  From everything I've read so far on this thread, I'm with Hesham
here - I don't understand why we need GRE to parse the multiple flows
sent in the MR's tunnel.  

Vidya 

> Subject: [nemo] RE: [Mip6] The use of GRE
> 
> Sri, 
> 
>  > >  >
>  > >  > We dont have to justify this just for PMIP. Its just 
> another  > >  > consumer, like NEMO. IMO, having a thin 
> header, always helps,  > >  > follows the conventional way of 
> tagging. 
>  > >
>  > > => My problem here is that you're not giving me any 
> concrete  > > reasons for a  > > use case.
>  > > Just saying "always helps" doesn't make me understand  > 
> > something new. There  > > is only two IP versions today and 
> this is not going to change  > > till you and I  > > retire, 
> so I don't find this flexibility argument realistic. 
>  > >
>  >
>  >
>  > GRE header is applicable when flows from multiple nodes 
> are carried  > in the same tunnel. That's not the case for 
> 3775 MN flows, but indeed  > is the case for 3963. The GRE 
> header has the proper semantics that  > allows tunnel peers 
> to process properly. The seq number in the header  > is 
> useful when carrying real time traffic. Is this not a  > good reason ?
> 
> => This is a classic example of hacks that lingered for such 
> long time that it grew on people and they thought it's just 
> the "normal" way of doing things. 
> I think your arguments above are quite confused about GRE. 
> It's like the very common arguments about NATs being good for 
> security. 
> The need for another abstraction layer for tunnelling was 
> only to support virtual routing, especially for environments 
> that conntain overlapping IPv4 addresses. 
> 
> Everything else you talk about above is available in IP and 
> transport headers; and I won't even get into QoS for IP 
> flows. You seem to think that this is a special case for nemo 
> because there can be "many flows", which is not the case in a 
> 3775 MN. This is clearly a confused view of things because a 
> MN can of course generate many flows, from different 
> addresses ....etc ....sigh 
> 
>  > Now, if you say there is no GRE tunneling for MIP6, off 
> course, thats  > where I say, there is a chance we will 
> introduce GRE tunnel mode  > for NEMO use cases in mind, 
> learnt from the experience of supporting  > NEMOv4 
> deployments and applications. 
> 
> => I think I've said enough on this. I don't think I can add 
> any more. I honestly think what you're listing above is 
> either confused or a case of you wanting everyone else to fit 
> some idea in your mind, which we don't know. 
> 
> 
> 
>  > PMIP as well, I agree, if we apply it there. Second 
> reason, I give  > is the convention that has been followed in 
> all protocol designs so  > far, of prev header identifying 
> the next header. No protocol  > is mucking  > around in the 
> payloads to determine the type. 
> 
> => Mucking around? There is a very well known encoding 
> mechanism called TLV where you have to inspect the first byte 
> to know the type of information following it. I don't think 
> that's referred to as mucking around, at least not in specs.. ;0
> 
> enuff said from me.
> Hesham
> 
> Are these not good
>  > reasons ? Do they outweigh the 4 byte saving ? Again, this 
> is my  > opinion. We can let others comment on this.
>  >
>  >
>  > Sri
>  > 
> 
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 11 May 2007 12:46:56 +0200

Sri Gundavelli wrote:
>> => My problem here is that you're not giving me any concrete 
>> reasons for a use case. Just saying "always helps" doesn't make me 
>> understand something new. There is only two IP versions today and 
>> this is not going to change till you and I retire, so I don't find 
>> this flexibility argument realistic.
>> 
> 
> 
> allows tunnel peers to process properly

Current implementations of NEMOv6 don't use GRE header and manage to
distinguish the flows from different LFNs through the same MR.

I don't know what is meant by 'same tunnel'.  The tunnel from MR to HA
has src MR's CoA and dst HA and inner is src LFN's address and dst CN.
BAsed on that the HA receiving a encapsulated packet from LFN can very
easily distinguish the flows.  No need of GRE.

> The seq number in the header is useful when carrying real time 
> traffic.

But real-time protocols have their own mechanisms with sequence numbers
no?  Why an intermediary layer between network and transport when
transport does it already.

> Is this not a good reason ? Now, if you say there is no GRE tunneling
>  for MIP6, off course, thats where I say, there is a chance we will 
> introduce GRE tunnel mode for NEMO use cases in mind, learnt from the
>  experience of supporting NEMOv4 deployments and applications.

_Some_ NEMOv4 deployments don't need GRE tunnels either.  NEMOv4
implementations rely on MIP4 and MIP4 has three ways of encapsulating,
only one them being GRE (the two others are IP-IP and UDP).  Some NEMOv4
deployments don't need GRE and they work.

> Sure, supporting GRE mode helps PMIP as well, I agree, if we apply it
>  there. Second reason, I give is the convention that has been 
> followed in all protocol designs so far, of prev header identifying 
> the next header. No protocol is mucking around in the payloads to 
> determine the type. Are these not good reasons ? Do they outweigh the
>  4 byte saving ? Again, this is my opinion. We can let others comment
>  on this.

Yes, I comment: I don't see the necessity of GRE in MIP6 at all, and
probably _some_ necessity in MIP4 (but MIP4 can do without GRE).

Alex

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 14 May 2007 07:04:27 -0700

Folks,

I have been trying to make sense of this discussion. After re-reading
the whole thread I think we may be able to progress if we answer the
following question:

QUESTION: Does this group agree that GRE encapsulation needs to be
supported in MIPv6?

If the answer is "NO", then using the already defined UDP port and the
IP version field to demux IPv4/IPv6 packets as already defined in
DSMIPv6 is absolutely fine and there is no reason to change it.

If the answer is "YES", then we have to consider the following:
It is clear that the IP version field can not demux GRE. In that case:
	a) Leave GRE out of DSMIPv6 draft (which uses IP version field
for demuxing). People interested in GRE should write up a draft defining
how GRE is used in MIPv6. This is likely to result in a GRE specific
method of encapsulation over UDP. This is likely to involve reservation
of one more UDP port and the definition of a small pseudo-header as
proposed by Sri and others.
	b) Be proactive and adopt the pseudo-header for all
encapsulations. This would mean that DSMIPv6 draft is changed to
indicate that over the reserved UDP port we add the TLV (or whatever
structure) which indicates what the next header is i.e., IPv4, IPv6,
GRE.

Personally, I am not a big fun of supporting GRE encapsulation for
MIPv6. The reason is that in IPv6 we do not have (and must never have)
to deal with overlapping address spaces (the main use of GRE tunneling
in MIPv4). 

Also note that even if we do decide to use the IP version field for
demuxing now, there is nothing that prevents GRE encapsulation to be
defined later, as indicated by (a) above, assuming that GRE support
becomes necessary. Yes, then implementation will have to deal with two
way of demuxing similar information but it is not the end of the world
and it reduces the overhead (albeit not much) in the typical case.

I hope this helps.
Regards
George

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Friday, May 11, 2007 6:26 AM
To: 'Hesham Soliman'; [email-masked]; [email-masked]
Subject: RE: [Mip6] The use of GRE

Sri

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 15 May 2007 00:12:54 +1000

George, 

That's exactly the point, I just wish this would have been made clear from
the start instead of talking around the issue. 

I see no reason for needing GRE in v6, including MIPv6. 

Hesham 

 > From: Tsirtsis, George [mailto:[email-masked]] 
 > Sent: Tuesday, May 15, 2007 12:04 AM
 > To: Sri Gundavelli; Hesham Soliman; [email-masked]; [email-masked]

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 14 May 2007 10:42:21 -0700

Alessio,

This is MIPv6, so I assume every mobile has a unique IPv6 Home Address.
I think that (and NAT-traversal) guaranties that even if the same mobile
has non-unique IPv4 addresses, routing works. I am not sure why GRE is
needed for this....or is it?

George

-----Original Message-----
From: CASATI, Alessio (Alessio) [mailto:[email-masked]] 
Sent: Monday, May 14, 2007 6:13 PM
To: Tsirtsis, George; Sri Gundavelli; Hesham Soliman; [email-masked];
[email-masked]

*Folks,
*
*I have been trying to make sense of this discussion. After 
*re-reading the whole thread I think we may be able to progress 
*if we answer the following question:

This is an excellent idea George!

*QUESTION: Does this group agree that GRE encapsulation needs 
*to be supported in MIPv6?

YES

*If the answer is "NO", then using the already defined UDP port 
*and the IP version field to demux IPv4/IPv6 packets as already 
*defined in
*DSMIPv6 is absolutely fine and there is no reason to change it.

Is port number sufficient to disambiguate a RFC 1918 "net 10"?
(10.0.0.0/8). If not we need to answer Yes to the first question, most
likely. Any views?

Regards
Alessio

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 15 May 2007 09:11:14 +0200

Hi Vidya

I think the discussion started with the idea of making the DSMIP tunnel
more open to tunneling *anything*. This could be or have been done
separately from DSMIP, for instance at the time of MIP6 or NEMO. If you
look at it, all these protocols are tunnel set-up and maintenance
protocols, with the HoA as the ID for the tunnel. So why tunnel only
IPv6 in there? 

That was (one of) Hesham's valid point(s) when he started his DS-MIP
draft. So now we have support to tunnel IPv4, and we discriminate with
protocol type. And the issue comes like is that all we'll ever need?
Can't we make that more open for future use? And is this draft the right
time for opening up?

One question was, which future use? 

One traditional use is L2 tunneling; if you want your MR to tunnel
multiple flows treated as multiple VLANs in the mobile network, you
might want to keep the VLANs up to the HA by inserting 802.1Q
information, or the whole or compressed Ethernet packet in the MRHA
tunnel. The L3 alternative (multiple VRFs) is much more complex to
deploy on a MR.

So I do agree with the original point that there will be multiple usages
for that tunnel. At this point, I feel that we are back to a previous
discussion on reverse Routability test: in traditional MIP or NEMO
(without SeND) the MR can not be sure of its CoA, and DS-MIP makes that
worse because of IPv4 roaming. Is DS-MIP the right place to solve a
problem that was already there?
 
I suspect that we have made some clear room for a number of small drafts
that will apply to all MIP, DS-MIP and NEMO, to improve the security of
the system or like in this case make it more open to the future. The new
drafts will have to cope with existing protocols, including IPv6 in the
MIP6 tunnel without GRE which is already a fact of life.

My own suggestion is to be ready to receive these drafts as new WG items
and carry them out swiftly, but not make a dependency for DS MIP on
these discussions, either. DS-MIP has been pretty stable for a while,
and the recent changes that were discussed (like the mapped CoA) were
more on the religious side than fixing practical problems. 

Pascal

>From: Narayanan, Vidya [mailto:[email-masked]]
>Sent: Friday, May 11, 2007 8:38 AM
>To: Hesham Soliman; Sri Gundavelli (sgundave); [email-masked];
[email-masked]
>Subject: RE: [nemo] RE: [Mip6] The use of GRE
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 15 May 2007 13:55:48 +0200

Pascal Thubert (pthubert) wrote:
> Hi Vidya
> 
> I think the discussion started with the idea of making the DSMIP 
> tunnel more open to tunneling *anything*. This could be or have been 
> done separately from DSMIP, for instance at the time of MIP6 or NEMO.
> If you look at it, all these protocols are tunnel set-up and 
> maintenance protocols, with the HoA as the ID for the tunnel. So why 
> tunnel only IPv6 in there?
> 
>  draft. So now we have support to tunnel IPv4, and we discriminate 
> with protocol type. And the issue comes like is that all we'll ever 
> need? Can't we make that more open for future use? And is this draft 
> the right time for opening up?
> 
> One traditional use is L2 tunneling;

IMHO it is not a good idea to tunnel L3 in L2 in L3 and in L2.  This is
an architectural mistake: IPv6-MACheader-IPv4-MACheader.

I think this is what you are proposing with encapsulating L2 tunnelling
in GRE, is it so?

> if you want your MR to tunnel multiple flows treated as multiple 
> VLANs in the mobile network, you might want to keep the VLANs up to 
> the HA by inserting 802.1Q information, or the whole or compressed 
> Ethernet packet in the MRHA tunnel.

I think it is not a good idea to intersperse an L2 header between two
IPv6 base headers.

I think it is not good idea to propagate 802.1q information between MR
and HA.

> The L3 alternative (multiple VRFs) is much more complex to deploy on
>  a MR.

I am not sure what you mean.

What is VRF?

Also, the L3 alternative (using NEMOv6 base spec and not using L2
headers between base IPv6 headers), is implemented widely.   I am not
sure why you say it is much more complex.

> So I do agree with the original point that there will be multiple 
> usages for that tunnel. At this point, I feel that we are back to a 
> previous discussion on reverse Routability test: in traditional MIP 
> or NEMO (without SeND) the MR can not be sure of its CoA,

What do you mean?  Do you mean that NEMOv6+SeND is not enough for
securing MR ownership of its Care-of Address?  And that NEMOv6+GRE
encapsulation (instead of IPv6-in-IPv6) will make sure MR has a safe
Care-of Address?

> and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP the 
> right place to solve a problem that was already there?

Good question.  I agree the security model with DS-MIPv6 and IPv4
Care-of Addresses is different than simple NEMOv6.  But I don't see GRE
a solution here.  Why do you see GRE as a security solution for DS-MIPv6?

If HoA is used for identitying IP tunnels then IPsec SAs can link these
HoAs, because HoA is an IP address.  On the contrary, if GRE key is used
to identify tunnels then GRE key can not be used with IPsec SAs.
Besides, I don't think there exist protocol selectors for GRE headers.

> I suspect that we have made some clear room for a number of small 
> drafts that will apply to all MIP, DS-MIP and NEMO, to improve the 
> security of the system or like in this case make it more open to the 
> future. The new drafts will have to cope with existing protocols, 
> including IPv6 in the MIP6 tunnel without GRE which is already a fact
>  of life.

I agree MIP6 tunnel without GRE is already a fact of life.

But I don't see how GRE improves security of MIP6, DS-MIPv6 or NEMO.

> My own suggestion is to be ready to receive these drafts as new WG 
> items and carry them out swiftly, but not make a dependency for DS 
> MIP on these discussions, either. DS-MIP has been pretty stable for a
>  while, and the recent changes that were discussed (like the mapped 
> CoA) were more on the religious side than fixing practical problems.

Ok, somehow agree.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 16 May 2007 02:07:14 -0700

Hi Yoshi,

Yes, you are right in that GRE does allow any protocol to go over it,
and I was not aware that this use of GRE is common in combination with
Mobile IP. I will take your work for it though.

If people feel that GRE is indeed important for MIPv6 then, I wonder if
it is a good idea to just add a "hook" for GRE support in DSMIPv6 draft.
Would it not be better to add GRE encapsulation on MIPv6 more properly,
and deal with how it is signaled, how GRE key management is done, how
GRE tunneling is used over IPv4 or IPv6 tunneling, and possibly other
issues? 

Maybe it is just me but somehow I feel that DSMIPv6 has already become
too big and a kind of a kitchen-sink draft for a lot of different
things.

Regards
George

-----Original Message-----
From: Yoshi Tsuda (yotsuda) [mailto:[email-masked]] 
Sent: Tuesday, May 15, 2007 5:22 PM
To: Tsirtsis, George; Sri Gundavelli (sgundave); Hesham Soliman;
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Mip6] The use of GRE

Hi George,

> Personally, I am not a big fun of supporting GRE 
> encapsulation for MIPv6. The reason is that in IPv6 we do not 
> have (and must never have) to deal with overlapping address 
> spaces (the main use of GRE tunneling in MIPv4). 

 I'm afraid, you might be missing the main use of GRE
 tunneling in MIPv4.  The main use of GRE tunneling in MIPv4
	- is NOT to deal with overlapping address spaces,
	- but to encapsulate any "Protocol type" of packets.

 In past, when I was implementing various MIPv4 MNs, I was
 told to implement GRE tunneling by many voices of customers
 to encapsulate TCP/IPv4, AppleTalk, or whatever protocol suites
 without worrying about used "Protocol type"s...

Thanks.
-Yoshi (in Cisco)

> Sent: Monday, May 14, 2007 11:04 PM
> To: Sri Gundavelli (sgundave); Hesham Soliman; [email-masked]; 
> [email-masked]
> I have been trying to make sense of this discussion. After 
> re-reading the whole thread I think we may be able to 
> progress if we answer the following question:
> 
> QUESTION: Does this group agree that GRE encapsulation needs 
> to be supported in MIPv6?
> 
> If the answer is "NO", then using the already defined UDP 
> port and the IP version field to demux IPv4/IPv6 packets as 
> already defined in
> 	a) Leave GRE out of DSMIPv6 draft (which uses IP 
> version field for demuxing). People interested in GRE should 
> write up a draft defining how GRE is used in MIPv6. This is 
> likely to result in a GRE specific method of encapsulation 
> over UDP. This is likely to involve reservation of one more 
> UDP port and the definition of a small pseudo-header as 
> encapsulations. This would mean that DSMIPv6 draft is changed 
> to indicate that over the reserved UDP port we add the TLV 
> (or whatever
> structure) which indicates what the next header is i.e., 
> IPv4, IPv6, GRE.
>  
> 
> Personally, I am not a big fun of supporting GRE 
> encapsulation for MIPv6. The reason is that in IPv6 we do not 
> have (and must never have) to deal with overlapping address 
> spaces (the main use of GRE tunneling in MIPv4). 
> 
> Also note that even if we do decide to use the IP version 
> field for demuxing now, there is nothing that prevents GRE 
> encapsulation to be defined later, as indicated by (a) above, 
> assuming that GRE support becomes necessary. Yes, then 
> implementation will have to deal with two way of demuxing 
> similar information but it is not the end of the world and it 
> reduces the overhead (albeit not much) in the typical case.
> 
> I hope this helps.
> Regards
> George
> 
> 
> > This concensus call on issue 93 made me a bit confused 
> about the use 
> > of GRE.
> Problem will be with the NAT/PAT device. It wont create NAT 
> bindings from the UDP header encapped in the GRE header.
> 
> Sri
> 
> 
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 16 May 2007 08:39:42 -0700

> Sent: Wednesday, May 16, 2007 2:07 AM
> To: Yoshi Tsuda (yotsuda); Sri Gundavelli (sgundave); Hesham 
> Soliman; [email-masked]; [email-masked]
> Cc: [email-masked]

Just a clarification. I dont think, the request was for extending DSMIP6
to support GRE. But, rather a request for a 4-byte TLV header that gives
the room for adding new extensions, including GRE header. Again, just as
in 3519.

Regards
Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 16 May 2007 12:08:51 -0500

Some observations about the discussion so far:

1. If the only packet types encapsulated by the UDP header are IPv4/6 then
we do not need the extra 4 byte header.
2. The need for the 4 byte header to spell the encapsulated packet type
arises only if we believe GRE or other types of packets may be encapsulated
in the tunnel between the MN and HA. Yoshi (at least) has indicated that he
has had to implement GRE tunnelling support on the MN. Would help if any
others can respond and clarify if tunnelling GRE over IP at the MN is
normally done.
3. The 4 byte header in every packet is an overhead. Depending on the link
type 4 bytes in every packet can be considered as being wasteful.
4. The need for GRE encapsulation for NEMO is not apparent; I think there
was an explicit statement that GRE is not needed for NEMO.

Recommendation:

The DS-MIP6 I-D has been worked on at length in this WG. Its time to get
this published and implementations tested.

Proceed with the current model where we only have either IPv4/6 packets
being encapsulated between the MN and HA by the UDP header. No additional 4
byte header to be added.

When there is a valid justification and need for supporting encapsulation of
GRE and/or other packet types, we can revise the specification if needed.

Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there is a need
to support GRE encapsulation in that context, the Netlmm I-D may extend the
DS-MIP6 spec and add the 4 byte header.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 May 2007 21:08:18 +0200

> the room for adding new extensions, including GRE header. Again, just as

I really don't think 3519 has that TLV more than as an option.  Probably 
it is there because somebody has insisted very hard to get it there.

But in general I think it makes no sense at all to have TLVs or GRE 
between IP headers, or between TCP and UDP headers or anywhere else 
other than pure and last payload.

It makes no sense to carry layer2 header within IP message.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 May 2007 21:19:07 +0200

> was an explicit statement that GRE is not needed for NEMO.

I agree with this 1-4 list, and I think it summarizes well the points 
discussed so far, thanks.

Another need for GRE that was mentioned is security.  It is not 
technically clear either.

> DS-MIP6 spec and add the 4 byte header.

Raj, I find it extemely annoying the silence around the actual need for 
GRE.  It is a known fact for anyone following WiMax SDO that WiMax needs 
GRE.  It is also a known fact that several people expressing oppinions 
on this list are also expressing opinions on WiMax NWG.

YEt these people are silent when the question "who needs GRE" is raised.

This is very annoying.

I understand very well your neutral Chair position and you summarized 
very well the GRE discussion so far - I appreciate that.

But I think it is time to state clearly that GRE is pushed here _only_ 
because WiMax needs it.  Every other technical reason for GRE is 
completely bogus: security (you didn't mention), NEMO and capacity to 
carry other than IPv4/IPv6 is pure speculative handwaving.

Once we have that statement of interest from WiMax needs about GRE we 
can deal with it accordingly.  Otherwise it looks as if you try to make 
it look as if it were a typical IETF discussion - it isn't.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 16 May 2007 14:52:27 -0500

Hi Alex,

> technically clear either.

I guess I missed the security argument. But as you say, the reasons are not
very clear.

> on this list are also expressing opinions on WiMax NWG.

I am not sure if that is indeed the case. At least I have not perceived it
as such from the current thread.

<chair hat off> Since I also am involved in WiMAX NWG, I can tell you that
this issue of GRE support in DS-MIP6 has never been discussed in that forum.
</chair hat off>

> it look as if it were a typical IETF discussion - it isn't.

IMO, the discussion on this topic/thread was not motivated by who needs GRE.
It was simply closing an issue that was raised and discussed at the Prague
IETF. The argument about GRE arose only as a result of the need for the 4
byte header to indicate the encapsulated packet type.
I believe this was a typical WG discussion. You may be reading much more
into it than what it is.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 16 May 2007 13:53:25 -0700 (PDT)

On Wed, 16 May 2007, Alexandru Petrescu wrote:

>> >  From: Tsirtsis, George [mailto:[email-masked]] Sent: Wednesday, 
>> >  May 16, 2007 2:07 AM
>> >  To: Yoshi Tsuda (yotsuda); Sri Gundavelli (sgundave); Hesham Soliman; 
> I really don't think 3519 has that TLV more than as an option.  Probably it 
> is there because somebody has insisted very hard to get it there.
>
> But in general I think it makes no sense at all to have TLVs or GRE between 
> IP headers, or between TCP and UDP headers or anywhere else other than pure 
> and last payload.
>

Well. it makes sense to me. Gave many reasons that I dont
want to repeat here. If you judge things based on your
preset notion of how requirements are arriving, its hard
for you to get convinced.

BTW, there was no comment on any justification based on
the security argument. Not sure, how you ended up with
that assumption. Also, this requirement is not comming
from WiMAX. But, I dont have to prove it to you. If this
requirement is indeed comming from WiMax, let it be so.
If there is a need, so is it. This is a technical discussion.
Judge it based on the merit.

Any case, we disagree on this. I gave the reasons why
we should add a simple 4-byte TLV header. If the WG is
convinced, let it add that. Otherwise, we need to later
allocate a special port just for GRE payload.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 May 2007 23:20:22 +0200

Sri Gundavelli wrote:
>>>> -----Original Message----- From: Tsirtsis, George 
>>>> [mailto:[email-masked]] Sent:
>>> Wednesday, >  May 16, 2007 2:07 AM
>>> Soliman; >  [email-masked]; [email-masked]
>>>> Cc: [email-masked] Subject: RE: [Mip6] The use of GRE
>>>>> Hi Yoshi, Yes, you are right in that GRE does allow any 
>>>>> protocol to go
>>> over it,
>>>> and I was not aware that this use of GRE is common in 
>>>> combination
>>> with
>>>>> If people feel that GRE is indeed important for MIPv6 then, I
>>>>> 
>>>>> 
>>> wonder if
>>>> it is a good idea to just add a "hook" for GRE support in 
>>>> DSMIPv6 draft. Would it not be better to add GRE encapsulation 
>>>> on MIPv6 more
>>> properly,
>>>> and deal with how it is signaled, how GRE key management is 
>>>> done, how GRE tunneling is used over IPv4 or IPv6 tunneling, 
>>>> and possibly other issues? > >  Maybe it is just me but somehow
>>>>  I feel that DSMIPv6
>>> has already become
>>>> too big and a kind of a kitchen-sink draft for a lot of 
>>>> different things.
>>>> 
>>> 
>>> 
>>> Just a clarification. I dont think, the request was for extending
>>>  DSMIP6 to support GRE. But, rather a request for a 4-byte TLV 
>>> header that gives the room for adding new extensions, including 
>>> GRE header. Again, just as in 3519.
>> 
>> I really don't think 3519 has that TLV more than as an option. 
>> Probably it is there because somebody has insisted very hard to get
>>  it there.
>> 
>>  between IP headers, or between TCP and UDP headers or anywhere 
>> else other than pure and last payload.
>> 
> 
> Well. it makes sense to me. Gave many reasons that I dont want to 
> repeat here. If you judge things based on your preset notion of how 
> requirements are arriving, its hard for you to get convinced.
> 
> BTW, there was no comment on any justification based on the security 
> argument. Not sure, how you ended up with that assumption.

I think this is what I read in yestarday Pascal's comment needing GRE
for security reasons. Pascal said at
http://www1.ietf.org/mail-archive/web/mip6/current/msg06157.html:
> usages for that [GRE, my note] tunnel. At this point, I feel that we
>  are back to a previous discussion on reverse Routability test: in 
> traditional MIP or NEMO (without SeND) the MR can not be sure of its
>  CoA, and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP
>  the right place to solve a problem that was already there?

Sri said:
> Also, this requirement is not comming from WiMAX. But, I dont have to
> prove it to you. If this requirement is indeed comming from WiMax,
> let it be so. If there is a need, so is it. This is a technical
> discussion. Judge it based on the merit.

Right...

The technical merit of this GRE discussion is utterly senseless, sorry 
for exaggerating the qualifier.

> Any case, we disagree on this. I gave the reasons why we should add a
>  simple 4-byte TLV header. If the WG is convinced, let it add that. 
> Otherwise, we need to later allocate a special port just for GRE 
> payload.

Do you agree that DS-MIPv6, MIP6 and NEMO can work ok _without_ that 
TLV?  Do you agree MIP4 can work ok without that TLV?

Alex

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 16 May 2007 14:33:59 -0700

Hello Raj,

We might actually end up with option 2. I see three reserved 
UDP ports with DS-MIPv6 already.

1. One UDP port indicating IPv4/IPv6. You parse the IP version
   field to figure out whether it is IPv4 or IPv6.
2. One UDP port for ESP encapsulation. This happens when you 
   protect DS-MIPv6 traffic with ESP and use UDP encapsulation 
   for NAT traversal. The packet format would be
     IPv4 hdr (src=MN-IPv4-CoA, dst=HA-IPv4)
     UDP hdr
     ESP hdr
     IPv6 (src=MN-IPv6-HoA, dst=CN)
     Payload 
3. One reserved UDP port for GRE encapsulation in DS-MIPv6.

So this is almost option 2. :) Option 2 was one reserved port
per protocol that follows the UDP header.

Vijay

> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2007 10:09 AM
> To: ext Tsirtsis, George; Sri Gundavelli; Hesham Soliman; 
> Subject: Re: [Mip6] The use of GRE
> 
> 
> re-reading
> port and the

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 May 2007 23:35:19 +0200

Basavaraj Patil wrote:
> Hi Alex,
> 
> 
> On 5/16/07 2:19 PM, "ext Alexandru Petrescu" 
> <[email-masked]> wrote:
> 
>> Basavaraj Patil wrote:
>>> 1. If the only packet types encapsulated by the UDP header are 
>>> IPv4/6 then we do not need the extra 4 byte header. 2. The need 
>>> for the 4 byte header to spell the encapsulated packet type 
>>> arises only if we believe GRE or other types of packets may be 
>>> encapsulated in the tunnel between the MN and HA. Yoshi (at 
>>> least) has indicated that he has had to implement GRE tunnelling 
>>> support on the MN. Would help if any others can respond and 
>>> clarify if tunnelling GRE over IP at the MN is normally done. 3. 
>>> The 4 byte header in every packet is an overhead. Depending on 
>>> the link type 4 bytes in every packet can be considered as being 
>>> wasteful. 4. The need for GRE encapsulation for NEMO is not 
>>> apparent; I think there was an explicit statement that GRE is not
>>>  needed for NEMO.
>> I agree with this 1-4 list, and I think it summarizes well the 
>> points discussed so far, thanks.
>> 
> I guess I missed the security argument. But as you say, the reasons 
> are not very clear.

Sorry, I think the security argument was made in a mail by Pascal yesterday
http://www1.ietf.org/mail-archive/web/mip6/current/msg06157.html

>> Raj, I find it extemely annoying the silence around the actual need
>>  for GRE.  It is a known fact for anyone following WiMax SDO that 
>> WiMax needs GRE.  It is also a known fact that several people 
>> expressing oppinions on this list are also expressing opinions on 
>> WiMax NWG.
> 
> I am not sure if that is indeed the case. At least I have not 
> perceived it as such from the current thread.

Right.

Let me say differently: does WiMax need GRE in netlmm-PMIPv6 protocol?

Is WiMax ok if netlmm-PMIPv6 protocol uses IPv6-in-IPv6 encapsulation as
of rfc2473 "Generic Packet Tunnling in IPv6 Specification" instead of
GRE as of rfc2784 "Generic Routing Encapsulation"?

> <chair hat off> Since I also am involved in WiMAX NWG, I can tell you
>  that this issue of GRE support in DS-MIP6 has never been discussed
> in that forum. </chair hat off>

Ok.  Did WiMax discuss at all GRE?  Did WiMax already include GRE in
some of its specs?

>> I understand very well your neutral Chair position and you 
>> summarized very well the GRE discussion so far - I appreciate that.
>> 
>> 
>> 
>> But I think it is time to state clearly that GRE is pushed here 
>> _only_ because WiMax needs it.  Every other technical reason for 
>> GRE is completely bogus: security (you didn't mention), NEMO and 
>> capacity to carry other than IPv4/IPv6 is pure speculative 
>> handwaving.
>> 
>> Once we have that statement of interest from WiMax needs about GRE 
>> we can deal with it accordingly.  Otherwise it looks as if you try 
>> to make it look as if it were a typical IETF discussion - it isn't.
>> 
>> 
> 
> IMO, the discussion on this topic/thread was not motivated by who 
> needs GRE. It was simply closing an issue that was raised and 
> discussed at the Prague IETF. The argument about GRE arose only as a 
> result of the need for the 4 byte header to indicate the encapsulated
>  packet type. I believe this was a typical WG discussion. You may be 
> reading much more into it than what it is.

Sorry... I'm probably over-reacting on this.

To come back to your recommendation, more reasonably, which was:
> Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there is
>  a need to support GRE encapsulation in that context, the Netlmm I-D 
> may extend the DS-MIP6 spec and add the 4 byte header.

I find it clear in your recommendation above that you consider NETLMM to
need GRE.  And I am not sure how to take this recommendation.

I ask you: why do you consider NETLMM to need GRE?  It is surprising to
consider NETLMM to need GRE because NETLMM is based on MIP6 and MIP6
doesn't need nor use GRE.

And then: do you make this recommendation as a MIP6 WG Chair to MIP6 WG
members?    Do you make this recommendation as a member of NETLMM WG?
If latter I don't agree with your recommendation (as another NETLMM WG
member).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 May 2007 23:47:09 +0200

> 3. One reserved UDP port for GRE encapsulation in DS-MIPv6.

Vijay, but _why_ reserving an UDP port for GRE encapsulation?

Since Sri puts the accent so much on the technical merit, what is the 
technical merit of using GRE (compared to existing encapsulation methods)?

Why developing two different ways for doing the same thing?

Alex

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 16 May 2007 15:09:13 -0700

Alex, 

"Why GRE?" is a separate topic. If someone wants to use GRE
encapsulation to identify flows in DS-MIPv6, we would need to
reserve another UDP port.

Vijay

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2007 2:47 PM
> To: Vijay Devarapalli
> Cc: Basavaraj Patil; ext Tsirtsis, George; Sri Gundavelli; 
> Hesham Soliman; [email-masked]; [email-masked]
> Subject: Re: [nemo] RE: [Mip6] The use of GRE
> 
> Vijay Devarapalli wrote:
> > Hello Raj,
> >

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 17 May 2007 10:17:28 +0900

Hi Raj,

On 2007/05/17, at 2:08, Basavaraj Patil wrote:

> IPv4/6 then
> encapsulated

It seems that many people want to support GRE on DSMIP.
I am fine with either 4byte header or UDP port for GRE.
I personally prefer Vijay's suggestion (UDP port for GRE).

I understand it is important for DSMIP to leave space for future  
extensions.
But this additional feature can easily be re-defined in different  
spec as DSMIP extension.
We don't need to specify it in DSMIP now.
The separate doc can overwrite the DSMIP spec if needed.

regards,
ryuji

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 May 2007 00:12:17 -0500

Hi Ryuji,

If we agree that a new UDP port for GRE, beside the one for IPv4/IPv6,
is needed, then why do not we use a new UDP port to indicate the
presence of the TLV which then can be used to indicate the next header
for many protocols including GRE and ESP. This way we save one UDP port
if we want to support ESP as per Vijay's proposal. 

Regards,
Ahmad

> From: RYUJI WAKIKAWA [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2007 6:17 PM
> To: Basavaraj Patil
> Cc: [email-masked]; [email-masked]; Sri Gundavelli
> Subject: Re: [nemo] Re: [Mip6] The use of GRE
> 
> Hi Raj,
> 
> 
> 
> > 2. The need for the 4 byte header to spell the encapsulated packet 
> > type arises only if we believe GRE or other types of packets may be 
> least) has 
> > indicated that he has had to implement GRE tunnelling 
> support on the 
> > MN. Would help if any others can respond and clarify if 
> tunnelling GRE 
> > over IP at the MN is normally done.
> > 3. The 4 byte header in every packet is an overhead. 
> Depending on the 
> > link type 4 bytes in every packet can be considered as 
> being wasteful.
> > 4. The need for GRE encapsulation for NEMO is not apparent; I think 
> > there was an explicit statement that GRE is not needed for NEMO.
> >
> > Recommendation:
> >
> > The DS-MIP6 I-D has been worked on at length in this WG. 
> Its time to 
> > get this published and implementations tested.
> >
> > Proceed with the current model where we only have either IPv4/6 
> > packets being encapsulated between the MN and HA by the UDP 
> header. No 
> > additional 4 byte header to be added.
> >
> > When there is a valid justification and need for supporting 
> > encapsulation of GRE and/or other packet types, we can revise the 
> > specification if needed.
> >
> I understand it is important for DSMIP to leave space for 
> future extensions.
> But this additional feature can easily be re-defined in 
> different spec as DSMIP extension.
> >> If the answer is "NO", then using the already defined UDP port and 
> >> the IP version field to demux IPv4/IPv6 packets as already 
> defined in
> >> a) Leave GRE out of DSMIPv6 draft (which uses IP version field for 
> >> demuxing). People interested in GRE should write up a 
> draft defining 
> >> method of encapsulation over UDP. This is likely to involve 
> >> reservation of one more UDP port and the definition of a small 
> >> pseudo-header as proposed by Sri and others.
> encapsulations. 
> >> This would mean that DSMIPv6 draft is changed to indicate 
> that over 
> >> the reserved UDP port we add the TLV (or whatever
> IPv4, IPv6, 
> >> to deal with overlapping address spaces (the main use of GRE 
> >> tunneling in MIPv4).
> >>
> field for 
> >> becomes necessary. Yes, then implementation will have to deal with 
> >> two way of demuxing similar information but it is not the 
> end of the 
> >> world and it reduces the overhead (albeit not much) in the typical 
> >> case.
> >>
> >> I hope this helps.
> >> Regards
> >> George
> >>
> >>
> >>> Why do we need to add another layer to qualifiers instead 
> of using 
> >>> the existing allocated numbers?
> >>>

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 17 May 2007 10:47:14 +0200

Folks,

> if we want to support ESP as per Vijay's proposal. 

At least I am very far from agreeing on one additional assigned UDP
port.  The number of unassigned UDP port in the range that can be
assigned by IANA (0 - 1023) is now down to 281, by my count, so this
should be considered a scarce resource.

I'm not even sure whether it makes sense to ask for a new port for DS-MIPv6
rather than multiplex over for instance the MIPv4 port, but I think we can
at least ask the question.  But asking for 2 ports, to carry 2 different
kinds of DS-MIPv6 payloads, seems just wrong.

	Henrik

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 17 May 2007 22:25:05 +0900

Hi

This is fine. I just want to avoid 4bytes in every packets over  
wireless.
However, I noticed that if this GRE/ESP support is only for netlmm,
it isn't big problem. The path between MAG and LMA is not wireless.

I need to see what tunnel (GRE, ESP) is supported for which protocol  
(MIP6, NEMO, PMIP?) in DSMIP.

ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 17 May 2007 22:28:45 +0900

Hi Henrik,

I have to agree with you, but the additional 4 bytes in air
are also consumed scarce resource, i.e wireless...

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 May 2007 18:39:00 +0200

> reserve another UDP port.

I think we rather should recommend to use existing application 
standardized tools to identify flows in DS-MIP6 instead of rushing to 
reserve new UDP port numbers.

I think that if there is no need of GRE there is no need of GRE port 
number either.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 May 2007 18:41:06 +0200

> if we want to support ESP as per Vijay's proposal.

Another possibility (no GRE, no new TLV. no new port number) is to 
extend existing Mobile IPv4 message types to contain whatever data that 
TLV or GRE needs.

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 17 May 2007 18:55:56 +0200

Hi Ryuji,

> are also consumed scarce resource, i.e wireless...

Humm.  What is the bandwidth of your expected wireless link,
how often do you send BUs, and how much other traffic?

With very simple assumptions, like a voice stream and a BU
every 4 minutes, you get:

  Voice: 16kbit/s * 4 min = 16*1024/8*4*60 bytes = 491520 bytes
  4 bytes overhead per BU/BA message = 8 bytes

  Extra overhead due to 4-byte header: 0.0016%

I think we can ignore this.

	Henrik

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 May 2007 13:06:41 -0500

> are also 
> > consumed scarce resource, i.e wireless...
> 

[Ahmad]
Yep. I like this simple yet valuable analysis.:)
> >>> If we agree that a new UDP port for GRE, beside the one for IPv4/ 
> >>> IPv6, is needed, then why do not we use a new UDP port to 
> indicate 
> >>> the presence of the TLV which then can be used to 
> indicate the next 
> >>> header for many protocols including GRE and ESP. This way we save 
> >>> one UDP port if we want to support ESP as per Vijay's proposal.
> >>
> >> rather than multiplex over for instance the MIPv4 port, 
> but I think 
> >> we can at least ask the question.  But asking for 2 ports, 
> to carry 2 
> >> different kinds of DS-MIPv6 payloads, seems just wrong.
> >>
> >>
> >> 	Henrik
> > 
> > 
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 17 May 2007 18:02:14 -0700

Isn't the 4 byte overhead on every data packet in the voice
stream? Not just the BU/BAck.

I must be missing something.

Vijay 

> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Thursday, May 17, 2007 9:56 AM
> To: RYUJI WAKIKAWA
> Cc: [email-masked]; [email-masked]; Sri Gundavelli; Basavaraj 
> Patil; Ahmad Muhanna
> >>> IPv6,
> >>> for many protocols including GRE and ESP. This way we 
> save one UDP  
> >>> port
> >> I'm not even sure whether it makes sense to ask for a new 
> port for  
> >> DS-MIPv6
> >> we can

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 18 May 2007 11:05:16 +1000

>   4 bytes overhead per BU/BA message = 8 bytes

=> That's not accurate, the 4-byte o/h is in every packet, it's not just the
BU/BA.

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 18 May 2007 10:35:02 +0200

Hi Alex:

I'm surprised you're surprised. That's what L2TP has always been. 
You might want to read about softwire, and in particular the new
developments in:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2t
pv2-03.txt 

Pascal

>Sent: Tuesday, May 15, 2007 1:56 PM
>To: Pascal Thubert (pthubert)
>Cc: Narayanan, Vidya; Hesham Soliman; Sri Gundavelli (sgundave);
>Subject: Re: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was:
[nemo] RE: [Mip6] The use of
>GRE)

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 May 2007 10:40:46 +0200

Hi Vijay,

> stream? Not just the BU/BAck.

Yes, of course.  Quite right.  Wrong time of day for me, I guess.

So the correct data depends on packet size, but not on BU interval.
For a 1280 total packet size, this means the overhead is 4/1276,
or 0.3%.

For a 16kbps voice stream, the payload size is 40 bytes, the IPv4
header is 20bytes, the first udp header 8, the IPv6 header 40, the
second udp header is 8, and the rtp header is 12 bytes.  Altogether
88 bytes header and 40 bytes payload, which gives the added overhead
of 4 bytes and 4/128 = 3.1%.

This is more serious, but also shows that we should probably consider
whether we can reduce/compress the whole set of headers, rather than
focus on the demultiplexing-enabling 4 bytes.  It might even be the
case that having the demultiplexing-enabling 4 bytes gives us the
freedom we need to define alternative tunnelling with less overhead.

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 18 May 2007 10:41:25 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2t

You're right, L2TP is to tunnel L2 packets.

If GRE does the same thing as L2TP then why using GRE and not L2TP?

Alex

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 18 May 2007 11:57:23 -0700

Hi Henrik, 

> Sent: Friday, May 18, 2007 1:41 AM
> To: Vijay Devarapalli
> Cc: RYUJI WAKIKAWA; [email-masked]; [email-masked]; Sri 
> Gundavelli; Basavaraj Patil; Ahmad Muhanna

I would divide by 40, since we are calculating the overhead compared 
to the actual payload, 4/40 = 10%.

Vijay

> >> >>> presence of the TLV which then can be used to indicate 
> the next  
> >> >>> header

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 18 May 2007 20:26:30 -0500

Hi Vijay,

> > > Isn't the 4 byte overhead on every data packet in the 
> voice stream? 
> > > Not just the BU/BAck.
> > 
> > For a 1280 total packet size, this means the overhead is 4/1276, or 
> > 0.3%.
> > 
> I would divide by 40, since we are calculating the overhead 
> compared to the actual payload, 4/40 = 10%.

[Ahmad]
Dividing by 40, IMO, is called a misleading and statically biased
methodology. The wireless link does not know nor care what is payload
and what is not. The wireless link probably cares that a packet of a
length of 124 is now 128 after adding the TLV. I thought what Henrik was
trying to quantify is the impact on the wireless link bandwidth due to
the added 4 bytes TLV.

On the other hand, let me say that this is almost the worst case
scenario, however, for example if FTP in the picture and let us assume a
packet length of 1300 bytes, then the impact is about 0.3%.

One more thing, If we think of compressing this TLV, we probably end up
with one byte!

My 1.5 cents. :)

> > >> Cc: [email-masked]; [email-masked]; Sri Gundavelli; 
> Basavaraj Patil; 
> > >> Ahmad Muhanna
> > >> > I have to agree with you, but the additional 4 bytes 
> in air are 
> > >> > also consumed scarce resource, i.e wireless...
> > >> 
> > >> Humm.  What is the bandwidth of your expected wireless link, how 
> > >> often do you send BUs, and how much other traffic?
> > >> 
> > >> With very simple assumptions, like a voice stream and a 
> BU every 4 
> > >> minutes, you get:
> > >> 
> > >> >> at least ask the question.  But asking for 2 ports, 
> to carry 2

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 19 May 2007 08:09:59 +0200

Hi Vijay,

on 2007-05-18 20:57 Vijay Devarapalli said the following:
...
> to the actual payload, 4/40 = 10%.

No.  That sounds as if the packet size increases by 10%, which it
doesn't.  As Ahmad says, that's misleading.  Then you might as well
pick a 1-byte payload, and claim the figure 400%.  That would also
be misleading.  Both figures are technically correct under certain
premises, but not helpful in this context.

The figures 3.1% and 0.3% are the increased bandwidth consumption of
the link in question, for these traffic types, if we do nothing about
compression or header reduction.

And regarding that, it would be interesting if you would also comment
on the last part of my message (left in place below).

	Henrik

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 21 May 2007 21:43:31 -0700

Hi Ahmad,
 
> trying to quantify is the impact on the wireless link bandwidth due to

I was looking at how much overhead we are adding in addition
to the existing overhead. Not in comparison to the existing
overhead. I hope you see the difference. 

> packet length of 1300 bytes, then the impact is about 0.3%.

Of course. For large packets, this is not an issue.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 21 May 2007 21:50:12 -0700

Hi Henrik,
 
> >> freedom we need to define alternative tunnelling with less overhead.

Yes, this is a good idea. I have come across an IPR'ed solution
(not mine) in this space. It proposes to compress the inner 
headers when you use IP-in-IP tunneling with Mobile IP (both v4
and v6). I don't have a reference to it now.

Vijay

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 24 May 2007 11:20:13 +0900

Hi Henrik,

sorry for my silence.

Thanks for good analysis.
In wireless, we should also consider the number of mobile nodes  
attached to the same access point.
I just prefer decreasing the header parts from the packet as much as  
possible.
As you show the example of VoIP, the header part is already two times  
bigger than the payload.

BTW, I agree that some kind of header compression may be worth to  
apply here.

regards,
ryuji