Subject: [Mip4] Re: Comments on draft-ietf-nemo-v4-base-01.txt

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Jan 2007 17:09:23 +0100

Vijay, thanks for detail comments.  I responded one by one to the
different issues you raised, with proposed text.

Please let us know whether resolution is fine with you, whether not,
whether you'd like me to split every issue on a different mail, etc.

Vijay Devarapalli wrote:
> Hello,
> 
> Here are some comments on draft-ietf-nemo-v4-base-01.txt
> 
> Some high level comments
> 
> - The terms "subnet", "prefix" and "mobile network" are used 
> interchangeably in many places. Needs to be fixed throughout in the 
> document.

Ok, tried to substitute 'mobile network prefix' in several places where
'subnet' appears.

> - Support for mobile networks using the FA CoA mode is not explained 
> clearly.

Ok, trying to clear that.  The goal is to have as little as possible FA
talkin this document, ideally none at all.  There's another draft
looking about enhancing FA for moving network support.

The goal is also to have this draft work ok when 'legacy' FAs are present.

Would you agree with the generic idea to completely avoid FA text in
this 'base' draft?  It would involve removal of following text about:
(1) intermerdiary tunnel optimization (3) MR obtains a FA CoA (4) HA
replies back to FA (5) HA encapsulates to FA (6) MR routes packet to FA.

> - Running a dynamic routing protocol between the mobile router and 
> the home agent probably does not work when FA-CoA mode is used.

Ok, good to know.  Even more reason to reduce the FA talk in this document.

>> IPv4 Network Mobility (NEMO) Basic Support Protocol
> 
> Lets just call it "IPv4 Network Mobility (NEMO) Protocol". The Basic 
> Support was used for NEMOv6 since there was a plan to work on route 
> optimization for NEMOv6 and this was called Extended Support. Its not
> the same with MIPv4 and IPv4 NEMO.

I agree.  I've changed the title to "IPv4 Network Mobility (NEMO)
Protocol".  If anybody is against this change in title please say so.

Remark the Charter main nemo text doesn't use "basic support" but does
use "base protocol" in the timeline.  If we change the draft title then
the timeline should be updated too.

>> This document describes the support of Mobile Networks, as defined 
>> in Mobile IPv4, by the Mobile Router and Home Agent.
> 
> This statement is confusing. What does "as defined in Mobile IPv4" 
> mean? Perhaps rephrase to
> 
> This document describes a protocol for supporting Mobile Networks 
> between a Mobile Router and a Home Agent by extending the Mobile IPv4
>  protocol.

I agree it's less confusing, I've copypasted.

>> This document describes protocol extensions to Mobile IPv4 
>> ([RFC3344]) to enable support for Mobile Networks.  A Mobile 
>> Network is defined as a network segment or subnet that can change 
>> its point of attachment to the routing infrastructure.  Such 
>> movement is performed by a Mobile Router, which is the mobility 
>> entity that provides connectivity and reachability as well as 
>> session continuity for all the nodes in the Mobile Network.  The 
>> Mobile Router typically serves as the default gateway for the 
>> devices on the Mobile Network.
> 
> s/devices/hosts/

Done.

>> Mobility for the Mobile Network is supported by the Mobile Router 
>> registering the point of attachment to its Home Agent.  This 
>> signaling sets up the tunnel between the two entities.  The Mobile 
>> Networks (either implicitly configured on the Home Agent or 
>> explicitly identified by the Mobile Router) are advertised by the 
>> Home Agent for route propagation.  Traffic to and from nodes in the
>>  Mobile Network are tunneled by the Home Agent to the Mobile 
>> Router, and vice versa.  Though packets from the Mobile Network can
>>  be forwarded directly without tunneling when reverse tunneling is 
>> not enabled,
> 
> Not just "not enabled" but also "not used".

Ok.

>> reachability is still subject to ingress filtering conditions for 
>> the path in this case.
> 
> What reachability? I guess you want to say packets can be dropped if 
> ingress filtering is turned on.

Changed to:
> Though packets from the Mobile Network can be forwarded directly 
> without tunneling (if reverse tunneling is not used) packets will be 
> dropped if ingress filtering is turned on.

