Re: [CARD Technical Issue] Dropping FMIPv6 piggybacking

James,

I see, but I am not sure if a "try-and-error" mechanism for discovery is
much better, in particular since this procedure needs to be performed
with each AR the MN attaches to, right?
This is simpler with the current mechanism, since the MN knows in advance
if it will suceed with performing CARD via FMIP or not with its next AR.
If not, then the MN can use the stand-alone CARD mechanism. In your example
it should be distinguished between "piggybacking capable" and "CARD capable"
nodes. Only the first support can be identified with the P-flag.

marco



James Kempf wrote:

>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
>>>
>>>
>>>      
>>>
>>
>>    
>>
>
>  
>