Subject: [MEXT] Comments on draft-ng-nemo-ce-req-02.txt

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 21 Jul 2008 12:19:21 +0200

Hi Chan-Wah,

	I've read last version of the CE NEMO RO Requirements draft and I have
some minor comments.

	First of all, I found quite interesting the scenarios' descriptions. It
quite useful to know what you consumer electronics manufacturers think
it'd be deployed in the future and what optimisations need to be
addressed.

	Regarding the content of the draft, I already sent some comments in the
past based on a previous version of the draft. I'd like to add the
following minor comments/questions:

	* Regarding Req4 (Protocol Harmony), IMHO a NEMO RO approach that is
not able to operate with some protocols (I'm thinking in IPsec, which
could be the most problematic) could also be OK, as long as the NEMO RO
approach does not prevent these protocol to operate (following the
bi-directional tunnel path). I'd say Req4 is a desired requirement.

	* Regarding Des4 (Separability), I think this should be a required
characteristic (rather than a desired one), since trying to route
optimise everything could be very suboptimal. Even if this is only
statically configured, some communications should be allowed not to be
optimised.

	Thanks,

	Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 22 Jul 2008 12:38:12 +0800

Hello Carlos,

Thanks for the comments.

> bi-directional tunnel path). I'd say Req4 is a desired requirement.

The problem here is how does the MR/MN knows which protocol is
supposedly broken by RO?  The consumer electronics cannot rely on a
experience/knowledgeable user.  If RO starts breaking certain protocols
for them (eg IPSec while they try to access company's VPN), they will
ditch the MR and buy another one.

Even if the MR knows, how MR knows which protocol the MNN is running
then?  It is much safer, IMHO, to strictly insist on protocol harmony.

> statically configured, some communications should be allowed not to be

Possibly.  This may get a little tricky on how does the MR identifies
flows from MNN in order to separate them.

/rgds
/cwng

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 22 Jul 2008 09:32:54 +0200

Hi Chan Wah,

> then?  It is much safer, IMHO, to strictly insist on protocol harmony.

I'm looking at this requirement assuming that Des4 is also a required
characteristic. With this in mind, the MR has to decide (based on
operator/user configuration) which flows have to be route optimised.
Then it's very simple for the MR not to try to optimise those
communications (if any) that make use of protocols that are broken by
the NEMO RO solution. In this way, the MR would not break any
communication, just it would not be able to optimise some.

> flows from MNN in order to separate them.

Well, I think current devices (NATs, firewalls, etc.) deal with flow
identification quite well

Kind Regards,

Carlos