Ok that?

>> This document specifies an additional tunnel between Mobile 
>> Router's Home Address and the Home Agent.  This tunnel is 
>> encapsulated within the normal tunnel between the Care-of Address 
>> (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel between
>>  the Mobile Router and Home Agent is needed to allow the Foreign 
>> Agent to direct the decapsulated packet to the proper visiting 
>> Mobile Router.
> 
> Lets take an example.
> 
> IPv4 hdr (src=HA, dst=FA-CoA) IPv4 hdr (src=HA, dst=HoA) IPv4 hdr 
> (src=CN, dst=MNN) Payload
> 
> I borrowed the MNN terminology for NEMOv6 to indicate a host that is 
> attached to the mobile network. The above packet format is always 
> used for FA CoA mode, correct?

Yes, should be correct.

I think that additional tunnel for FA-CoA mode should be specified in
the FA NEMO draft.

>> However, in Collocated CoA mode, the additional tunnel is not 
>> essential and can be eliminated because the Mobile Router is the 
>> recipient of the encapsulated packets for the Mobile Network.
> 
> This would give us
> 
> IPv4 hdr (src=HA, dst=CoA) IPv4 hdr (src=CN, dst=MNN) Payload
> 
> This gives us a unique case of the packet overhead being the same for
>  the co-located CoA mode and the FA CoA mode. :)

Yes, I understand.  Looks strange to me too, but that's logical
conclusion - tunnel overhead same for CCoA and FACoA modes, for a MR,
not for a MH.

I agree to remove the MR-FA-CoA tunnel overhead optimization, if that's
what you suggest.  However, I find the idea of clearly showing what
encapsulated headers look like very appealing.  Do you want me to add that?

>> A similar protocol has been documented in [RFC3963] for supporting 
>> IPv6 moving networks with Mobile IPv6 extensions.
> 
> s/moving networks/mobile networks/

Ok in this rfc3963 phrase.

>> Although Mobile IPv4 stated that Mobile Network can be supported by
>>  the Mobile Router and Home Agent using static configuration or 
>> running a routing protocol, there is no solution for explicit 
>> registration of the Mobile Networks served by the Mobile Router.
> 
> Perhaps elaborate to say that there is no mechanism for the home 
> agent to know that the mobile router is authorized to send routing 
> updates for a particular mobile network prefix? Is this the intention
>  of the above sentence?

Yes, that's one intent.  Another is for network debugging purposes: one
would like to know looking at passing packets that a RegReq is for an
entire network, not only for one host.  One would like to see that
distinction in the Regitration Table too.

HEre's proposed text:
> Although Mobile IPv4 stated that Mobile Network can be supported by 
> the Mobile Router and Home Agent using static configuration or 
> running a routing protocol, there is no solution for explicit 
> registration of the Mobile Networks served by the Mobile Router.  A 
> solution needs to provide the Home Agent a means to ensure that a 
> Mobile Router claiming a certain Mobile Network Prefix is authorized 
> to do so.  A solution would also expose the Mobile Network Prefixes 
> (and potentially other subnet-relevant information) in the exchanged 
> messages, to aid in network debugging.

>> 4.2.  Mobile Network Acknowledgement Extension
>> 
>> The Registration Reply contains zero, one or several Mobile Network
>>  Acknowledgement extensions in addition to any other extensions 
>> defined by or in the context of ([RFC3344]).  For Implicit Mode, 
>> the Mobile Network Acknowledgement informs the Mobile Router the 
>> prefixes served by the Home Agent.
> 
> You mean owned by the Mobile Router? The Home Agent only sets up 
> forwarding for the mobile network prefix. Is this what you mean by 
> "served by the Home Agent"?

changed that too, look:
> The Registration Reply contains zero, one or several Mobile Network 
> Acknowledgement extensions in addition to any other extensions 
> defined by or in the context of ([RFC3344]).  For Implicit Mode, the 
> Mobile Network Acknowledgement informs the Mobile Router the prefixes
>  for which the Home Agent sets up forwarding with respect to this 
> Mobile Router. [...]

>> In accordance with this specification, a Mobile Router may operate 
>> in one of the following two modes: explicit and implicit.  In 
>> explicit mode, the Mobile Router includes Mobile Network Prefix 
>> information in all Registration Requests (as Mobile Network Request
>>  extensions), while in implicit mode it does not include this 
>> information in any Registration Request.  In this latter case, the 
>> Home Agent obtains the Mobile Network Prefixes by other means than 
>> Mobile IP.
> 
> Perhaps give one example, like configuration on the home agent.

What example would be more helpful to your reading?  Can I say that the
HA obtains the MR's routes from its routing table, from an ICMP Redirect
sent by the BR or from a static configuration file.  Or from all three.
   From another?

>> A Mobile Router can obtain a Collocated or Foreign Agent Care-of- 
>> Address while operating in explicit or implicit modes.
> 
> Whether the mobile router is using the explicit or implicit mode it 
> has no impact on FA or colocated CoA mode, right? Anyway re-phrase 
> the above sentence to
> 
> A Mobile Router MAY use either Co-located or Foreign Agent Care-of 
> Address while operating in explicit or implicit mode.

Ok.  If we get rid entirely of specifying FA behaviour then I'd be
completely silent about MR obtaining a FA CoA, would you agree to remove
the FA CoA obtention.

>> 1.  Check that the subnet information is valid
> 
> s/subnet/Mobile Network Prefix/

Ok.

> We have used mobile network prefix or just mobile network so far.
> 
>> 2.  Ensure such subnet is authorized to be on the Mobile Router
> 
> Same as above.

Ok.

>> 6.2.1.  Registration Table
>> 
>> The registration table in the Home Agent, in accordance with 
>> ([RFC3344]), contains binding information for every mobile node 
>> registered with it.
> 
> Mention that the Registration Table is already defined in RFC 3344.

Ok, now looks:
> The Registration Table in the Home Agent, in accordance with 
> [RFC3344], contains binding information for every Mobile Node 
> registered with it.  [RFC3344] defines the format of Registration 
> Table. [...]

>> If all checks are successful, the Home Agent either creates a new 
>> entry(ies) for the Mobile Router or updates an existing binding 
>> entry(ies) for it
> 
> Isn't there only one entry per Mobile Router?

If there are two egress interfaces and moving simultaneously then there
would be two HoAs, right?

> Are you considering multiple home addresses per mobile router?

Yes, one per interface.

> Anyway a registration request can only modify one binding cache entry
>  at a time. It cannot modify more than one, right?

Yes, because of that HoA.  So text became:
> If all checks are successful, the Home Agent either creates a new 
> entry for the Mobile Router or updates an existing binding entry for 
> it and returns a successful registration reply back to the Mobile 
> Router or the Foreign Agent (if the registration request was received
>  from a Foreign Agent).

>> 6.4.  Advertising Mobile Network Reachability
>> 
>> If the mobile network prefixes served by the Home Agent are 
>> aggregated with the home network prefix and if the Home Agent is 
>> the default router on the home network, the Home Agent does not 
>> have to do anything different than normal.
> 
> s/do anything different than normal/advertise the mobile network 
> prefixes.

Ok.

>> The routes for the mobile network prefix are automatically 
>> aggregated into the home network prefix.
> 
> Mention that it is assumed that the mobile network prefixes are 
> automatically aggregated under the home network prefix.

So text became:
> The routes for the Mobile Network Prefix are automatically aggregated
>  into the home network prefix (it is assumed that the Mobile Network 
> Prefixes are automatically aggregated into the home network prefix).

>> If the Mobile Router updates the mobile network prefix routes via a
>>  dynamic routing protocol, the Home Agent SHOULD propagate the 
>> routes on the appropriate networks.
> 
> This is the first mention of running a dynamic routing protocol 
> between the MR and the HA. Perhaps it should be described briefly 
> somewhere earlier on how to run a dynamic routing protocol between 
> the mobile router and the HA.

Not sure how to do that.  I mean if I want to do it completely I'd split
it from this document.  Not sure what kind of text would you like here.
   A new subsection earlier than this?  If I remove the mentioning of
dynamic routing protocol completely would it fit your reading?

Alex

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/