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

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 22 Feb 2007 12:13:01 -0800

Hi Alex,

I somehow missed replying to this email. Sorry about that.

Alexandru Petrescu wrote:
>> - 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.

You could say, that the current draft addresses only
co-located CoA mode. FA CoA mode is addressed in a separate
document. As far as this draft is concerned, the mobile
router could ignore the FA on the access link, perform DHCP
for address configuration and send a registration request
to the HA directly.

>>> 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.

That milestone item needs to be update anyway.

Sep 2007	  	Base MIPv4 Mobile Network Support (Draft Std.) to IESG

It talks about Draft Standard. It should have said "Proposed
Standard". :)

>>> 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.

Ok

>>> 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?

Sure. But since the FA CoA mode is going to be described
in a separate document, do we need to?

>>> 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. [...]

Looks good.

>>> 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?

Perhaps mention just static configuration on the home agent
for the implicit mode as an example. Other means are ofcourse
possible.

>>> 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.

Ok.

>>> 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).

Ok.

>>> 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?

If you want to run a routing protocol over the tunnel between
the Mobile Router and the Home Agent, it might be better if
there is a separate section on it. Similar to what we did in
RFC 3963.

Vijay

-- 
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/

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Feb 2007 14:27:10 +0100

Vijay, I've submitted draft-ietf-mip4-nemo-v4-base-00.txt.  It will show 
up soon on the I-D directory and hopefully on this mMIP4 mailing list.

It's now nameed according to the MIP4 WG, no longer NEMO WG.

Please check I've addressed correctly all your comments.  There's 
changelog.  The draft was reduced from 16 pages to 15.

Please feed back.

MIP4 members: please feedback on this draft, thank you,

Alex

Vijay Devarapalli wrote:
>>> - 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.
>> 
>> 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.
> 
> You could say, that the current draft addresses only co-located CoA
> mode. FA CoA mode is addressed in a separate document.

Done, right up in the Introduction.

> As far as this draft is concerned, the mobile router could ignore the
> FA on the access link, perform DHCP for address configuration and
> send a registration request to the HA directly.

Todo.

>>> 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.
>> 
>> 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.
> 

Right.

>> 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?
> 
> Sure. But since the FA CoA mode is going to be described in a
> separate document, do we need to?

No.

>>>> 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.
>>> 
>> 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?
> 
> Perhaps mention just static configuration on the home agent for the
> implicit mode as an example. Other means are ofcourse possible.

Done, 1 phrase.

>>>> 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.
>>> 
>>>  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?
> 
> If you want to run a routing protocol over the tunnel between the
> Mobile Router and the Home Agent, it might be better if there is a
> separate section on it. Similar to what we did in RFC 3963.

Do you want to write it?  I want to keep the number of authors limited 
to the usual limit.  Let's talk to group and co-authors as well about 
this option.  The draft was reduced by 1 page (from 16 to 15 pages).

Alex