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

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

Alex, I think you are right. As it is described in draft-ietf-nemo-dhcpv6-pd-02 MR is RR and HA is DR. Because of this Ryuji's concerns hold.
My apologies, I misunderstood this draft. 

Regards,

Behcet

----- Original Message ----
From: Alexandru Petrescu <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Monday, November 26, 2007 3:32:30 PM
Subject: Re: [MEXT] Next steps on prefix delegation

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

_______________________________________________
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: Behcet Sarikaya <[email-masked]>
Date: Tue, 27 Nov 2007 09:53:51 -0800 (PST)

Hello Julien,
  Currently there are two WG drafts draft-ietf-nemo-prefix-delegation-02 and draft-ietf-nemo-dhcpv6-pd-02 which is expired and the main author (Ralph) 
has not been actively participating in the discussions.

Here is my evaluation: draft-ietf-nemo-prefix-delegation-02 is written
to close a gap in RFC 3963. I believe what it proposes (MR requesting
prefix and HA sending prefix) should have been part of 
the base protocol. Also the draft is misnamed I think, 
what the draft proposes is not PD. It leads the way to use PD and maybe that's
why the authors called it nemo PD.
The other draft, draft-ietf-nemo-dhcpv6-pd-02 is about
dhcp PD, it has already expired, there are problems
(some indicated in draft-ietf-nemo-prefix-delegation-02
) in this draft.

Overall my suggestion is to go with draft-ietf-nemo-prefix-delegation-02

but ask the authors to give a better name to it. There are
also several other typos that need to be cleaned.

As for draft-ietf-nemo-dhcpv6-pd-02
, it could be considered if the authors revise it in view of the 
comments.

I hope this helps.

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: [email-masked]
Sent: Tuesday, November 27, 2007 8:32:16 AM
Subject: Re: [MEXT] Next steps on prefix delegation

Hello TJ,

On Monday 26 November 2007, T.J. Kniveton wrote:
> I think that Ryuji's message shows that:
>
> If you want to select one prefix delegation mechanism for NEMO, and
> have it fit a situation where a mobile network is away from the home
> infrastructure, and have the number of messages passed be reasonably
> low, with low complexity...
>
> then, more engineering work is needed.

I am not really sure about what Ryuji message shows ;) At any rate it 
doesn't answer the two questions I've put forth to try to understand 
if/why a single solution isn't doable (What could possibly make the 
existing DHCPv6 PD unsuitable to be used for NEMO PD? 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?). Please note that these
 questions 
were not intended to take side with one proposal or the other but 
rather try to gain understanding so that we have a consensus on what is
 
the best choice.

Our charter only calls for a single prefix delegation mechanism to be 
published as proposed standard, and I also think that it is a 
reasonable goal. I'd like the WG to agree on specification  on a single
 
mechanism. Thus, this note includes a number of questions.

Before we start to discuss about the number of messages incurred by 
prefix delegation maybe it is worth to asnwer the following question:
   
   o Does the WG thinks that keeping the number of messages exchanged
     for prefix delegation when a MR boots in foreign network low is a 
     requirement?

> As I said before, there is a reason that there are two drafts instead
> of one. If you consider this "several ways of doing the same thing"
> as per RFC 1958, then more work will be necessary to create one way
> of doing it that works well.

I think it is fine for the WG to spend more time if it allows 
specification of a single, unified mechanism.

W.r.t. the work needed to make a single mechanism work well, is there's
 
an understanding of the missing parts of either of the proposals:

   o What is missing in the nemo-dhcpv6-pd draft to make it work well?

   o What is missing in the nemo-prefix-delegation draft to make it
 work
     well?

> If, on the other hand, you want to make the assumption that any
> network with NEMO will have DHCP deployed, and you are not concerned
> about bootstrapping a tunnel to the home network to exchange DHCP
> messages, then DHCP is the way to go. 

That would not only be making an assumption, but in fact making DHCPv6 
PD part of the specification for prefix delegation in NEMO. The second 
part of your sentence also bring one question:

    o What are the issues related to bootstrapping a tunnel to the
      home network to exhange DHCP messages?

> But in this case, the minimum effort needed would be to lay out the
> assumptions and have some consensus in the group that this is a
> reasonable engineering compromise.

Seems like a reasonable way to go.

--julien

> 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.
> >
> > PMIP uses similar way of NEMO PD to assign prefix to MN during
> > binding registration.
> > If MR uses IKE for HoA assignment, it can setup a tunnel and obtain
> > its MNP simultaneously by initial BU.
> >
> > We have to remember that MR is also MIP6-MN.  MIP6 WG standardized
> > several ways to assign HoA to  MN.
> >
> > Another question is that shall we have a mechanism to assign HoA
> > and prefix at the same time?
> > 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.
> >
> > regards
> > ryuji
> >
> > 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
> >>