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

From: Romain KUNTZ <[email-masked]>
Date: Sat, 9 May 2009 18:56:48 +0200

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.

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.

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.

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.

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?

Cheers,
-- 
Romain KUNTZ
[email-masked]
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

---

From: Romain KUNTZ <[email-masked]>
Date: Sat, 9 May 2009 19:15:23 +0200

One more comment inline:

On 2009/05/09, at 18:56, Romain KUNTZ wrote:
> 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 MCoA draft does not say anything about the behavior the HA  
> should have in that case.

My mistake, actually it does say something, in section 6.5 (Receiving  
Packets from Mobile Node):

    When a node receives packets with a Home Address destination option
    from a mobile node, it MUST check that the care-of address that
    appears in the source address field of the IPv6 header MUST be equal
    to one of the care-of addresses in the binding cache entry.  If no
    binding is found, the packets MUST be discarded.  [...]

But my comment on the efficiency (especially at the HA side) still  
holds, in addition to the other issue related to the RHT2.

Cheers,

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 11 May 2009 13:59:33 -0700

Hi Romain,

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

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

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

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

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

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

>   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

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 11 May 2009 14:01:27 -0700

Hi Romain,

On 2009/05/09, at 10:15, Romain KUNTZ wrote:

>> 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):
>>
> My mistake, actually it does say something, in section 6.5  
> (Receiving Packets from Mobile Node):
>

I have answered to this.

This situation is only for the traffic between MN and HA. The same  
rule apply to the traffic between MN and CN.
The issue of RHT2 is not MCoA matter. It is solved by flow binding.

thanks
ryuji

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 12 May 2009 23:08:28 +0200

Hi Ryuji,

> rule apply to the traffic between MN and CN.

Right, and I was especially concerned about the HA because it may have  
more MN to handle than a CN. I thought it could be a problem if there  
are lots of MNs-HA communications (but on the other hand, I can't  
think of an use-case where MN-HA communications would be frequent).

If you think it would not cause possible performance issues, I'll  
trust you on that.

> The issue of RHT2 is not MCoA matter. It is solved by flow binding.

Well, yes it could be solved by flow binding. I had in mind a case  
where only MCoA would be used. But I was already told here that  
everything related to flow distribution should be handled by some flow  
filtering mechanism, and not MCoA itself only, so I'll stop arguing on  
that.

Cheers,
romain

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 12 May 2009 23:08:35 +0200

Hi Ryuji,

On 2009/05/11, at 22:59, Ryuji Wakikawa wrote:
>> 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.
>

Ok, this has also been extensively discussed in another thread - I'll  
follow the WG agreement then.

>> "home agent" with "receiving node".

You didn't ack the above comment, did you skip it by mistake?

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

Looks fine with me!

Thanks,
romain

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 13 May 2009 15:32:40 -0700

Hi Romain,

2009/5/12 Romain KUNTZ <[email-masked]>:
>>> But my comment on the efficiency (especially at the HA side) still holds,
>>> in addition to the other issue related to the RHT2.
>>
>> I have answered to this.
>>
>> This situation is only for the traffic between MN and HA. The same rule
>> apply to the traffic between MN and CN.
>
> Right, and I was especially concerned about the HA because it may have more
> MN to handle than a CN. I thought it could be a problem if there are lots of
> MNs-HA communications (but on the other hand, I can't think of an use-case
> where MN-HA communications would be frequent).

ok. From the MIP6 protocol, there is only protocol signaling exchange
between MN and HA.
As you said, there isn't use-case of MN-HA data communication.
We don't need to bother the data traffic between MN and HA.

>
> If you think it would not cause possible performance issues, I'll trust you
> on that.
>
>
> Well, yes it could be solved by flow binding. I had in mind a case where
> only MCoA would be used. But I was already told here that everything related
> to flow distribution should be handled by some flow filtering mechanism, and
> not MCoA itself only, so I'll stop arguing on that.

OK

thanks,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 18 May 2009 10:14:58 -0700

Hi Romain,

On 2009/05/12, at 14:08, Romain KUNTZ wrote:

>>> 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  
>> It is not possible to change the consensus at this moment. We  
>> passed all last call.
>
> Ok, this has also been extensively discussed in another thread -  
> I'll follow the WG agreement then.
>
>>> 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".
>

I've already replaced it :-)

thanks!
ryuji