Subject: Re: [MEXT] Next steps on prefix delegation

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 26 Nov 2007 11:34:26 -0800 (PST)

Hi Ryuji,
  DHCP PD does not require DHCP functionality at the MR. HA can get a prefix for MR even if MR boots up in foreign network.

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: RYUJI WAKIKAWA <[email-masked]>
Cc: [email-masked]
Sent: Monday, November 26, 2007 12:22:41 PM
Subject: Re: [MEXT] Next steps on prefix delegation

Hello Ryuji,

I'd still like the questions I've asked to be answered, but anyway: 

<chair hat off>:

On Monday 26 November 2007, RYUJI WAKIKAWA wrote:
> Hi Julien and all,
>
> Agree that solo solution is always better, but I support both
> solutions for MNP delegation.
>
> DHCP PD is simple solution, but it requires DHCP functionalities at
> HA and MR.
> DHDP PD seems practical when MR boots up in home network. 
> However, when MR boots up in foreign network, MR must creates a
> tunnel to send any DHCP messages.
> It means it takes several message exchanges between MR and HA to get
> MNP in bootstrap.

Since booting a node typically consumes quite some time it seems the 
delay incurred by an additional message exchange could be considered as
 
neglogible.

> PMIP uses similar way of NEMO PD to assign prefix to MN during
> binding registration.

This discussion is about NEMO prefix delegation; AFAICT PMIP doesn't 
require *delegation* of prefixes, thus it is not a good comparison 
w.r.t. this discussion.

> If MR uses IKE for HoA assignment, it can setup a tunnel and obtain
> its MNP simultaneously by initial BU.

As I said above if the MR is booting up I don't see the MNP assignment 
as time critical.

> We have to remember that MR is also MIP6-MN.  MIP6 WG standardized
> several ways to assign HoA to  MN.

Well, first of all it is not because one choice was made in one 
situation that this choice applies in every other situation.

In this specific case the HoA assignment is an *address* *assignment*, 
and we're talking here about *prefix* *delegation*.

What makes the two fundamentally dissimilar is that to assigns
 addresses 
you can use stateless or statefull mechanism, whereas to delegate a 
prefix a stateful mechanism is required.

Thus I do not see the comparison between MIPv6 HoA assignment and NEMO 
PD as relevant.

> Another question is that shall we have a mechanism to assign HoA and
> prefix at the same time?

I don't think so, this looks like an optimization on something that 
isn't time critical anyway. What would be the point of coupling these 
two, maybe I'm missing something. Modularity is a feature IMHO.

> We should update both documents or write another document how NEMO
> bootstrap work with MIP6 bootstrap mechanisms.
>
> There are certainly pros & cons. Operator should select one.

Well, one thing I'm sure is that having two mechanisms is a drawback 
since it might require coordination between vendors and administrators 
on the operator and MN sides. When a single mechanism is present no 
such coordination is needed.

Cheers,

--julien

> On 2007/11/26, at 22:28, Julien Laganier wrote:
> > Folks,
> >
> > Please see below:
> >
> > On Sunday 25 November 2007, marcelo bagnulo braun wrote:
> >> Hi all,
> >>
> >> With respect to the NEMO prefix delegation issue, it is my opinion
> >> that it would be preferred to have a single prefix delegation
> >> solution rather than two. Moreover, that we should have strong
> >> technical reasons to do more than one solution since this variety
> >> of mechanisms without strong reasons adds needless complexity.
> >>
> >> So, my first question to the working group is: do you think there
> >> are strong technical reasons to have more than one solution for
> >> prefix delegation?
> >>
> >> If no, then which would be the preferred approach for prefix
> >> delegation and why?
> >>
> >> Out goal is to try to wrap up this discussion in the next meting
> >
> > I would like to complement Marcelo's question with some more
> > questions from my side. I am quoting below one of the Architectural
> > Principles of
> > the Internet [RFC1958]:
> >
> >    3.2 If there are several ways of doing the same thing, choose
> > one. If a previous design, in the Internet context or elsewhere,
> > has successfully solved the same problem, choose the same solution
> > unless
> >    there is a good technical reason not to.  Duplication of the
> > same protocol functionality should be avoided as far as possible,
> > without
> >    of course using this argument to reject improvements.
> >
> > In light of this, it seems to me that we should select one
> > mechanism only for prefix delegation in the context of NEMO. If
> > DHCPv6-PD would work, it seems that it should be the only solution
> > adopted. Things are not that simple however and it is possible that
> > very good reasons justify the specification of a new mechanism for
> > prefix delegation in the context of NEMO.
> >
> > To help the WG understand the tradeoffs involved and make an
> > educated choice, I'd like to ask the following questions:
> >
> >    o What could possibly make the existing DHCPv6 PD unsuitable to
> > be used for NEMO PD?
> >
> >    o In case DHCPv6 is suitable but introduces limitations in the
> >      context of NEMO that makes it desirable to standardize another
> >      prefix delegation mechanism for NEMO, what would be the
> >      limitations?
> >
> > Once we have answered these questions I believe the WG will be in
> > the best position to make the best choice.
> >
> > Cheers,
> >
> > --julien
> >
> > _______________________________________________
> > MEXT mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Nov 2007 22:32:30 +0100

Behcet Sarikaya wrote:
> Hi Ryuji, DHCP PD does not require DHCP functionality at the MR.

On a certain axis one would trade among these:
-if MR and HA are DHCP entities then run DHCP-PD unmodified over that
  tunnel.
-if MR is DHCP entity but HA must not run DHCP then some MIP6
  extensions  and some implementation are necessary.
-if MR and HA can not be DHCP entities then do some more MIP6 extensions
  and some more implementation and rely entirely on MIP6.

If the HA can not be a Relay nor a Server then it's complicated IMHO:
assuming the MR already has a Home Address and knows the address of the
DHCP Server in the home network then it's sufficient for it to run a
MRHA-encapsulated unicast DHCP Request/Ack exchange with it.  If it
doesn't know the address of the DHCP Server (but does have a HoA) then
it has to go through the multicast Solicit/Advertise exchange before the
Req/Ack unicast exchange.  Or, multicast behaviour and scope between the
MR-HA tunnel and the home link is currently undefined.

> HA can get a prefix for MR even if MR boots up in foreign network.

Huh?  You mean HA to get a prefix for MR as if the HA were a DHCP
Client?  And then act as a DHCP Server and the MR as a DHCP Client?  "Get"?

Alex