Re: CARD issue#29: more text on use of "Context-ID" and "M-flag"required

This is exactly what the current protocol description proposes. But only
adding the L2_ID sub-option in the reply does not solve the problem. You 
can see in the
example below that in case two or more L2_IDs connect to the "same" CAR,
this is indicated with the M-flag (M=matched) in the L2_ID coming back 
to the MN with the
CARD Reply. Sending back L2_ID with a CARD Reply in case this
particular L2 ID does "not" connect to a CAR that has been already
previously resolved, is redundant. Actually, a L2 ID that comes back with
a CARD Reply could be taken already as an indicator that the respective 
context-ID
has been adjusted to a previously received conext, this could avoid the 
M-flag.

What do you think?

marco

Vijay Devarapalli wrote:

>I am against using this mechanism. why not just include
>the L2_ID suboption in the CARD reply too? ofcourse it
>would increase the number of bytes in the CARD reply,
>but I think it helps in reducing the overall complexity
>of the CARD protocol.
>
>Vijay
>
>Marco Liebsch wrote:
>  
>
>>Hi all,
>>
>>going through the remaining open issues, there are some
>>important ones, which have not been discussed during the
>>meeting in Vienna. Here is one:
>>
>>There was a comment that more text w.r.t use of Context-ID
>>and the M-flag is required. The proposal is to briefly describe
>>the mechanism again and to solicit comments. After having agreed
>>on a mechanism, more text will be added to the document.
>>Please find a desciption/example of the proposed mechanism below:
>>
>>Since the L2 ID, a CAR's IP address and associated capabilities come
>>with separate sub-options in a CARD Request/Reply message,
>>association is indicated using a Context-ID.
>>Example:
>>
>>MN listens to L2_ID(1) and L2_ID(2), sends them to its current AR
>>in a CARD Request for resolution:
>>
>>CARD Request (MN->AR)
>>L2_ID(1) comes with one L2_ID sub-option, Conext-ID=1
>>L2_ID(2) comes with one L2_ID sub-option, Conext-ID=2
>>
>>Now, first assume both L2_IDs (APs) connect to 2 different
>>CARs, hence, associated IP address and capability container
>>is identified with the respective Context-ID :
>>
>>CARD Reply (AR->MN)
>>IP address of CAR(1) comes with capability container(1), both carry Context-ID=1.
>>IP address of CAR(2) comes with capability container(2), both carry Context-ID=2.
>>
>>Now assume L2_ID(2) and L2_ID(1) connect to the "same" CAR:
>>IP address of CAR(1) comes with capability container(1), both carry Context-ID=1.
>>L2_ID(2) comes back with "Context-ID=1", "M-flag=1".
>>
>>M-flag avoids to send IP address and capability container of the same CAR
>>back the the MN twice. Hence, Context-ID of L2_ID(2) has been re-addressed
>>to Context-ID=1, M-flag indicates that Context-ID has been modified by the
>>AR and that associated CAR IP address and associated capability container
>>is the same as for a previously received IP-address/capability
>>container pair, here indicated with Context-ID=1.
>>
>>Comments?
>>
>>marco
>>
>>_______________________________________________
>>Seamoby mailing list
>>[email protected]
>>https://www1.ietf.org/mailman/listinfo/seamoby
>>    
>>