Subject: [nemo] DS-MIP6: Consensus call to close issue 93

From: Basavaraj Patil <[email-masked]>
Date: Tue, 08 May 2007 16:16:24 -0500

Hello,

The DS-MIP6 I-D <draft-ietf-mip6-nemo-v4traversal-04.txt> still has
issue 93 open. This was discussed at IETF68. Vijay presented 4 options
to solve the issue. These are captured in:

https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf

We need to make a decision on this issue and move forward with the
I-D. At the meeting itself, I got the sense that option 3 was the one
that had the least impact and easy to implement.

Please consider this email as a consensus call for issue 93. The
problem and choices are as follows (based on Vijay's slides):

Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The
encapculations are either:
 - IPv6-in-UDP-over-IPv4
 - IPv4-in-UDP-over-IPv4
There is a need (or I guess desirable) to indicate the type of
protocol being encapsulated in the UDP header.

Choices are:
1. Parse the protocol header following the UDP header
2. Reserve a UDP port for each protocol header (i.e one UDP port for
   IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.)
3. One reserved UDP port and a DS-MIP6 "tunnel type message"
4. Encapsulated protocol header type is indicated in the BU message

Pros and cons of these choices are in the slides that were presented
at IETF68 (see URL above).

Please provide your opinions and comments by May 15th, 07 on the MIP6
mailing list.

-Raj

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 8 May 2007 18:20:33 -0700

Hi,

My preference is for option 4. I know many preferred option 
3, but it adds a 4 byte per-packet overhead for each tunneled
data packet. I wish we can avoid that.

Vijay 

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Tuesday, May 08, 2007 2:16 PM
> To: Mobile IPv6 Mailing List; [email-masked]
> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93
> 
> 
> Hello,
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 9 May 2007 12:03:21 +1000

Hi Raj, 

At the meeting Sri (the author of the issue) and Kent said they didn't know
that a UDP port was already reserved. Once we cleared that, the rationale
for the issue was no longer applicable. I believe Sri said he wanted some
time to be sure before the issue is rejected. 

 > 1. Parse the protocol header following the UDP header

=> This should be "parse the version field after the UDP header". This is
what's already in the draft and it works fine today with any UDP
encapsulation. 

 >    IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.)

=> This isn't needed. 

 > 3. One reserved UDP port and a DS-MIP6 "tunnel type message"

=> This is what the issue suggested but the additional 4 bytes are
redundant. 

 > 4. Encapsulated protocol header type is indicated in the BU message

=> Again, not needed IMO.

I think option 1 is the right option. There is no reason given for a change.

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 8 May 2007 19:16:54 -0700

Hi Hesham:

Sure. I agree that the application can switch based
on the IP version field. True. I'm ok either way. You
can keep it the way you have it now or use an approach
below. But, just one comment.

I prefere 3519 style of thin wrapper. Reason: If we
need to add Keepalive messages tomorrow, a separate
subtype can be defined for the keepalive messages and
so we can extend this. Off course, I do realize, you guys
wanted to use BU/BA as the keepalive message and that
processing in my opinion is bit expensive compared to a
simple keepalive message and that too with the option
of skipping keepalive message when any data traffic
is seen. But, if you think this 4-byte wrapper is a waste
for the keepalive extension that never be defined in
future, I'm ok.

Sri

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Tuesday, May 08, 2007 7:03 PM
> To: 'Basavaraj Patil'; 'Mobile IPv6 Mailing List'; [email-masked]
> Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93
> 
> Hi Raj, 
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 9 May 2007 12:27:20 +1000

Hi Sri,  

 > for the keepalive extension that never be defined in

=> I agree with you on the need for lighter weight keep-alive. I raised an
issue
a long time ago, and rejected it :), because there wasn't enough interest to
justify its addition. 
However, I don't think it's related to this discussion because if we wanted
a keep alive we 
could simply define a new option in the DO header or just encapsulate a
"ping". 
So I don't see the correlation with this issue as the keepalive can always
be sent in a ping using either IPv4 or IPv6 and the same parsing rules would
apply. 

Hesham

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 10 May 2007 02:07:09 -0500

Hi Vijay,

