Re: [CARD Technical Issue] Dropping FMIPv6 piggybacking

Marco,

What I specifically had in mind by "complex" was this.

Suppose CARD was defined to just work with FMIP. Then there would be no need
for setting the flag and sending an initial CARD Request/CARD Reply to
determine if piggybacking was supported. The MN would simply use FMIP, and
if the AR didn't return anything, it would know that the AR is not CARD
capable. This is very simple.

Now, suppose that piggybacking was not supported. The MN sends CARD Request
and if it gets a CARD Reply it knows that CARD is supported, it can use the
CARD protocol. This is also very simple (though more complex than the FMIP
case because there are two protocols instead of one).

With the current design, the MN must negotiate and choose which to use.
Perhaps "complex" was too strong a word, but it is an extra bit of protocol
that could be simplified.


            jak

PS: I still believe that interoperability with FMIP is desirable, but I
think its more important now to simplify things to reduce the chances of the
draft getting caught in the IESG's lint filter. I would like to see this
draft sail through the IESG.

----- Original Message ----- 
From: "Marco Liebsch" <[email protected]>
To: "James Kempf" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, July 02, 2003 3:44 AM
Subject: Re: [Seamoby] [CARD Technical Issue] Dropping FMIPv6 piggybacking


>
>
> James,
>
> it's not a complex negotiation using specific protocol messages,
> its discovery by means of setting a flag to indicate to
> communication peers the sender's capability to convey CARD signaling
> with the FMIP protocol sequence between MN and AR. Now, this indication
> is needed for MNs and ARs to learn about whether or not CARD message
> options can be appended to RtSolPr and PrRtAdv messages.
>
> Performing CARD, the MN knows already in advance if subsequent
> CARD signaling messages can be appended to FMIP signaling, so, no
> explicit discovery of piggybacking capability is required.
>
> To keep FMIP operation in mind when designing the CARD protocol
> was advice from the beginning. Now, to not restrict CARD to
> FMIP was also discussed here, which is a reasonable design goal.
> Why not keeping this flexible and use CARD with FMIP if supported,
> otherwise use CARD protocol operation stand-alone by means of
> appending the CARD signaling to the specified CARD main header.
> Btw., latter approach should be the default operation.
>
> marco
>
>
>
>
> James Kempf wrote:
>
> >Section 4.5 describes a negotiation between the MN and AR to determine
> >whether CARD is piggybacked on FMIPv6. This negotation seems complex and
> >unnecessary. For simplicity, I think we should do one or the other.
Though I
> >favor piggybacking because it simplifies the entire handover across both
> >protocols, requiring the MN to negotiate whether to use FMIPv6 makes the
> >handover more complex. Since the DT and WG don't seem to agree, I believe
we
> >should drop FMIPv6 piggy backing.
> >
> >            jak
> >
> >
> >_______________________________________________
> >Seamoby mailing list
> >[email protected]
> >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
>
>
>