|
»
« Return to Thread: SMF and intarea-ipv4-id-update
Re: [Int-area] SMF and intarea-ipv4-id-update
by Joe Touch
::
Rate this Message:
Hi, Joe,
On 11/15/2011 9:01 AM, Joe Macker wrote:
> 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.
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.
>> 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
>>>> manet@...
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>
>>> _______________________________________________
>>> Int-area mailing list
>>> Int-area@...
>>> https://www.ietf.org/mailman/listinfo/int-area
>>
>_______________________________________________
manet mailing list
manet@...
https://www.ietf.org/mailman/listinfo/manet
On 11/15/2011 9:01 AM, Joe Macker wrote:
> 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.
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.
>> 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
>>>> manet@...
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>
>>> _______________________________________________
>>> Int-area mailing list
>>> Int-area@...
>>> https://www.ietf.org/mailman/listinfo/int-area
>>
>
manet mailing list
manet@...
https://www.ietf.org/mailman/listinfo/manet
« Return to Thread: SMF and intarea-ipv4-id-update
| Free embeddable forum powered by Nabble | Forum Help |
