Subject: RE: [nemo] RE: Closing Issue 27

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Dec 2003 07:27:24 -0000

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: lundi 8 décembre 2003 19:30
> To: Pascal Thubert (pthubert)
> Cc: Jari Arkko; [email-masked]
> Subject: Re: [nemo] RE: Closing Issue 27
> 
> Pascal Thubert (pthubert) wrote:
> 
> > IPv6 Mobile Routers
> >
> >
> >    o  The router MUST comply with the MIPv6 requirements on all nodes and
> >       on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply with
> > 	section 8.2 as well.
> >
> > -> this is not said elsewhere in the spec. Do you think your new text covers it?
> 
> section 8.1 does not have any requirements. section 8.3 talks
> about requirements for all IPv6 routers. a mobile router is an
> IPv6 router.
> 
> draft-ietf-ipv6-node-requirements-06.txt says
> 
>     Routers SHOULD support the generic mobility-related requirements for
>     all IPv6 routers described in Section 8.3 of [MIPv6].
> 
> >
> >    o  The router MUST support at least one of the 2 modes, implicit or explicit prefix,
> >       for its Home registration as a mobile router. It SHOULD support both. It MAY support
> >       additional routing protocols over the MRHA tunnel.
> >
> > -> Chapter 5.2 is not clear on whether supporting only one mode is enough. At the WG, we
> said HAs MUST support both, but MRs need only support one.
> 
> we already discussed this.
> 
> section 5.2 says
> 
>     The Mobile Router uses
>     one of the following modes to instruct the Home Agent to determine
>     the prefixes owned by the Mobile Router.
> 

My point exactly. Obviously MR uses one method since that's all what's available, but this does not say whether a compliant MR MAY or SHOULD support both. I'm asking for a very limited change here, which removes the need for a list at the end (which is ugly :)

> section 6 says
> 
>     The
>     Home Agent MUST implement both modes described in Section 5.2 of this
>     document.
> 
> support for dynamic routing protocols is truly optional for both
> mobile router and Home Agent.
> 
> 
> look for reference [3] all over the text. the text says the reverse
> tunneling must be done using RFC 2473.

Again, do you think that mean full support of 2473? I mean, ICMP forwarding, PMTU etc... It does not take a lot of text to be very explicit. The current draft is not wrong, but it is very implicit.

> 
> >
> >    ?  The router MAY support receiving Mobile Prefix Advertisements
> >       (Section 11.4.3) and reconfiguring its home address based on the
> >       prefix information contained therein.
> >
> > -> in MIPv6 it's a MUST. For MRs, what we really need if DHCP PD that's not ready yet.
> 
> if the MR configures its home address from the home link (and not
> from MNP), prefix discovery is still needed. so it is a MUST so
> far.
> 

So either you say it MUST in a given case, which is more precise than my MAY, or you leave it to a MAY? Anyway I believe it is at least as important to have the prefix delegation (from which we can build a new Home address for the MR) that to have MPA. And we let the draft out with no PD support. So for me MPA falls into the same TBD in a following module. Maybe we will discover that MPA is not globally the best thing to do when you have PD and NAI, so MUSTing it now pains me.

> >
> >
> > Now let's look at 8.5.
> >
> >
> >    o  The node MUST maintain a Binding Update List (Section 11.1).
> >
> > -> useless for MRs. I suppose it's clear for you that this is a RO feature. Is it clear
> enough for all?
> 
> thats not correct. BUL is not an RO feature. it is needed for a
> mobile router because it sends binding updates to its Home Agent.
> 

That's not a List. It becomes a list when you start RO.

> > Conclusion: I'm afraid that your text is over simplifying
> 
> its exactly what is need without getting into a rut.
> 

it sure is an improvement anyway

> > Also remove MPA from the MUST
> 
> disagree.

Advice from the list, anybody?

> 
> > and let's push for the advancement of NAI and PD features for IPv6.
> 
> sure.
> 
:)

> >
> > We're still missing an RFC with the minimum reqs on IPv6 nodes.
> 
> it might be ready before the NEMO spec. its with the IESG now.
> look up the mobility section in the node requirements draft.
> 
> >
> > Note (as an answer for 28), that if the terminology becomes an RFC,
> > I do not mind referencing it and there's no need to copy text from
> > there (like we do not copy RFC 2461 text either) into our draft. But
> > we can only ref RFCs I guess.
> 
> a couple of clarifications. you can add an internet draft as an
> informational reference. you shouldnt put an internet draft in
> the normative section, unless that internet draft is also being
> advanced at the same time. but that may not an issue here because
> I was told that the terminology document is also being advanced
> to the IESG (though I dont know why there hasnt been a WG last
> call on it yet).
> 
> as for you comparison between RFC 2461 and terminology draft,
> there is a huge difference. :)
> 

:)

Pascal

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Dec 2003 11:22:25 -0800

> My point exactly. Obviously MR uses one method since that's all what's available, but this does not say whether a compliant MR MAY or SHOULD support both. I'm asking for a very limited change here,…

okay. made it more explicit.

    A Mobile Router MUST implement atleast one mode and MAY implement
    both modes.

> Again, do you think that mean full support of 2473? I mean, ICMP forwarding, PMTU etc... It does not take a lot of text to be very explicit. The current draft is not wrong, but it is very implicit.

this should be clarified in the IPv6 Node requirements doc. IMO,
RFC 2473 does not seem to have any optional sections. you have
to implement it entirely. (?)

> So either you say it MUST in a given case, which is more precise than 
> my MAY, or you leave it to a MAY? Anyway I believe it is at least as
> important to have the prefix delegation (from which we can build a new
> Home address for the MR) that to have MPA. And we let the draft out
> with no PD support. So for me MPA falls into the same TBD in a
> following module. Maybe we will discover that MPA is not globally the
> best thing to do when you have PD and NAI, so MUSTing it now pains me.

the way I see it, prefix discovery and prefix delegation for NEMO
do two different things. prefix discovery is about discovering
prefix information on the home link. prefix delegation is about
delegating prefixes for the mobile network. both are needed, IMO.

if it turns out that prefix discovery is not used, when DHCP prefix
delegation is deployed, then we can strip it out when NEMO basic
support moves from proposed standard to draft standard. (I am being
very optimistic :)

> That's not a List. It becomes a list when you start RO.

what about when the MR has more than one HA? it becomes a list?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Dec 2003 11:22:25 -0800

Vijay