Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

From: Brian Haley USG <[email-masked]>
Date: Wed, 13 Feb 2002 15:14:42 -0500

> The DT has come to the following conclusions:
> 
> (a) For reasons of timing, we do not recommend extending
>     IPsec specifications in any manner.  Therefore, we feel
>     that approaches that rely on better IPsec policy
>     granularity should not be considered.

CAN LIVE WITH.  If I'm using IPsec between a MN and CN/HA, I'll use it
for every packet, not just BUs.

> (b) We recommend that when IPsec protection is used, it is
>     always used in *addition* to RR (or CGA) methods, not as
>     a replacement. Thus RR (or CGA) methods would be used to
>     protect MN - CN Route optimization procedures even when IPsec
>     is used.

DISAGREE.  IPsec AH covers enought header fields so that we know the
packet wasn't changed in flight.  RR seems like overkill.

> (c) Binding update messages for both HAs and CNs, binding
>     acks,

DISAGREE.  There is no reason a MN can't set a bit (P-bit?) to tell
the HA/CN it should not be sent a piggybacked BA or BR.  We already
know that most CNs support piggybacking (either Ericsson or UNH had
a ping test last Connectathon that piggybacked), and it's easy to
control the BU behavior on a MN.  If the CN doesn't wish to have the MN
piggyback in the future, it can just return a new < 128 status code -
this would cover the MN to MN case.  So technically it looks to me
like there's a way to eliminate all but the first Binding piggyback.

>     RR messaging, and CGA messaging are to be
>     implemented as a new message set without the ability
>     to piggyback data packets on those messages

CAN LIVE WITH.

>     The basis on this recommendation is as follows:
> 
>       - The DT recognizes the potential benefits of piggybacking.

How can the DT recognize there is a *potential* benefit, but decide
to kill piggybacking?

-Brian

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 18:32:27 +0100 (CET)

> How can the DT recognize there is a *potential* benefit, but decide

Brian,

There is a potential benefit it lots of things - I can envision benefits
in carry BUs as XML over http (but there might be some disadvantages as well
:-)

The issue is the engineering tradeoff.

  Erik