[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13
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
kuntz at lsiit.u-strasbg.fr
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext