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

[[e-mail]]

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.


>
>> Technical:
>>
>>>    In implicit mode, the Home Agent has the necessary information to
>>>    continue routing to the MNPs in the absence of registration, and
the
>>>    participation of the Mobile Router to the Home IGP is not
required.
>>
>>
>> This may be a lack of understanding of RFC 3963 on my part, but
>> how does this actually work? Is the traffic to the MR routed through
>> home agent in all cases even when there's no registration?
>
>for implicit mode, it is assumed the routes for MNPs exist
>all the time. but the forwarding entry would point to a
>virtual tunnel interface that wouldnt exist if the mobile
>router does not have a valid binding cache entry at the HA.
>
>in practice, the routes dont have to exist. there could be
>some state on the HA which says, if the MR sends a binding
>update in the implicit sate, create routes for these MNPs,
>don't look for MNPs in the binding update. this is
>implementation dependent.
>
[<PT>] How do we translate that into a fix in the text? 

When read separately, the text is misleading and seems to say that
there's some magic that allows the HA to route to MR at all times.

In context (returning Home in extended mode) the text makes more sense
hopefully.

Current text:

   In implicit mode, the Home Agent has the necessary information to
   continue routing to the MNPs in the absence of registration, and the
   participation of the Mobile Router to the Home IGP is not required.

Proposed fix:

   In implicit mode, the Home Agent has the necessary information to
   continue routing to the MNPs in the absence of registration, 
   assuming that the Mobile Router is at Home,  and the
   participation of the Mobile Router to the Home IGP is not required.


>>>    When connecting to the Home Link, the Mobile Router also need to
>>>    autoconfigure an address on the egress interface as opposed to
>>>    assigning its Home Address to the interface.
>>
>>
>> And how does this work wrt. routing of the actual data packets?
>> Does this mean that the MR needs perform a registration to its
>> home agent, even if its on the home link?
>
>this text is only specific to the case where the home address
>of the MR is configured from the MNP. if the MR is capable of
>sending routing protocol updates, it just sends an update for
>the MNP. another option is to send an ICMP redirect for the MNP.
>the MR shouldn't register with the home agent.

[<PT>] Note: The HA being a router, it might not process the redirect,
though.
 
But yes, again the excerpt needs to be read in context. As Vijay says,
the MNP is a different /64 then the prefix on the Home Link. The HA owns
the aggregation (say /48) and has more specific routes (one /64
connected to the Home link acting as a RFC 3775 home prefix, and other
/64 used as MNPs attached to the ingress of the MRs).

If the MR takes its Home Address from the /64 on the Home Link, all is
very classical. But if it wishes to take its Home Address from the MNP,
then the Home Address is not located ion the Home Link.

The HA itself does not have route to the /48, but acts as an ABR to
aggregate the /64s into that /48 and call the result Home. Instead, the
HA has /64 routes (to MNPs) via the CareOf address of the MR (for which
it has a connected /64 so the route lookup ends up there).

This is the whole purpose of extended Home Network. I do not have a
simple fix to propose to make it clearer. If you still think a change is
required, can you please be more specific?



>>> 5.5  Applicability
>>>    ...
>>>
>>>    Also, when the Home Address is derived from the prefix on the
Home
>>>    Link, the Home Agent behavior on the link trivially extends that
of
>>>    MIP and the support should for that configuration should be
available
>>>    with all implementations.
>>
>>
>> But Section 5 appeared to be talking also about the case
>> when the MR's home address is not derived from the home
>> link prefix.
>
>right. thats why we have the following text in section 5.3
>
>    For all these reasons, this submode of extended is no more a
trivial
>    extension to the MIPv6 Home Model, and it might not be compatible
>    with all implementations.
>
>configuring a home address from the home prefix is the default
>mechanism. configuring from the MNP may not work all the time.
>
[<PT>] 
[<PT>] Do we need to add a last sentence in 5.5 to say that? 

