Subject: [nemo] Comments on ORC draft-wakikawa-nemo-orc-00.txt

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Aug 2004 15:29:58 +0200

Hello to authors of draft-wakikawa-nemo-orc-00.txt Ryuji and Watari :-)

I've read the draft and have comments of two kinds: editorial and on the
architecture, at the end.

Overall, I think the draft describes a method for offering approximate
RO for mobile hosts and mobile routers by placing new architectural
entities supporting ORC in the Internet. (like MBone routers do
bandwidth savings). The method relieves CN's from implementing any new
NEMO RO protocol, thus a great advantage. It also offers a means to
automatically discover the presence of CR's, which is also advantageous:
ORC BU's can be triggered only when CR's are present near CN.

One drawback seems to be the fact that even if shorter paths are
employed through CR, there's still encapsulation (if my reading is
correct); but this may probably be improved.

The editorials I'm mentioning below may confuse the reader easily.  They
reflect the interpretation I give to some aspects, which may be not the
right one, please enlighten if so.  (and there are others on grammar but
they're obvious so I don't mention.)

> The ORC aims to manage binding information as if routing information 
> of each mobile network are located at special routers called 
> ``Correspondent Router''.

Substitute "for when" for "as if".

> best effect routing protocol

Effort.

(actually, I don't think it is very precise to say that some routing
protocol is "best effort"; I guess one can say that IP routing in itself
happens in a best effort manner, in that nothing guarantees delivery of
fwded packets to the final destination - there's no ack. I think
routing protocols do have some means of acknowledging their exchanges
(e.g. BGP uses TCP), and in this sense they can't be qualified as best
effort. It is also true that a path taken by packets to a certain
destination is not necessarily the shortest possible, because of load
balancing and other traficcy shaping if I can say so, in which case I
think it's called simply "optimal", and this may better fit in your
context where paths are shorter if an ORC router is present and longer
otherwise.  Closed parenthesis.)

> Mobile router can forward any packets meant for the managed prefixes 
> to the correspondent router.

"forward" ok yes, but maybe stress with "directly, instead of forwarding
to its HA"; and stress that MR actually encapsulates, not quite simple
forwarding.

> The managed prefix is used when the mobile router decides which 
> packets are sent to which correspondent router.  The Home Agent setup
>  forwarding for all the mobile network prefixes notified by the 
> mobile router.

It is true that HA sets up fwding for all Mobile Network prefixes
notified by the MR, but in this section we're talking about Binding
Registration (btw, why not simply BU?) to the CR, not to the HA.  So I
assume it's the CR you're talking about in the last phrase above (not
the HA), right?

> next hope address

Hoping the next hop forwards where it should :-)

Other than editorial remarks:

After reading, may I conclude that there's always encapsulation between
MR and CR?  So this is a sort of RO but without the benefit of not
having to encapsulate?  Section 2.2.2 RR invited to think it may lead to
remove the encapsulation after RR, but it never says so.  How is it
intended?

About path length.

After reading, it is clear that ORC provides for shorter-than-through-HA
paths between MR and CN provided a CR is close to CN.

But the description gives no clue about what happens when MR and its HA
are both in the CN-and-CR's domain.  In this case, it may happen that
the path MR-HA-CN is much shorter than MR-CR-CN.  So it would be
interesting to consider a sort of intelligence on MR about what to do
with the discovered CR's address, maybe don't always use it.

Additionally, in the case that MR has its home in the same AS as the CN
and talks to CN, there is little chance for CR to "intercept" these
packets, unless CR is in the path MR-CN (should it be there?).

About where to put the CR.

There is a sort of contradictory assumption about the placement of CR.
Initially, it is said that a CR should be "scattered near the transit
AS", a bit later it is said that CR is an "edge router" and could even
be a "gateway" router for a network, in order to intercept packets of
CN.  I assume the intention of "gateway" was to say "CN's next-hop
router to the Internet".  If it is so, then those two claims practically
bring the CN near the "transit AS".  I think this is difficult to
assume, since most CN's (in the form of e2e communicators), are usually
at the far edges.

Of course, there exist large web/ASP server farms placed somehow nearer
the "transit AS", but I think they're the rare exceptions.

I think it should be better clarified where exactly the CR's should be
placed, and this should be suggested with respect to existing OSPF and
BGP terminology (like AS, area, backbone, routing domains,  border
router, backbone router, AS boundary router, etc.  For more fun, an OSPF
"edge" is actually any link between two routers, not the "edge of the
Internet" as we often talk about :-)

About CR receiving identical routes towards mobile prefix, from ORC and EGP.

It is good to say that the route a CR learns from a remote MR (the
mobile network prefix) could be advertised by CR via an IGP in the same
domain, but not via BGP.  Moreover, one should say what happens when CR
receives a route towards exactly same prefix, by EGP and by ORC
simultaneously.  Which would take precedence?

About CR Discovery.

It is commonly acknowledged that DHAAD is not hyper secure in the MIP6
world, and since CR Discovery is similar to MIP6 one immediately thinks
about the more risks CRD involves, so how do you secure it?

> The mobile router learns the correspondent router anycast address 
> from the correspondent node's prefix and the anycast identification.

This and other places make the assumption that CN's prefix and CR's
prefix match on the first 64 bits.  This is also something used in "home
network models".  I think this is a very particular case, especially
when CR is placed nearer to the centre than to the leaves... Just a thought.

About ORC RO in nested aggregations of moving networks.

The method with "reflective BU's" seem to make sense but immediately two
questions come to mind.  It is said that sub-MR learns root-MR's CoA
from the RA's send by the latter to the former.  But what about
sub-sub-MR's?  Does the sub-MR re-transmit the root-MR's CoA it
receives, or does is it just transmitting its own CoA?  How does an MR
_know_ of being a root-MR in fact?

> The correspondent router then sends a binding update message to the 
> root-MR for the network claimed by the correspondent router.

Ok, so root-MR has some sort of a binding cache, right?  This looks new?

That's about my remarks, I know it's lengthy, but I find it to be a good
reading of an interesting method.  Thanks for all replies.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 4 Aug 2004 01:38:11 +0900

Hello Alex.

Thanks for detailed comments to this draft.

> correct); but this may probably be improved.

