Subject: [nemo] Closing Issue 27

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 05 Dec 2003 10:05:11 -0800

Jari, Pascal,

issue 27 is about clarifying MR requirements with respect to MIPv6.

add the following to section 5

    A Mobile Router MUST implement all requirements for IPv6 Mobile
    Nodes, Section 8.5 in [1].  However if a Mobile Router is not
    expected to initiate sessions of its own and behaves purely as a
    router serving the Mobile Network most of the time, then the Route
    Optimization functionality MAY be implemented.

comments, text suggestions welcome.

Vijay

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Dec 2003 09:11:22 -0000

Hi Vijay:

If you come back to my 'ugly' list and see what I think may not be covered by the proposed text:

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?

   o  The router MUST support establishing and tearing down a bidirectional 
      tunnel to its Home Agent and a default route over that tunnel. 
      It MUST support forwarding packets between that tunnel and the Mobile Networks. 

-> I believe that one is natural with the spec, and can be omitted 

   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.

   o  The router MUST fully support [RFC2473]. As such, it MUST be able to 
      perform IPv6 encapsulation and decapsulation, ICMP forwarding and PMTU
      discovery.

-> This comes with the support of 2473. Can we assume all MRs MUST do 2473 without a word about it?

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

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?

   o  The node MUST support movement detection, care-of address
      formation, and returning home (Section 11.5).

-> MRs support this only on egress interfaces, when they act as nodes (:meaning hosts:). This is lissing frm the new text. Again, people with a good understanding of the spec would agree it's implicit.

Conclusion: I'm afraid that your text is over simplifying (or over implicit) though I agree with the concept, and I agree that most people with a good understanding of the spirit of the spec would do OK implementing it.

What I suggest: 

A bit more about what's removed from the MUST MN. In particular list what's related to RO from 8.5 and becomes a MAY. Also remove MPA from the MUST, and let's push for the advancement of NAI and PD features for IPv6. 

We need some text somewhere to list RFCs that are implicitly supported. We're still missing an RFC with the minimum reqs on IPv6 nodes. So we need to do it ourselves, same problem as the terminology I think.

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.

Pascal

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: vendredi 5 décembre 2003 19:05
> To: Jari Arkko; Pascal Thubert (pthubert)
> Cc: [email-masked]
> Subject: Closing Issue 27
> 
> Jari, Pascal,
>

---

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

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

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

> 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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Dec 2003 08:38:09 -0000

> 
> 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. (?)
> 
> 
I suppose so too. I agree it's better if we are able to dereference the
node reqs.

> >>>-> useless for MRs. I suppose it's clear for you that this is a RO
feature. Is it clear
> >>enough for all?
> what about when the MR has more than one HA? it becomes a list?
> 
I thought my point was clear... I try otherwise. Minimum basic Nemo MR
does not need a list. So you can not MUST it. A basic nemo MR SHOULD
support DHAAD, so I guess that implicitly it SHOULD be able to store a
list of HAs. But only one needs to be active at a given point of time.
Only one active binding is needed. There no need to support a list.

Note that in the spirit (unless I'm wrong) the list is about the various
bindings for a given CareOf, and if a MR was to support multiple
registrations, I guess it would naturally maintain multiple lists. But
this is implementation...

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Dec 2003 15:08:36 -0000

> 
> o I agree with Vijay that BUL needs to be a list, if not
>    for multiple registrations per home address, at least for
>    the possibility of multiple home addresses / home agents.
> 
I see confusion between HAs and bindings. With basic Nemo, a MR needs to
maintain one active binding. Nothing more is required. Even though a MR
maintains a list of HA. Different objects. 

More than one active binding is multihoming which is clearly out of
scope. The spec does not prevent it but it must not MUST it...

Anyway, we lost too much time on this. It's impossible to see from the
outside if an implementation that supports only one active binding has a
list or not.

> 
> o I do not think you should spend too much effort on
>    optimizing the parts of MIPv6 that you need or do not
>    need. Remember that CN side RO is already a SHOULD
>    in the IPv6 node requirements.
> 

Agreed.
 
Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Dec 2003 15:08:36 -0000

Agreed.
 
Pascal