Subject: Re: [manet] [Int-area] SMF and intarea-ipv4-id-update

From: Joe Macker <[email-masked]>
Date: Tue, 15 Nov 2011 12:01:16 -0500

Joe:

After a few Last Calls I think your comment is the main one that still needs addressing.

I have been through lengthy rewrites based upon other reviewers input but I could now use some input on how to proceed to avoid further document stall. The biggest detractor in doing it like IPv6 is the need for an IPv4 header option.

Some options forwards:

(1) Split the document into IPv4/v6 versions.  I think IPv6 version could move forward. Deal with IPv4 in parallel.  Since its EXP I'd prefer to keep it together but its an option to split these apart.

(2) Rewrite the IPv4 approach to be more in line with IPv6 approach. For IPv4 this document has attempted to avoid header options as an approach. As an older IETF participant I sort of have a prejudice against using IPv4 header options based upon past discussion with vendors,etc. Perhaps this is less founded since deployments might be limited to edge networks, so any feedback on that would be appreciated. I think IPSEC and fragment headers work fine but If we copied the IPv6 approach for IPv4 we would need to create an IPv4 header option with an ID field or hash assist value.  

(3) Remove the I-DPD mode from IPv4 and only have a hash mode. A non-assisted hash mode would of course not be robust since packets are sometimes produced that have the same content. Not a fan of this although its an easy change.

I think options 1, 2 are the way forward but could use some group feedback on whether it would wise to split the document.
I would also be open to anyone doing an IPv4 section rewrite.

-Joe 

On Sep 14, 2011, at 7:33 PM, Joe Touch wrote:

> Hi, all,
> 
> I'm getting back to updating this doc, and wanted to come back to this issue...
> 
> Is there a reason why the mechanism proposed for IPv6 (which does not reliably include an ID field) is insufficient for IPv4?
> 
> Joe
> 
> On 3/30/2011 7:10 AM, Joe Macker wrote:
>> Yes this is an optional duplicate detection scheme and is an example of use in practice.
>> 
>> Also As Teco mentioned this intended for limited use in edge network multicast systems.
>> 
>> On Mar 30, 2011, at 1:29 PM, Teco Boot wrote:
>> 
>>> Sorry for x-posting. But there is a conflict in:
>>> http://tools.ietf.org/html/draft-ietf-manet-smf
>>> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update
>>> 
>>> SMF has a duplicate packet detection function based on the IPv4
>>> ID field. So text in ietf-intarea-ipv4-id-update section 4
>>> is not correct, in that there would be no deployments for such.
>>> That said, SMF deployment with IPv4 DPD on IP-ID would be limited.
>>> 
>>> What to do?
>>> 
>>> Teco
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> manet mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/manet
>>> 
>> 
>> _______________________________________________
>> Int-area mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Nov 2011 13:35:35 -0800

Hi, Joe,

On 11/15/2011 9:01 AM, Joe Macker wrote:
> (1) Split the document into IPv4/v6 versions. I think IPv6 version
> could move forward. Deal with IPv4 in parallel. Since its EXP I'd prefer
> to keep it together but its an option to split these apart.

I don't think this is a good idea; at this point, all IETF docs that 
have applicability to both IPv4 and IPv6 should do so in the same doc IMO.

> (2) Rewrite the IPv4 approach to be more in line with IPv6 approach.
> For IPv4 this document has attempted to avoid header options as an
> approach. As an older IETF participant I sort of have a prejudice
> against using IPv4 header options based upon past discussion with
> vendors,etc. Perhaps this is less founded since deployments might be
> limited to edge networks, so any feedback on that would be appreciated.
> I think IPSEC and fragment headers work fine but If we copied the IPv6
> approach for IPv4 we would need to create an IPv4 header option with an
> ID field or hash assist value.

There are several concerns here, but even being generous I don't see 
this as viable. IP packets with header options go slow-path, which means 
(at best) they're out of order and significantly delayed compared to 
non-option packets.

> (3) Remove the I-DPD mode from IPv4 and only have a hash mode. A
> non-assisted hash mode would of course not be robust since packets are
> sometimes produced that have the same content. Not a fan of this
> although its an easy change.

This is already the case, FWIW, for IPv4 packets with current ID use. 
The IDs wrap fast enough that you already see packets with duplicate IDs 
that are NOT duplicate packets.

I would suggest that this is the only way forward unless you add 
information to the packet. E.g., IPsec for IPv4 adds a "shim" layer:

	IP/TCP/data -> IP/IPsec/TCP/data

You could require your edge devices add this info if needed. That turns 
MANETs into a LISP/TRILL-like cloud architecture, not merely IP 
forwarding. That seems like more than you want to do...

Joe

>> I think options 1, 2 are the way forward but could use some group
> feedback on whether it would wise to split the document.

---

From: Joe Macker <[email-masked]>
Date: Tue, 15 Nov 2011 17:23:08 -0500

On Nov 15, 2011, at 4:35 PM, Joe Touch wrote:

> I don't think this is a good idea; at this point, all IETF docs that have applicability to both IPv4 and IPv6 should do so in the same doc IMO.
> 
> There are several concerns here, but even being generous I don't see this as viable. IP packets with header options go slow-path, which means (at best) they're out of order and significantly delayed compared to non-option packets.

The "slow path" type issues are exactly what I was trying to avoid.

> This is already the case, FWIW, for IPv4 packets with current ID use. The IDs wrap fast enough that you already see packets with duplicate IDs that are NOT duplicate packets.

Ok, that is a way forward. Go with non-fragment/non-IPsec hash mode and also keep the more explicit IPsec, fragment processing discussion that I believe is ok.  I have robustness concerns but .

> 
> I would suggest that this is the only way forward unless you add information to the packet. E.g., IPsec for IPv4 adds a "shim" layer:
> 

of course its non-TCP since its only a multicast forwarding document. 

> 
> You could require your edge devices add this info if needed. That turns MANETs into a LISP/TRILL-like cloud architecture, not merely IP forwarding. That seems like more than you want to do...

Right, was thinking about that option since IPsec DPD use is already defined.  Dont necessarily want to go there but its there as a possibility.

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Nov 2011 17:07:20 -0800

On 11/15/2011 2:23 PM, Joe Macker wrote:
...
> Ok, that is a way forward. Go with non-fragment/non-IPsec hash mode
> and also keep the more explicit IPsec, fragment processing discussion
> that I believe is ok.

I think that's what's already in the IP-ID doc at this point, so that'd 
be good (I don't go into detail with the IPsec variant, but that's not 
critical IMO to the IP-ID doc).

Joe