Subject: RE: [nemo] review of draft-ietf-nemo-home-network-models-04.txt

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 28 Sep 2005 07:59:13 +0200

The way I understand it, we should not be specifying a behavior in this
document, which is oriented on deployment; and you know that the SHOULD
in the copied text is not really part of RFC 3963. 

There might be a need of some standard track work on the matter of
virtual home for NEMO and MIP. Maybe associated to the HAHA protocol,
which is needed for multiple HAs sharing a virtual Home.

Do I miss something?

Pascal

>-----Original Message-----
>From: Vijay Devarapalli [mailto:[email-masked]]
>Sent: Tuesday, September 27, 2005 8:21 PM
>To: Pascal Thubert (pthubert)
>Cc: Jari Arkko; IETF NEMO WG
>Subject: Re: [nemo] review of
draft-ietf-nemo-home-network-models-04.txt
>
>[email-masked] wrote:
>> Hi Jari:
>>
>> Thanks a bunch for all this. Please find some proposal changes
inline.
>> Actually, all interested in the draft are welcome to enter this
>> discussion, as it might be the last chance before publication...
>>
>>
>>>>What troubled me perhaps most was that the
>>>>document suggests a mechanism to emulate returning
>>>>home when a virtual home link implementation is
>>>>being used at the home agent. I'm not convinced that this
>>>>is necessary, and if it is, this is probably something that should
>>>>be done for Mobile IPv6 and not just nemo. Getting rid of this
>>>>part of the document would also remove one normative behaviour
>>>>requirement (which currently does not feel appropriate in
>>>>an informational document such as this one).
>>>
>>>there is a problem when there is a virtual home link and a
>>>mobile router returns home. where does it connect to? does
>>>it de-register? does it start sending routing protocol
>>>updates in case it is capable of sending routing updates?
>>>the last question especially is very important and is
>>>specific only to NEMO.
>>>
>>>the text we currently have is to address the above questions.
>>>even for MIPv6, we need to address returning home in case
>>>the home link is a virtual link, but the problem is not the
>>>same. there are no routing updates from the mobile node that
>>>could screw up route aggregation on the home network. also
>>>for some reason the thinking was that in MIPv6 if the home
>>>link is virtual the MN never goes home. the same may not be
>>>true for mobile networks.
>>
>> [<PT>]
>> [<PT>] I understand that Jari suggests removing that piece of text;
>> or maybe changing it to fit an informational document.
>>
>> Current text:
>>
>>    In order for a Mobile Router to emulate returning Home, it can
>>    connect to one or more access link(s) configured for that purpose
on
>>    the Home Agent.  The Mobile Router, after connecting to the access
>>    link, SHOULD not send any routing protocol updates on the egress
>>    interface because the routing information from the Mobile Router
>>    might adversely affect IPv6 route aggregation on the Home Network.
>>    However, the Mobile Router must register its binding as if it was
>>    accessing a foreign link.
>>
>> Proposed fix:
>>
>>    RFC 3775 and 3963 do not provide the specific support for a
>>    Mobile Node to emulate returning Home on a Virtual Home Network.
>>    In particular, in the case of NEMO, the routing information from
>>    the Mobile Router being injected on the IGP might adversely affect
>>    IPv6 route aggregation on the Home Network.
>
>but why? informational documents can describe some behavior
>for the mobile router. I dont understand the part about
>not fitting an informational document.
>
>Vijay

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Sep 2005 16:41:45 +0300

Hi Pascal and Vijay,

Its indeed possible to have some informational documents
that define protocol extensions or behaviour. Of course, if
we believe a particular function is generally useful its most often
targeted as a proposed standard. But we don't have
a theoretical reason why we couldn't have the
extension in this doc. However, my opinion that we
should pursue the behaviour in a separate document
was based on two things:

- The nature of the document is really about
  explaining how you can use NEMO, and what
  different network setups make sense. This
  may not fit detail-level protocol behaviour
  recommendations.

  Even the name is such that you don't expect
  to find new functional extensions in it.

- Gut feeling that we need more review & wider
  discussion about the extension.

--Jari