>>>    Alternatively, the Mobile Router might perform ND proxying for
all
>>>    addresses in its MNPs, between the egress and the related ingress
>>>    interface.  Since the prefixes on the egress and ingress
interfaces
>>>    are overlapping, routing is disallowed.
>>
>>
>> Reference to the ND proxy spec is appropriate here. But that
>> is experimental (and under discussion) -- is ND proxying what
>> we really want to do here?
>
>RFC 2461 allows a router to proxy for a host, right? that
>should be sufficient. I dont think we are talking about the
>ND proxying draft currently being discussed in the IPv6 WG.
>Pascal, Ryuji, correct me if I am wrong.
>
[<PT>] There might be related issues, like MTU being different, even
though there's no tunneling. I believe it's OK to add the non normative
reference to draft-ietf-ipv6-ndproxy-03.txt?
Consider this picture from Dave's draft,  and say that "the rest of the
network" is the Home Link, "local hosts" are lfns and A is our MR. Isn't
this our config should the MR return Home over 802.11?

         |         +-------+           +--------+
   local |Ethernet |       | Wireless  | Access |
         +---------+   A   +-)))   (((-+        +--> rest of network
   hosts |         |       |   link    | Point  |
         |         +-------+           +--------+

For the latter question, if the 2 interfaces are compatible, then the MR
could bridge. It might be more of a problem if they are different (like
one is PPP, between an embedded MR and a single device). But what else
could we do? The router sees overlapping prefixes (and connected routes)
on its interfaces and that's not a valid condition at L3.

>>>                     /48                       eg: A:B:C::/48
>>>                     HA
>>>                     | /64                         A:C:C:E::/64
>>>          --+-----+--+- . -+- . -+--
>>>            |     |        |     |
>>>            MR1   MR2      MRi   MRN
>>>            /64   /64      /64   /64            A:B:C:i::/64  0 < i
<= N
>>>
>>>
>>>
>>>                       Figure 5: Virtual Home Network
>>
>>
>> Is A:C:C:E::/64 correct? I would have assumed A:B:C:0::/64...
>
>I think so...
[<PT>] Well, the text says that 
   The Extended Home Network and the Aggregated Home Network models can
   be adapted for virtual links.

So both A:B:C::/64 (extended) or A:B:C::/48 (aggregated) could have
worked too. Since there's no need to waste any prefix, we left the whole
range of the /48 to MNP, as an alternate to the other 2 cases.

>
>>
>>>    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. ...
>>>    However, the Mobile Router must register its binding as if it was
>>>    accessing a foreign link.
>>
>>
>> I suspect this is the same as saying "in order to emulate returning
>> home link, the MR can connect to some other link and behave as
>> if it was accessing a foreign link" :-) Or am I missing something?
>>
>> Suggest deleting or reformulating paragraph. Its clear that we can
set up
>> networks and links close to the home agent, but in a virtual
>> network you don't return home, even if home might be just one
>> router hop away.
>>
>> I would also suggest deleting appendix A.
>
>well, we need to say something about returning home and virtual
>home links. the alternative is to say, returning home for
>virtual home links is not supported.

[<PT>] This refers back to the first and main comment on the draft. The
proposed change is actually to recognize that with the current
standards, it's not supported. Does everyone agree?

Does everyone agree that I remove appendix A? It's always a pain to
remove text but sometime we have to admit that it's either too early or
in the wrong doc and act on it.

>
>>
>>>       There can be only one Home Agent since Mobile IPv6 relies on
>>>       Neighbor Discovery on the Home Link for other Home Agent
discovery
>>>       and for Duplicate Address Detection.
>>
>>
>> As I have understood the Mobile IPv6 base requirements, there's
>> no mandate that you have to do home agent discovery only that way -
>> you could also configure things. And in theory you could construct
>> virtual links even across multiple home agents (such as via private
>> tunnels) but this would void the primary benefits of the virtual
>> approach i.e. ability to ignore what other nodes on the link are
>> doing. Suggested reformulation:
>>
>>  As there is no physical link, this also implies that there can
>>  only be a single home agent per home prefix; multiple home
>>  agents would not be able to communicate with each other.
>
>ok.
>
[<PT>] Great, Thanks :)

>>
>>> 7.2  Applicability
>>>
>>>    At some point in the future, NEMO basic support may be extended
to
>>>    operate fully at L3 for instance if the HAHA protocol [11] gets
>>>    standardized and deployed.  Until then, NEMO operations still
inherit
>>>    from mobile IPv6 [7] for the Home Agent to Home Agent
communication,
>>>    which is basically based on Neighbor Discovery extensions over
the
>>>    Home Link.  Making that link virtual bars the deployment of
multiple
>>>    Home Agents, which may be desirable for reasons of load
balancing.
>>>    Please refer to the NEMO multihoming issues [12] draft for more
on
>>>    this.
>>
>>
>> I'm not sure its useful to speculate about this. Also, this text
>> appears to be saying that Neighbor Discovery is not at L3.
>> Pointing to NEMO multihoming draft is good, though.
>
>you are right. should be re-written.

[<PT>] Note that the NEMO RO PS also details some related issues.
[<PT>] Proposed change is to remove the first sentence, with the same
rationale as appendix A...

    NEMO operations still inherit from mobile IPv6 [7] for the Home
Agent to 
    Home Agent communication, which is based on Neighbor Discovery
extension
    over the Home Link.  Making that link virtual bars the deployment of
multiple
    Home Agents, which may be desirable for reasons of load balancing.
    Please refer to the NEMO multihoming issues [12] draft for more on
    this.

>
>>
>>>    Alternatively, the
>>>    Home Agent may indicate that the Mobile Router has moved to the
>>>    virtual Home Access Links as a status code in the binding
>>>    acknowledgement.  The status code implies that Home Agent
successsful
>>>    de-register the binding at the virtual Home Access Link.
>>
>>
>> Which status code would this be? Neither RFC 3775 or 3963 appear to
>> define a code for this particular purpose.
>
>looks like we need a new status code. :)
[<PT>] For the future :) But for this doc, we need to drop this text
together with the support of coming home on a virtual home. 

[<PT>] What do you think?


 
Pascal