Hesham Soliman wrote:
Hi Heikki,
I guess Jari wants us to continue this point on the int-area list so
I'll respond to both. See below.
Hesham Soliman wrote:
Regardless of the approach, the solution we had in mind
would transfer flow
descriptions and binding information between the flow in
question and one or
more of the mobile node's addresses. The sender of this
information is the
mobile node. The receiver is either a correspondent node or
another intermediate node. If we use the terms HA/MAP then we're
implying the use of
MIPv6. So I'll stick to generic language.
==> I think that the solution you describe in your draft for flow
bindings might be enough for MIPv6 but it is not sufficient for
instance in NEMO case (or other non MIPv6 intermediate node case).
In the flow binding draft it is mandatory for the intermediate
node to be able to receive a BU message, right?
In NEMO the MNN cannot send a BU message to the MR so the MNN.
Because of this you would need to write another draft (which would
resemble I think the one or both of the alternative solutions). Or
change the NEMO so the MNN can send BU to the MR?
=> No no no :). You've skipped a lot of steps here. First of all, the
current solution does support nemo because the signalling can be
sent from the MR to the HA/MAP. As you probably know nemo does not
allow the MR to send BUs to a CN, so this fully supports nemo.
Yes both Hesham and Heikki: MNN doesn't send NEMO BU and MR doesn't send
BU toCN.
(terminology: MNN as defined by terminology documents is a Mobile
Network Node, thus a Mobile Node, which can be a Mobile Router; but I
assume the intent was to say a MH (not a MR) that is connected to a
moving network doesn't send BU to MR - I agree with this).
Now, your second point is about an MNN sending a BU. First, lets be
clear that the MNN does not send BUs to the MR in any spec defined
today, so the BU would have to be sent from the MNN to a CN/HA/MAP. I
don't see why this can't be done in draft-soliman. If you mean that
the MNN (more likely a VMN) needs to know what properties correspond
to which prefix advertised by the MR then this goes back to a
separate issue of how the MR informs MNNs of the properties
associated with advertised prefixes. This issue was raised many years
ago (when nemo was a bof) and was recently referred to by Thierry in
his response to a query about this point. Thierry's response was on
this thread so feel free to take a look.
Regardlessof Thierry mentioning it, it's still unsolved.
It's still true that an LFN/MH has certain preferences for application,
preferences that aren't currently communicated to MR. So when MR makes
monami decisions on which interface to use it's monami-relevant only for
that MR, not for LFN.
In this sense, monami filters at MR are irrelevant to LFN. In which
case one can easily say that monami filters are only for MR. Which is
easy to say that is relevant only for the MH part of that MR.
My reasoning is. But let me turn it into a question:
What's the effect of MR monami filters on the LFN application?
So the bottom line is the MIPv6 solution does support this case.
Just as an example. In NEMO the MNN might have a need to set the
preferred routes for it's traffic into the MR. For instance, think
of a case where the MNN is a laptop and the user uses a cellular
phone with multiple interfaces as a MR. In this scenario the user
most certainly would expect some control over the application flows
from the laptop trough the phone.
=> Of course, so if it gets the prefixes from the MR and associated
properties with each one it can make that choice. I don't see the
relationship between this issue and the current discussion on this
thread.
I agree with you with the first part. But I see a strong relationship
of MR making monami decisions and its effects on LFN. If this
relationship is not defined then one simply can't say Monami is for
NEMO. End-to-end arguments can be made about this.
I also think a clear distinction should be made here, that I wanted to
say since long but things were too hectic at that time.
When monami6 was formed there network mobility was an important topic
discussed in many places. Monami6 has a goal to work in the NEMO
context, so it helped building it up. This can be understood in two ways:
-simplest: NEMO is an extension to MIP, so a HA doing NEMO can be
extended to do monami (mcoa) and it will continue to do NEMO no
problem. But that doesn't mean NEMO protocol was extended. It more
means that that HA will continue to use UDP as before, or HTTP or NEMO.
-more complex: have monami flow bindings to have a meaning _through_ the
MR, to LFN and have a NEMO sense. That is a more relevant means to say
that the MONAMI6 WG does NEMO. OTherwise monami6 does NEMO as much as
it does UDP.
Alex
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