In case that we choose option 4 for the sake of saving the 4 bytes, do
not we, at the same time, limit the option of carrying more than one
type of traffic for the same session? I believe we can negotiate only
one type in BU/BA. Right?

If that is the case, would you consider option 3 again since it fits
naturally in the IP packet processing without the need to peak into the
encapsulated header to identify the traffic type.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, May 08, 2007 8:21 PM
> To: Basavaraj Patil; Mobile IPv6 Mailing List; [email-masked]
> Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93
> 
> Hi,
> 
> > 1. Parse the protocol header following the UDP header 2. 
> Reserve a UDP 
> > port for each protocol header (i.e one UDP port for

---

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

Hi Vijay,

In your slide, you said "If DS-MIPv6 is not implemented in the  
kernel, then it is still an issue"
for the option-1.

What kind of problem is there?
I believer an userland program can parse the headers
and process the received packets accordingly.

regards
ryuji

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 10 May 2007 00:20:42 -0700

Hi Ryuji:

All protocol packets have payload qualifiers.
Looking at the payload to determine the packet type,
I'm not sure that is the followed convention. The protocol
type in the IP header, or the next option type in
the IPv6 headers, the protocol type in gre header,
or the 3519 Data Message, all follow this style of
containment. We can certainly switch by looking at
the 1st byte of the IP packet, but that limits the payload
to IP. We cannot carry GRE header over UDP tomorrow,
or we cant define a separate control message such as
a keepalive message. Why not use a simple type header
and provide the room for carrying new payloads ?

This may not address your specific comment on the
user proc parsing of the packet. But, my comment
is on the need for a TLV header.

Sri

> From: RYUJI WAKIKAWA [mailto:[email-masked]] 
> Sent: Thursday, May 10, 2007 12:12 AM
> To: Vijay Devarapalli
> Cc: [email-masked]; Mobile IPv6 Mailing List
> Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to 
> close issue 93
> 
> Hi Vijay,
>

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 10 May 2007 18:37:25 +0900

Hi Sri,

The problem is not yet in DSMIP, because DSMIP only supports IPv4 and  
IPv6 packets in UDP.
As Hesham said, the receiver can simply check the followed header  
(IP) and can determine whether IPv4 or IPv6.

I am fine with 4 bytes if there is strong reason for that,
however I want to see what kind of additional payloads is considered  
in the future.
In addition, can this 4 bytes mandate only for non IP packets  
followed by UDP header?
If the default is either IPv4 or IPv6, it isn't much big problem for  
implementations.

ryuji

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 11 May 2007 00:25:24 +1000

> to IP. We cannot carry GRE header over UDP tomorrow,

=> Why do we want GRE in MIP6? Are we going to tunnel GRE packets to hosts?
IPv6 in general doesn't need GRE, we sure don't have any overlapping address
problems...

You might be thinking about PMIP here, but you can extend things
specifically for that purpose quite easily. The base standard certainly
shouldn't be compromised for PMIP.

 > a keepalive message. 

=> I thought I answered that point in the last email. 

Hesham

Why not use a simple type header

 > > >> The DS-MIP6 I-D 
 > <draft-ietf-mip6-nemo-v4traversal-04.txt> still has

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Thu, 10 May 2007 11:52:11 -0700

Hi Raj.

I vote for #3.  This method is the most flexible.  It allows the
inclusion of GRE support, which is used to segregate the IPv4 sessions
within a tunnel.  This feature is valuable to PMIPv6, which is dependant
on DSMIP6 for IPv4 support.  Other use case may also arise (maybe NEMO?)
in the future. IMHO, it's better to provide an extensible framework.

Kent 

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2007 2:16 PM
To: Mobile IPv6 Mailing List; [email-masked]
Subject: [Mip6] DS-MIP6: Consensus call to close issue 93

Hello,

to solve the issue.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 10 May 2007 14:00:36 -0500

Hi Hesham,
Please see comment inline.

Regards,
Ahmad

>  > Looking at the payload to determine the packet type,  > 
> I'm not sure that is the followed convention. The protocol  > 
> type in the IP header, or the next option type in  > the IPv6 
> headers, the protocol type in gre header,  > or the 3519 Data 
> Message, all follow this style of  > containment. We can 
> certainly switch by looking at  > the 1st byte of the IP 
> packet, but that limits the payload  > to IP. We cannot carry 
> GRE header over UDP tomorrow,
> 
> IPv6 in general doesn't need GRE, we sure don't have any 
> overlapping address problems...
> 
> You might be thinking about PMIP here, but you can extend 
> things specifically for that purpose quite easily. The base 
> standard certainly shouldn't be compromised for PMIP.

[Ahmad]
Ok, But I believe it is more efficient if we choose an option (e.g. No.
3) which is flexible enough to address the current and possible
(in-progress) future needs. 

> 
>  > or we cant define a separate control message such as  > a 
> keepalive message. 
>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 10 May 2007 15:18:09 -0500

Hesham,

> what's already in the draft and it works fine today with any UDP

Agree. So this option would impy: Do nothing.

>>    IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.)

Okay. 

> => This is what the issue suggested but the additional 4 bytes are

So are you okay with using the tunnel type message as has been done in
RFC3519? Not sure what you are implying by saying that the 4 bytes are
redundant in this context.

> I think option 1 is the right option. There is no reason given for a change.

Sure... If the encapsulated packets are only IPv4 or IPv6, you could parse
the version field and figure out the encapsulated packet type. And as you
have said on the list in another email, is there a need for encapsulating
any other type of packets between the MN and HA in UDP? I think this is an
unknown. GRE has been mentioned, but I agree that it is not generally
between an MN and HA. I don't know if you have thought about this option
from the NEMO perspective as well. After all this I-D is intended to address
hosts and mobile routers. And the other thing is if you want to have some
flexibility by introducing the 4 byte header to explicitly indicate the
encapsulated packet type (akin to RFC3519)

Some explicit reasons for why in the case of MIP6/NEMO would we want the 4
byte header to indicate the encapsulated packet type would be good.

Reasons I have heard so far:
1. PMIP6 relies on DS-MIP6 for IPv4 support and hence encapsulation of
packets other than IPv4/6 (eg. GRE) should be possible in which case the
header would be useful
2. Flexibility for future use
3. Reuse 3519 (don't know if this was mentioned)

It would be good to hear from the NEMO folks as well on this issue as we may
be overly focused on just MIP6 MNs.

-Raj

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 10 May 2007 13:30:31 -0700

Hi Hesham,

> IPv6 in general doesn't need GRE, we sure don't have any 

Agree, may not be useful for a pure MIP6 node, as the mode
is in CCOA mode. But, if you enable NEMO, we need more
flexibility on the marking of the MNP flows that go in the
tunnel. 

> shouldn't be compromised for PMIP.

Sure. That's one use-case. PMIP leverages DSMIP6 and leaving
a simple TLV wrapper will help in extensibility. I dont think
it will compromise the base protocol, its just a simple wrapper,
conventionally in all protocols, the prev header identifies the
payload that follows. 

I agree from the perspective of the 3775, it may not be useful,
but from 3963 or from PMIP6 perspective, it will be useful. 
You guys are doing this now, why not provide the hook as well.

> => I thought I answered that point in the last email. 

Sure. That's one way of building keepalives. 

>  > > >> issue 93 open. This was discussed at IETF68. Vijay 
> presented 4  
>  > > >> options

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 10 May 2007 13:34:36 -0700

Hi Ryuji,

> Sent: Thursday, May 10, 2007 2:37 AM
> To: Sri Gundavelli
> Cc: [email-masked]; 'Mobile IPv6 Mailing List'; 'Vijay Devarapalli'

Its not just about the streams. We need GRE tunnel header for
various reasons, when ever there are multiple mobile node or LFN
streams, the GRE header for its key carrying capability etc. will
be useful, its also useful for PMIP6. So, its a good idea to
do the right thing of putting a tiny header as all protocols do.

> however I want to see what kind of additional payloads is considered  

Ok. Reasons are beyond the MIP6 node's usage, its for PMIP6 and NEMO.
Will be useful.

Sri

---

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

> flexibility on the marking of the MNP flows that go in the

=> Could you elaborate on the nemo aspect you mention above? I don't
understand why nemo is helped by this?

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 10 May 2007 20:42:42 -0700

Hi Hesham: 

> Sent: Thursday, May 10, 2007 7:28 PM
> To: 'Sri Gundavelli'
> Cc: [email-masked]; 'Mobile IPv6 Mailing List'
> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to 
> close issue 93
> 
> 
> 

We have some use cases where we use the GRE key to tag
certain MNP flows and the tunnel peers use these keys as
a form of a selector for differential treatment. Its a 
color code. The seq number and key fields in the GRE header
are used. So support for carrying the GRE header over UDP
will be possible with the TLV header.

Thanks
Sri

>  > >  > > >> I-D. At the meeting itself, I got the sense that 
> option 3 
>  > >  > > was the one
>  > >  > > >> Pros and cons of these choices are in the slides 
> that were 
>  > >  > > presented
>  > >  > > >> Please provide your opinions and comments by May 
> 15th, 07 
>  > >  > > on the MIP6
>  > >  > > >> mailing list.
>  > >  > > >>
>  > >  > > >> -Raj
>  > >  > > >>
>  > >  > > >>

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 11 May 2007 13:03:32 +0900

Hi Sri,

OK, if WG agree to support other payload (GRE) in UDP encapsulation,
we need to have some bits indicating the header type after the UDP  
header.

However, this consensus call is hard to make, because the current  
DSMIP only
supports IPv4/IPv6 tunnel and not GRE.
In the current DSMIP spec, it is obvious that we need nothing here.
If GRE is considered, we need to pick one from choices 2-4.

Is this consensus call whether we support additional tunnel in UDP? :-p

regards,
ryuji

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 10 May 2007 21:08:04 -0700

Hi Ryuji:

Ok. Fair enough. Then I'd vote for Option#3.
Having a thin header or a prev header identifying
the  next header is the followed convention. So,
TLV format gives me that and  I'd like to stick with
that approach. I vote for option #3.

Sri 

> Sent: Thursday, May 10, 2007 9:04 PM
> To: Sri Gundavelli

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 10 May 2007 23:14:14 -0500

Hi Raj,

I hinted in several emails to option #3. 
However, since the consensus call requires clear answers, I would like
to vote for option # 3.

Regards,
Ahmad

> Sent: Tuesday, May 08, 2007 4:16 PM
> The DS-MIP6 I-D <draft-ietf-mip6-nemo-v4traversal-04.txt> 
> still has issue 93 open. This was discussed at IETF68. Vijay 
> presented 4 options to solve the issue. These are captured in:
> 
> We need to make a decision on this issue and move forward 
> with the I-D. At the meeting itself, I got the sense that 
> option 3 was the one that had the least impact and easy to implement.
> 
> Please consider this email as a consensus call for issue 93. 
> The problem and choices are as follows (based on Vijay's slides):
> 
> Problem: UDP encapsulation is used in DS-MIP6 for NAT 
> traversal. The encapculations are either:
>  - IPv6-in-UDP-over-IPv4
>  - IPv4-in-UDP-over-IPv4
> There is a need (or I guess desirable) to indicate the type 
> of protocol being encapsulated in the UDP header.
> 
> Choices are:
> Reserve a UDP port for each protocol header (i.e one UDP port for
>    IPv6-in-UDP-over-IPv4 and another for 
> IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port and a 
> DS-MIP6 "tunnel type message"
> Pros and cons of these choices are in the slides that were 
> presented at IETF68 (see URL above).
> 
> Please provide your opinions and comments by May 15th, 07 on 
> the MIP6 mailing list.
> 
> -Raj
> 
>

---

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

> Agree. So this option would impy: Do nothing.

=> Yes.

 > redundant in this context.

=> I meant that they are redundant because they have no justification for
the operation of the spec. The rationale for the suggestion was that it was
not really possible (or difficult) to tell whether the following packet was
IPv4 or IPv6 if the implementation is in user space; and that it was
diffcult to know the packet length. However, after we discussed this, it
turned out that none of these issues are true, so I don't see why we need to
add another 4 bytes to every packet.

 > hosts and mobile routers. 

=> Sure, if there is something specific for nemo then we have to address it.
I still don't know what that is though. I'd appreciate it if someone can
explain it. 

And the other thing is if you want 
 > to have some

=> Yes.

 > packets other than IPv4/6 (eg. GRE) should be possible in 

=> I heard that too, but I don't know why we should add more overhead for
every host and router just so PMIP might use GRE, unless we want to make MIP
look like it's more wasteful. Also, I don't understand why GRE has to follow
UDP and not run after the IP header? I need to re-read GRE to see if that's
possible.

 > 3. Reuse 3519 (don't know if this was mentioned)

=> what do you mean by "reuse 3519"? You mean "make it look like 3519"?
That's not a reason though is it? 

Hesham

---

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

Sri Gundavelli wrote:
>> however I want to see what kind of additional payloads is
>> considered in the future.
> 

Sri - for NEMO, I don't understand.  Implementations of MIP6 and NEMOv6
today don't use GRE, neither GRE keys; NEMOv6 implementations don't need
GRE.

Alex

---

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

> will be possible with the TLV header.

Errr... this is too long and complicated and... undocumented?  What is 
that use case more exactly?

We can say that we 'tag' the MNP (Mobile Network Prefix) by the Home 
Address (not by the GRE key).

You seem to mention UDP - do you mean that DS-MIPv6 (and not NEMOv6) 
needs GRE?

Alex

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 11 May 2007 05:53:02 -0700

I support Option 1. (BTW, Option 4 does not work as far as I can tell)
Please see justification below...

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2007 10:16 PM
To: Mobile IPv6 Mailing List; [email-masked]
Subject: [Mip6] DS-MIP6: Consensus call to close issue 93

...

Choices are:

GT> This makes sense to me. It is simple, efficient and it is already
defined in the draft.

GT> While this is a reasonable alternative, I have not heard a
convincing argument to warrant a change from what the draft already
defines (i.e., option 1 above).

GT> This seems wasteful and unnecessary, given (1 and 2)

GT> This does not seem to work at all. DSMIPv6 can register IPv4 and
IPv6 addresses at the same time. This means that on a packet by packet
basis the header encapsulated over UDP can change from IPv4 to IPv6 and
back. Signaling one or the other in the BU (outbound indication) is
clearly not sufficient and so the indication has to be inbound with the
data.

Regards
George

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 11 May 2007 14:49:10 -0500

Hi Hesham,

On 5/11/07 12:15 AM, "ext Hesham Soliman" <[email-masked]> wrote:

> => I meant that they are redundant because they have no justification
> for the operation of the spec. The rationale for the suggestion was that
> it was not really possible (or difficult) to tell whether the following
> packet was IPv4 or IPv6 if the implementation is in user space; and that
> it was diffcult to know the packet length. However, after we discussed
> this, it turned out that none of these issues are true, so I don't see
> why we need to add another 4 bytes to every packet.

Whether you view it from an implementation perspective or from protocol
design perspective, does it not make sense to have the header indicate the
type of header or encapsulation that exists following the parsing of a
header? It is a matter of processing ease and clarity of the encapsulated
packet type vs the overhead of 4 bytes on every packet.

> => Sure, if there is something specific for nemo then we have to address
> it. I still don't know what that is though. I'd appreciate it if someone
> can explain it. 
> 
> => I heard that too, but I don't know why we should add more overhead
> for every host and router just so PMIP might use GRE, unless we want to
> make MIP look like it's more wasteful. Also, I don't understand why GRE
> has to follow UDP and not run after the IP header? I need to re-read GRE
> to see if that's possible.

Okay..

>> 2. Flexibility for future use

Is the flexibility argument worth considering? Design the protocol with
hooks for allowing it to be used in the case there exists encapsulation of
packet types other than v4/v6 in the future...

> That's not a reason though is it?

Agree that its not a good reason. What I was implying was that we could
learn from the 3519 experience and adopt a mechanism that has worked well.

-Raj

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 12 May 2007 11:44:12 +1000

Hi Raj, 

I think there is some misunderstanding on this issue. Some people seem to
think that there is no UDP port already allocated. I urge everyone to read
the draft. 

Some answers to your comments inline:

 > header? 

=> It certainly makes sense to to have a clear indication of the order of
headers 
to the receiver. There are two ways of doing that:
1. Just define the format so that UDP is followed by IP (v4 or v6). This is
effectively
option 1 in your email.
2. Have a generic TLV to indicate the type of the header following UDP. 
This is effectively option 3. 

Honestly, the other two options are non-options, especially given George's
email about option 4. 

The question is: when do you need 2) above? You obviously need it if there
are many different things that can follow UDP and cannot all be parsed by
simply reading the first byte. 
But this is not the case here because it's always IP. Now, I sent a separate
email indicating that if someone wants to use GRE for PMIP reasons they can
add the GRE header after IP and keep it transpared to the whole packet. 
So I don't see a reason for this "generic" header as flexible as it sounds,
such flexibility is not needed. 

It is a matter of processing ease and clarity of the 
 > encapsulated

=> The clarity is always there. I don't think the new header brings any
thing new, it's only clearer on paper, an implementer would see no
difference. 

 > packet types other than v4/v6 in the future...

=> Like I said, in general it sounds nice, but practically I don't see the
need. There is a lot of nice and flexible things we can add but they're also
wasteful by nature. I prefer to add things when needed.

 > learn from the 3519 experience and adopt a mechanism that 

=> Ok. But this is not rocket science :) We know that either mechanism will
work fine, but one of them will be 4 bytes heavier :)

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 12 May 2007 17:39:09 +0200

Hesham Soliman wrote:
[...]
> => The clarity is always there. I don't think the new header brings
> any thing new, it's only clearer on paper, an implementer would see
> no difference.

Hey, I agree with Hesham :-)