Yes. We use tunnel between MR and CR.
One thing we tried to avoid is that MR modifies original packets sent 
by MNN by adding RTHDR, etc.
Tunneling is simple way to route packets to CR without changing 
original packets.

> otherwise.  Closed parenthesis.)

One goal of ORC is bypassing HA on the way to HA.
Except for bypassing HA, packets are routed based on existing routing 
mechanism.

> to its HA"; and stress that MR actually encapsulates, not quite simple

I am not sure I get your point here, but MR basically encapsulates 
packets to HA all the time.
Only the difference is the destination of outer IP packet (either HA or 
CR).

> assume it's the CR you're talking about in the last phrase above (not
Yes,  right.
I will correct this in the next version.

> remove the encapsulation after RR, but it never says so.  How is it

RR is just used as security mechanism.
We also say IPsec can be used as a security mechanism.
MR must handle packets which are not originated by MR.
MR should not modify original packets (adding IP options at MR).
That's why we simply say using tunnel.

> paths between MR and CN provided a CR is close to CN.
yes

> with the discovered CR's address, maybe don't always use it.

Good point. However I think ORC already have two mechanisms for this.

When MR operates CR discovery, it will know
whether CR is located in the same network of MR or HA.

Another operation is that MR can know that CR is in same domain
by checking managed prefix acquired from Binding Ack.
If managed prefix is same as MR belonging network,
MR may not use CR (de-registration).

Anyway, this is important issue. I will update this in the next version.

> packets, unless CR is in the path MR-CN (should it be there?).

Right.

> about the more risks CRD involves, so how do you secure it?

True. Anycast address can not be used with IPsec.

> when CR is placed nearer to the centre than to the leaves... Just a 

Yes, As pascal pointed out, assuming 64/ is not good idea.

I will reply to the rest of your mail by separate mail.

Thanks again.
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2004 15:52:36 +0200

> Only the difference is the destination of outer IP packet (either HA or 

Ok.  It is not very important.  (using the word "forward" leaves place 
to misinterpretaion when tunnelling).

> whether CR is located in the same network of MR or HA.

How?  Also by assuming always 64-bit prefix length?

> True. Anycast address can not be used with IPsec.

Maybe msec has something to help mip6 to help orc here?

Alex

---

From: Masafumi Watari <[email-masked]>
Date: Wed, 11 Aug 2004 12:10:10 +0900 (JST)

Hello Alex,

On Mon, 02 Aug 2004 15:29:58 +0200,

> > best effect routing protocol

Right...

> otherwise.  Closed parenthesis.)

Yes, I think I understand what you mean.  
We can rephrase the word.

> _know_ of being a root-MR in fact?

I didn't mention explicitly in the draft, but the sub-MRs should learn
the CoA of the MR which it is attached to.  By each MR doing the same
operation, the CR and the MRs will eventually have all the bindings
for the MNN.  For the MR knowing whether being the root or not can be
achieved with the tree discovery.

> Ok, so root-MR has some sort of a binding cache, right?  This looks new?

Yes. I'm hoping it would give a new thoughts.  The good thing about
this is that it does not require location management of the sub-MRs at
the root-MR.

Masafumi Watari

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Aug 2004 17:26:10 +0200

Masafumi Watari wrote:
>> The method with "reflective BU's" seem to make sense but
>> immediately two questions come to mind.  It is said that sub-MR
>> learns root-MR's CoA from the RA's send by the latter to the
>> former.  But what about sub-sub-MR's?  Does the sub-MR re-transmit
>> the root-MR's CoA it receives, or does is it just transmitting its
>> own CoA?  How does an MR _know_ of being a root-MR in fact?
> 
> I didn't mention explicitly in the draft, but the sub-MRs should
> learn the CoA of the MR which it is attached to.  By each MR doing
> the same operation, the CR and the MRs will eventually have all the
> bindings for the MNN.

I want to be sure the following is avoided.

Assume a 3-level nested MR's and LFN deepest.  LFN and its immediately
above MR's would make CR believe what you say and route-optimize.  But
all communication would goes through TLMR's HA.

>>> The correspondent router then sends a binding update message to
>>> the root-MR for the network claimed by the correspondent router.
>> 
> this is that it does not require location management of the sub-MRs
> at the root-MR.

CR sending BU's is just like CR being actually an MR, no?

What is "location management"?

Alex

---

From: Masafumi Watari <[email-masked]>
Date: Thu, 12 Aug 2004 12:33:25 +0900 (JST)

Hello,

On Wed, 11 Aug 2004 17:26:10 +0200,

> all communication would goes through TLMR's HA.

Yes, this is avoided.  It may go throught the root-MR's HA for a
while, but eventually CR would have the binding for the sub-MR.  I can
be more clear on this, but since the ORC is focused on the notion of
the CR, we may separte this part on the next version of our draft.

> CR sending BU's is just like CR being actually an MR, no?

Yes, correct, which allows route optimization between two distinct
nests.

> What is "location management"?

I was refering to the case where management of some sort of status is
required at MRs for the sub-MRs attached behind it.  For some reason I
thought it was well known term.  Sorry.

Regards,

Masafumi Watari