[lifting up monmami6 WG from CC]

Hesham Soliman wrote:
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.

=> This is not different from a router in the fixed network that load-balances traffic without informing end hosts. This happens all the time today and no one is making e2e arguments about that.

Hi HEsham, I'm not sure how it's thought routers in the fixed network
load-balance traffic without informing end-hosts.  IETF has some nice
qos reservation mechanisms that are triggered by end-node after which
routers in the middle look at packet markings and load-balance
accordingly.  COPS, RSVP, Traffic Class, Diffserv are keywords for
search.  It's the end-node who tags the packets anyways.

It's even true for a MIP6 HA: HA copies the traffic class from inner to
outer header, so what's decided by MN is respected by HA.  (there's an
option with pre-configured Traffic Class at HA , but optional that is).

So I think flow bindings for NEMO _would_ be different than
COPS/RSVP/Traffic Class, because MR would make decisions irrespective of
the LFN will, what do you think?

Alex


_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area

Reply via email to