Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13

[Ryuji Wakikawa <[e-mail]>]

Hi Romain,

On 2009/05/09, at 9:56, Romain KUNTZ wrote:

> Hi,
>
> Some comments on draft-ietf-monami6-multiplecoa-13.
>
> First, I'd like to express that I support Arnaud's opinion about  
> section 5.6 (Simultaneous Home and Visited Link Operation). I also  
> don't see what is the motivation to re-route and tunnel traffic from  
> the HA to one of the MN's CoA, while the MN is only one hop from the  
> HA. Even if there is a specific use-case, at the time this topology  
> was suggested, a simple solution that came out was to configure a  
> CoA on the Home link and use a tunnel via the home link. I don't  
> think the little overhead of this solution justifies the complexity  
> of the one proposed in the draft.

This was discussed at WG. We agreed to have this feature at the end.
I understand the complexity, but this is how WG agreed.

It is not possible to change the consensus at this moment. We passed  
all last call.

> Another concern I have is about the use of route optimized traffic  
> between the MN and the HA. I've already raised this problem long  
> time ago and I don't think it was addressed in the draft (excuse me  
> if I skipped the text), so I'll try to explain it in short again:
>
> RFC 3775 says in section 9.3.1:
>
>   Mobile nodes can include a Home Address destination option in a
>   packet if they believe the correspondent node has a Binding Cache
>   entry for the home address of a mobile node.
>
> So a MN may include an HOA dest. option in the packets destinated to  
> the HA instead of reverse-tunneling them. The source address of the  
> packet would thus be the CoA of the interface from which the packet  
> is sent. At the Home Agent side (still in section 9.3.1):

>   [...] the currently registered care-of address MUST be equal to
>   the source address of the packet.  These tests MUST NOT be done for
>   packets that contain a Home Address option and a Binding Update.
>
> The MCoA draft does not say anything about the behavior the HA  
> should have in that case. As packets do not contain any information  
> about the BID binded to the CoA used to send the packet, the HA at  
> this time would have, for each packet, to check if the source  
> address of the packet is equal to *one of the CoA registered for the  
> corresponding BCE*, thus to parse the list of all the CoA registered  
> for the node.
>
> However I have some doubts about the efficiency of such tests if the  
> number of CoA registered of each node is great and if there is a lot  
> of traffic. One solution could be to use reverse tunneling rather  
> than HOA dest. option when the node uses MCoA and wants to send  
> packets (other than Mobility Headers) to its HA.
>
This is the case when the destination is HA.  The recursive check is  
not for all the traffics from MNs, but for the traffic between MN and  
HA.
We have texts in Section 6.5

> Then, when the HA replies, it must put a RTH2 in the reply instead  
> of reverse-tunneling the packet. How does the HA select the source  
> address to put in the RTH2? As the RTH2 is included once the IP  
> packet is forged by upper layers, the HA has no way to maintain a  
> state for each packet received from a node to know which address to  
> include in the RTH2 of the reply. Picking up one randomly may result  
> in a non-symmetric path between the MN and the HA.

This is not MCoA stuff, but it's flow filtering matter.

> For that reason I would suggest to add some text stating that  
> traffic from the MN to the HA (except for the mobility signaling  
> messages) must not be route optimized.

I don't see any modification is required for this.

> Two other minor comments on the draft below:
>
> - Section 6.2 (Processing Binding Update)
>
>      *  If the 'O' flag is set in the Binding Update, the home agent
>         removes all the existing bindings and registers the received
>         binding(s).
>
> It is not explicitly said that the MN can use the O flag with a CN.  
> I think nothing prevents the MN to use it, so we should replace  
> "home agent" with "receiving node".
>
>   If all the above operations are successfully completed, a Binding
>   Acknowledgement containing the Binding Identifier mobility options
>   MUST be sent to the mobile node.
>
> The BAck must be sent only if the 'A' flag was set in the BU, right?  
> or does the MCoA spec mandates sending BAck in all cases?

BA is sent only A flag is set.
I will update this to

>   If all the above operations are successfully completed, a Binding
>   Acknowledgement containing the Binding Identifier mobility options
>   MUST be sent to the mobile node if  'A' flag is set in the  
> received Binding Update.

Please let me know if you have further comments on this.

thanks Romain,
ryuji

>
> Cheers,
> -- 
> Romain KUNTZ
> [e-mail]
> LSIIT - Networks and Protocols Team
> http://clarinet.u-strasbg.fr/~kuntz/
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext