Subject: RE: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO?

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 6 May 2002 18:41:23 +0200

Late reply.

    Since any IPv6 node may at any time be a correspondent node of a
  >     mobile node, either sending a packet to a mobile node 
  > or receiving a
  >     packet from a mobile node, the following requirements 
  > apply to ALL
  >     IPv6 nodes (whether host or router, whether mobile or 
  > stationary):
  > 
  >      -  Every IPv6 node MUST be able to process a Home 
  > Address option
  >         received in any IPv6 packet.
  > 
  >      -  Every IPv6 node SHOULD be able to participate in a return
  >         routability procedure, process Binding Update 
  > messages, and to
  >         return a Binding Acknowledgement option if the 
  > Acknowledge (A)
  >         bit is set in the received Binding Update.
  > 
  >      -  Every IPv6 node SHOULD be able to maintain a 
  > Binding Cache of the
  >         bindings received in accepted Binding Updates.
  > 
  > Samita Chakrabarti comments on this: "IMHO, SHOULD is quite weak
  > statement. The whole point of doing route optimization is to save
  > round-trip time.  Now that we are solving the security 
  > issues, I think
  > route optimization is the feature that a CN (a CN could be 
  > a MN) must
  > implement. But obviously there SHOULD be a knob on MN side 
  > to turn it
  > off and on.
  > 
  > Without RO, the roundtrip time now is even longer through the
  > reverse tunnel. Route optimization should be "MUST" for CN, IMHO."

=> I was going to ask, why is this coming up now and 
was ok as a SHOULD before, then I saw the last line. 
IMHO, this is not a justification for mandating RO.
Yes reverse tunnelling through the HA would cause
additional RTT for CNs outside the MN's home 
network, but does it really make a difference 
when compared to triangular routing. At least
for most communication scenarios today I can't 
see any benefits (in terms of delays) for asymmetric 
triangular routing, compared to symmetric rectangular
routing. Would love to hear some explanation from someone
for why there is a significant difference. 

RO for all sounds nice, but I don't see why it is
more important now than before. 

  > Question: Is the text right? Should the keywords be MUST?

=> If it should be a MUST then I don't think it should be
done based on the text above, it would be good to know 
if there is anything new that would give a significant
reason for making it a MUST. 
Of course the WG can also just have a change of heart 
and thing that RO is important anyway and should have
always been a MUST. 

Hesham

---

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Tue, 7 May 2002 09:23:54 +0200

Hi Vijay,
> 
> hi Karen,
> 
> hope you dont mind me saying this.
> 

On the contrary, I really appreciate it - Thanks !

> "Karen E Nielsen (TED)" wrote:
> 
> > 
> > Does it really make sense to mandate (MUST) RO at CN's ?
> > Without specifying a certain minimum BC size, a MUST will 
> have no real effect, and do we
> > have a good idea about what this minimum size "MUST" be ?
> 
> This is a very unreasonable statement. 
> 
> Anyway, the MUST that is being discussed is for "MUST implement".
> It does not mean that the CN has to do RO all the time. 
> 
> The minimum size would depend on what the CN is. If it is a mobile
> node a few binding cache entries (for your satisfaction maybe 5).
> If it is a Yahoo server, maybe 1 million? :(
> 
> Specifying something like that is really a bad idea.

Couldn't agree more, that is why I thought that a "SHOULD" was better.
However, I understand from all you much more experienced people that "SHOULD" IS indeed a BAD idea.
and that "the MUST implement" is very important. 

I was thinking that mandating RO is really a lot to ask from all other Ipv6 nodes and that unless
they maintained a BC of a certain size we would not gain anything from it - but I now understand
that we really gain a lot from imposing the functionality as a standard Ipv6 functionality even if a sufficient
size of the BC is not always maintained.

Karen

(I am sending this to the list - hope that's OK)

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 21 May 2002 15:14:48 -0700 (PDT)

> for why there is a significant difference. 

BTW, I was comparing RTT of using reverse tunnel vs. route optimization,
in case it was not clear.

> more important now than before. 

Actually, we are trying to decide on two things. I have discussed
this with Jari and Erik. Previously, there was no clarification on the draft
that all CNs supporting MIPv6 draft MUST support route optimization. I think,
this is quite natural conclusion, otherwise, there is no meaning of 
providing MIPv6 correspondent node functionality in the base draft.

So, I was requesting that there should be a section on "Correspondent Node
Behaviour" in the next revision of the draft, which clarifies the
RR procedure and binding update requirement for all correspondent nodes
supporting MIPv6 base draft.

The second thing is whether all ipv6 nodes SHOULD/MUST support the 
'Correspondent node behavior' defined MIPv6 draft.

> and thing that RO is important anyway and should have

In future, if we believe all mobile nodes will run IPv6 and use MIPv6
as the mobility protocol, then it makes much sense to make MIPv6
CN functionality mandatory for all ipv6 nodes.

If we define the requirement in mobileip and ipng working group,
then that requirement can be used for IPv6 node requirements as well.

-Samita