It is sufficient to say in spec that the payload of the UDP packet is an
IP packet that needs to be delivered back to the IP stack.  This kind of
behaviour is common in tunnelling implementations.  If someone wants to
write code about this, the pseudocode looks like this:

void
recv_packet (nb)
{
   if (portnumber == DS-MIPv6)
     ip_input (nb - UDP_header)
   else
     udp_input ();
   return;
}

whereas the function with an intermediary layer would look like this:

void
recv_packet (nb
{
   if (portnumber == DS-MIPv6)
     {
       parse_after_udp (nb);
       if (thin-layer says there's IP packet)
          ip_input (nb - UDP_header - thin-layer);
       else
          udp_input ();
     }
   return;
}

Remark more code (not only more headers).

Alex

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 12 May 2007 09:16:24 -0700

Alex: 

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Saturday, May 12, 2007 8:39 AM
> To: Hesham Soliman
> Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93
> 
> 

1 line of code is more code, for checking the type of the
message, rather assuming its an IP packet ? Is this argument
right ? 

Also, your psueo code is assuming in_input is handling both
versions of the packet. In most implementations, the handlers
are different. So, on the extra code you are talking about,
you have to check either the type field of the TLV header or
the 1st byte in the payload any case. How do you do the error
handling for dropping 1st byte that is not IPv4 or IPv6. So,
where is the extra code ? 

For one last time, GRE tunneling is widely used for the semantics
it provides, GRE key field, seq number fields etc. MIP4 support
GRE and IPIP for a reason. We need GRE for many reasons and also
for NAT traversal. 3519 supports the same model. Instead of closing
the doors and arguing on the use case, why cant this simple hook
be provided and be bit more flexible. Leaving this 4-byte TLV
header, allows us to add keepalive message, GRE header or some
other tunneling header. What is the cost ? 1 or 0 lines of
handling code ? 4-bytes in the packet ? Are we sending Max MTU
packets ? In wireless tx, does it even matter ? Why cant we just
follow 3519 convention ?

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 12 May 2007 22:39:47 +0200

Sri Gundavelli wrote:
>> It is sufficient to say in spec that the payload of the UDP packet 
>> is an IP packet that needs to be delivered back to the IP stack. 
>> This kind of behaviour is common in tunnelling implementations.  If
>>  someone wants to write code about this, the pseudocode looks like 
>> this:
>> 
>> void recv_packet (nb) { if (portnumber == DS-MIPv6) ip_input (nb - 
>> UDP_header) else udp_input (); return; }
>> 
>> void recv_packet (nb { if (portnumber == DS-MIPv6) { 
>> parse_after_udp (nb); if (thin-layer says there's IP packet) 
>> ip_input (nb - UDP_header - thin-layer); else udp_input (); } 
>> return; }
>> 
> 1 line of code is more code, for checking the type of the message, 
> rather assuming its an IP packet ? Is this argument right ?

We can go into compilation details to find out which kinds of lines take
the more time to execute (and it's actually the 'if's).

> Also, your psueo code is assuming in_input is handling both versions 
> of the packet. In most implementations, the handlers are different.

Right... I meant generic.

> So, on the extra code you are talking about, you have to check either
>  the type field of the TLV header or the 1st byte in the payload any 
> case. How do you do the error handling for dropping 1st byte that is 
> not IPv4 or IPv6. So, where is the extra code ?

Ok... it was generic and pseudo.  Everything can be implemented.  We
better discuss protocol.

> For one last time, GRE tunneling is widely used for the semantics it 
> provides, GRE key field, seq number fields etc. MIP4 support GRE and 
> IPIP for a reason.

Do you agree MIP4 can work without GRE?  I have an implementation that does.

> We need GRE for many reasons and also for NAT traversal. 3519 
> supports the same model.

3519 supports both IP-in-UDP and GRE-in-UDP tunnelling.  An implementer
has the choice to implement only one of them and it will work fine.

Proposing GRE to DS-MIPv6 is an invitation to interoperability issues 
(what if my MR does GRE-in-UDP) but your HA only does IP-in-UDP).  Do we 
want to open the door to new interoperability issues by allowing GRE as 
an option?

> Instead of closing the doors and arguing on the use case, why cant 
> this simple hook be provided and be bit more flexible. Leaving this 
> 4-byte TLV header, allows us to add keepalive message,

Keepalive message can be done as a Mobile IP message type extension,
doesn't need to be a new TLV or GRE.

> GRE header or some other tunneling header. What is the cost ?

Ok, let's talk cost in terms of interoperability, not lines of
code/memory/bits on wire.

I think there is a significant risk in adding GRE as an option to
DS-MIPv6, in terms of interoperability.

Alex

> 1 or 0 lines of handling code ? 4-bytes in the packet ? Are we
> sending Max MTU packets ? In wireless tx, does it even matter ? Why
> cant we just follow 3519 convention ?
> 
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 16 May 2007 19:24:15 +0200

on 2007-05-08 23:16 Basavaraj Patil said the following:
...
> 4. Encapsulated protocol header type is indicated in the BU message

There has been some clarifications to Basavaraj's original formulation
(above), and I agree with the clarifications.  I'm responding to the
original email to make the tallying simple.

I originally thought that I'd find either 1. or 3. equally acceptable,
but after the side discussion about GRE and alternative keepalives, I
find that despite the small additional overhead of 4 bytes of solution
3., I prefer it because it is somewhat more future-proof.  We don't
strictly need 3. today, but it provides some freedom for tomorrow when
compared with 1.  (2. and 4. aren't tempting at all.)

The choice was easier in 3519, although not obvious -- at first we
thought we could do without the 4-byte overhead there too, but it looks
increasingly as if it was a good idea to have the added header in that
case.

So: I prefer alternative 3.

	Henrik

---

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

Option 4 needs some more work. It is incomplete when you consider
what is shown in the slides. We briefly touched upon this during
the IETF meeting in Prague. Option 4 can be used in environments
where you actually run the signaling protocol (Binding Update/
Binding Ack) and setup a flow (for a particular session/app). You
run the signaling protocol each time you want to setup a separate
flow. 

I was planning to work on it and specify it in more detail, but
don't have the time for it. I think we should remove option 4 from
the list of options, unless someone wants to work on it and specify 
it in more detail.

Vijay

> From: Tsirtsis, George [mailto:[email-masked]] 
> Sent: Friday, May 11, 2007 5:53 AM

---

From: <[email-masked]>
Date: Thu, 17 May 2007 09:48:25 +0300

Hi,

>4. Encapsulated protocol header type is indicated in the BU message

I prefer to go with option 2. From MN perspective the extensibility that
a TLV header brings (e.g. support for GRE) is
not important. So my suggestion is to allocate one port for
IPv4-UDP-IPv4/IPv6 and define that now in the draft. If there is a need
to support other protocols later, then allocate a new port. This way we
can have a "green" protocol without the extra 4-byte overhead and still
allow to add support for other protocols later. Having separate ports
for IPv4-UDP-IPv4 and IPv4-UDP-IPv6 is something I don't like just
because we'd need to have separate keepalives for both ports.

Cheers,
Markku