Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

From: Romain KUNTZ <[email-masked]>
Date: Mon, 2 Jun 2008 01:08:19 +0200

Hi,

On 2008/05/31, at 0:13, Behcet Sarikaya wrote:
> I think this is a good point, we should not hurry up a solution just  
> because it was long overdue.
> I have the same concern. Instead of MR, HA could be a better place  
> for DHCP PD.
> http://tools.ietf.org/id/draft-sarikaya-mext-prefix- 
> delegation-00.txt explains this and it is a much simpler document.

I think this document is a companion document to draft-ietf-nemo- 
prefix-delegation-02, which is based on the MIPv6 signaling (BU/BA)  
between the MR and the HA for prefix delegation. If I understand well,  
your document tells how to provision the HA with a list of prefixes,  
but in the end the MIPv6 signaling is used to delegate a prefix to the  
MR. This is different from what is proposed in draft-droms-mext-nemo- 
pd which uses DHCP in all the prefix delegation process.

As DHCP already got the consensus of the WG, that would be better to  
not debate again on "DHCP versus MIP6 signaling".

Regards,
-- 
Romain KUNTZ
[email-masked]
Louis Pasteur University - Networks and Protocols Team

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 2 Jun 2008 19:37:59 -0700 (PDT)

My comments below.

Regards,

Behcet

----- Original Message ----
From: Francis Dupont <[email-masked]>
To: Alexandru Petrescu <[email-masked]>
Cc: Julien Laganier <[email-masked]>; [email-masked]
Sent: Monday, June 2, 2008 5:55:22 PM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

In your previous mail you wrote:

   Or, maybe DHCPv6-PD doesn't use the multicast Solicit/Advertise and uses 
   only the unicast Request/Reply/Confirm messages - in which case MR 
   should discover Server's or HA's address somehow.
  
=> this is not possible (to use only the unicast Request/Reply/Confirm
messages), this is why I introduced the DHCPv6 relay agent to use
only unicast Relay-Forw/Relay-Reply...

[behcet] This is correct. Previous version of this draft was using DHCP Client to do DHCPv6 PD and people said (I think Ryuji it was) this can not work because you are not on link, these messages are going far away to the HA.
Then Francis' draft came to the rescue with the Relay Agent idea.
  However what I would like to point out is that the main idea of this draft and its previous versions is since MR is a router, let MR be the requesting router in DHCPv6 PD. I think that was flawed. MR is a router but it is also an MN, its upstream link is wireless and MR is moving. It needs to establish and maintain MR-HA tunnel. Now, running DHCPv6 PD under these conditions is unprecedented. 
  What the authors of the previous versions missed is the fact that this was not the only way to do DHCPv6 PD under these circumstances.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 4 Jun 2008 07:32:45 -0700 (PDT)

Hi Romain,

----- Original Message ----
From: Romain KUNTZ <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, June 4, 2008 3:43:05 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi Behcet,

On 2008/06/03, at 17:53, Behcet Sarikaya wrote:
> [behcet] This is good point. We will find a solution for this in a  
> separate third draft
> (just a joke).
> I think the same problem exists in Ralph's draft and they need to  
> deal with that as well.

I don't think this is a problem in Ralph's draft. When the MR is at  
home, it just operates DHCP as usual. Messages are not exchanged via  
the MR-HA a tunnel but directly on the home link.

> Ok, what was their opinion on that?
[behcet] I don't want to get into the details but the architecture in Ralph's draft would not work as is on the home link. 
As I said before, I don't think that
we can ignore the possibility of having no home registration at the MR
for DHCPv6 PD interactions, I don't agree this is an implementation
issue.
> [behcet] I would let Marcelo answer this.

I think his answer to Frank Xia makes it clear.
[behcet] It is clear that DHCPv6 PD can be used in different ways. MR as RR IS NOT the only way, draft-sarikaya-mext-prefix-delegation shows this clearly. Let HA be RR and let MR get prefixes using BU/BA (PBU/PBA in PMIPv6 which also has extensions to carry prefixes), just like in PMIPv6 where the first part has not been discussed yet in netlmm.

Regards,

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Jun 2008 07:58:16 -0700 (PDT)

Hi Julien,
  First of all the consensus was on DHCP-PD not necessarily DHCP-PD from MR. So the idea of IKE-PD could as well be considered in-line with the consensus.
  DHCP-PD from MR has several disadvantages such as additional software on the upstream interface of MR be it for a one-time use as you stated.

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: Alexandru Petrescu <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, June 10, 2008 4:15:37 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hello Alex,

On Tuesday 10 June 2008, Alexandru Petrescu wrote:
>
> fan zhao wrote:
> > Hi Julien, Marcelo et al,
> >
> >> The question at this stage is whether we want to make the only
> >> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft.
>
> WEll I agree in principle, provided authors are open to feedback from
> implementation and ready to modify it further.

Just for clarification, if the draft becomes a WG draft, it will of 
course be subject to modifications as per the WG consensus. This is the 
IETF process

> > IMHO, the DHCP-PD solution leads to additional signaling overhead;
> > furthermore, using the DHCP Authentication Option introduces
> > another layer of overhead/redundancy. Therefore, my oponion is
> > DHCP-PD should not be the only solution.
>
> Well DHCP-PD through the secured MR-HA tunnel wouldn't use DHCP auth
> option.

This is my understanding as well.

> > RFC 5026 describes the procedure for the MN to dynamically obtain
> > the home address from the network using the IKEv2. As defined in
> > RFC 3753, a MN could be either a MR or MH. Therefore it is natural
> > to define extensions in the IKEv2 for the MR to request the MNP,
> > which is more efficient and secure.
>
> I'm not sure using IKEv2 to obtain MNP is more efficient than DHCP,
> at least because IKEv2 has much more roundtrips than DHCP, so it
> could be considered heavier (or less efficient).

And bottom line is that optimizing the efficiency of a one round-trip 
process that happens once when the MR boots up, and not in any critical 
path (e.g. handover) at the expense of modularity is questionable, 
IMHO.

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Jun 2008 09:52:57 -0700 (PDT)

Jean-Michel,
  Regarding the certificates for the delegated prefixes, there is an individual draft in DHC WG. This draft proposes to add certificate option to DHCPv6 PD. 
  Once this draft goes through, the certificates will become part of DHCPv6 PD.
  At this moment, we don't know. So I think it is early to talk about this issue.

Regards,

Behcet

----- Original Message ----
From: Jean-Michel Combes <[email-masked]>
To: Frank Xia <[email-masked]>
Cc: Julien Laganier <[email-masked]>; [email-masked]
Sent: Wednesday, June 11, 2008 10:27:23 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi Frank,

At first I assume this is the HA that delegates the MNPs.

2008/6/9, Frank Xia <[email-masked]>:
> Hi JMC
>
>  Firstly, the certificate issuing party is not supposed to be HA, so
>  the certificate does not mandatorily get from the HA.

Agree. The HA has just to provide the cert.

>  Or, how does the HA get  the certificate of the MR?

HA may be the Certificate Authority or a Registration Authority.

>
>  Secondly, if the prefix information can't be sychronized between
>  the certificate issuing party and the HA, the prefix should not
>  included in the certificate.

AFAIK, the HA is always aware of the delegated MNPs: in explicit mode
with the Prefix Table and in implicit mode where it is assumed the HA
knows the MNPs in using a specific mechanism

>
>  There are same concerns with PMIPv6 when  you insist that
>  the certificate should be delegated from the HA.

IMHO, this is the simplest solution when we assume this is the HA/LMA
that delegates the prefixes.

Best regards.

>
>  There is no perfect solution but compromised solution.
>
>  BR
>  Frank
>
>  ----- Original Message ----- From: "Jean-Michel Combes"
> <[email-masked]>
>  To: "Frank Xia" <[email-masked]>
>  Cc: "fan zhao" <[email-masked]>; <[email-masked]>; "Julien Laganier"
> <[email-masked]>
>  Sent: Monday, June 09, 2008 11:05 AM
>
> > Hi Frank,
> > If SEND is deployed in the NEMO network (i.e. MR's ingress interface),
> > at the same time the HA has to provide the MNPs, it has to provide the
> > Router Authorization Certificate linked to the MNPs.
> >
> > There is no relationship between IKE and SEND, by the way.
> >
> > Best regards.
> >
> > JMC.
> >
> > 2008/6/9, Frank Xia <[email-masked]>:
> >
> > > Hi Jean-Michel
> > >
> > >  Even in SEND,  IMHO, it is not necessary for HA to
> > >  provide Router Authorization Certificate because
> > >  HA and MR have authenticated each other using
> > >  IKE, etc.
> > >
> > >  Anyway, this scenario is not clear.
> > >
> > >  BR
> > >  Frank
> > >
> > >  ----- Original Message ----- From: "Jean-Michel Combes"
> > > <[email-masked]>
> > >  To: "Frank Xia" <[email-masked]>
> > >  Cc: "fan zhao" <[email-masked]>; <[email-masked]>; "Julien
> Laganier"
> > > <[email-masked]>
> > >  Sent: Friday, June 06, 2008 6:30 PM
> > >
> > > > Don't forget that people may want to deploy SEND and so you will have
> > > > to provide Router Authorization Certificate too in that case.
> > > > AFAIK, for the moment, there is no proposal to provide such
> > > > certificates with PBU/PBA and so you will have another mechanism. The
> > > > consequence is that you will loose the advantage in time you gained in
> > > > piggybacking the delegated prefixes in the PBU/PBA ...
> > > >
> > > > This is not the case with PMIP because the LMA is aware of the
> > > > prefixes assigned to the MAGs and during the set up of
> > > >
> > > > 2008/6/7, Frank Xia <[email-masked]>:
> > > >
> > > > > Hi Fan
> > > > >
> > > > >  Please check my reply...
> > > > >
> > > > >
> > > > >  BR
> > > > >  Frank
> > > > >
snipped the rest of this huge mail.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Jun 2008 07:40:24 -0700 (PDT)

Hi Pascal,
  Maybe you are right but you'd better get Francis and several others accept your argument.

Regards,

Behcet

----- Original Message ----
From: Pascal Thubert (pthubert) <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; Julien Laganier <[email-masked]>
Cc: [email-masked]
Sent: Friday, June 20, 2008 2:28:25 AM
Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi Behcet
 
The PD draft is consistent with its parent
RFCs 3775 and 3963. If the group agrees in some future that DHAAD should be
deprecated, then we’ll need to revise all 3 documents. What’s important
IMHO is to keep them consistent.
 
Pascal

________________________________
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of  Behcet Sarikaya
Sent: mercredi 18 juin 2008 17:34
To: Julien Laganier
Cc: [email-masked]
Subject: Re: [MEXT] Adoption of
draft-droms-mext-nemo-pd-00.txt?
 
Yes. The reason is
simple, look at this draft:
http://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt

Regards,

Behcet
----- Original Message
----
From: Julien Laganier <[email-masked]>
To: [email-masked]; Behcet Sarikaya 
<[email-masked]>
Sent: Wednesday, June 18, 2008 10:29:27 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

On Wednesday 18 June 2008, Behcet Sarikaya 
wrote:
> Well, I was just wondering if its coauthors agree with this text ?

Well, then I'm still wondering what you're wondering about... Are you 
asking whether or not coauthors of the draft agree with the draft?! 

--julien

> Sent: Wednesday, June 18, 2008 4:00:49 AM
> Behcet,
> I'm wondering what you're wondering about -- the message I sent
> (excerpt below) is quite explicit, isn't it?
>
> > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as
> > a WG draft corresponding to the Nemo Prefix Delegation work item.
> >
> > Authors, please resubmit the draft as WG draft under the name:
> >
> >    draft-ietf-mext-nemo-pd-00.txt
>
> --julien
>
> On Tuesday 17 June 2008, Behcet Sarikaya 
wrote:
> > Hi Julien,
> >  It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any
> > changes based on the long and heated debates we had on
> > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is
> > this what you expected from the authors?
> >
> > Regards,
> >
> > Behcet
> >
> >
> > To: [email-masked]
> > Cc: [email-masked]
> > Sent: Friday, June 13, 2008 10:42:14 AM
> > Folks,
> > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as
> > a WG draft corresponding to the Nemo Prefix Delegation work item.
> >
> > Authors, please resubmit the draft as WG draft under the name:
> >
> >    draft-ietf-mext-nemo-pd-00.txt
> >
> > Note: you can use the online I-D submission tool to make it faster:
> > <https://datatracker.ietf.org/idst/upload.cgi>
> >
> > Thanks.
> >
> > --julien & marcelo, MEXT chairs.
> >
> > On Friday 30 May 2008, marcelo bagnulo braun wrote:
> > > Hi,
> > >
> > > We would like to ask the WG what is their opinion about
accepting
> > > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo
> > > PD deliverable included in our charter.
> > >
> > > Please provide comments so we cna make some progress on this
long
> > > overdue deliverable
> > >
> > > thanks, Julien and marcelo
> > >
> > > -------- Mensaje original --------
> > > Asunto:    I-D Action:draft-droms-mext-nemo-pd-00.txt
> > > Fecha:    Fri, 30 May 2008 05:45:01 -0700 (PDT)
> > > De:    [email-masked]
> > > Responder a:    [email-masked]
> > > Para :    [email-masked]
> > >
> > >
> > >
> > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > >
> > >    Title          : DHCPv6
Prefix Delegation for NEMO
> > >    Author(s)      : R. Droms, et al.
> > >    Filename        :
draft-droms-mext-nemo-pd-00.txt
> > >    Pages          : 12
> > >    Date            : 2008-05-30
> > >
> > > One aspect of network mobility support is the assignment of a
> > > prefix or prefixes to a Mobile Router (MR) for use on the links
> > > in the Mobile Network. 
DHCPv6 prefix delegation can be used for
> > > this configuration task.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.t
> > >xt
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of
the
> > > Internet-Draft.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Jun 2008 08:54:02 -0700 (PDT)

Hi Pascal,
  Two solutions can be proposed:
a) Simply remove that section from the draft. As far as I remember most people suggested this on the mailing list. It would have the implications such as leaving it completely up to the implementations.
b) Not to have HA as DR. As you mentioned in an earlier mail, going for a second solution is also feasible IMHO.

Regards,

Behcet

----- Original Message ----
From: Pascal Thubert (pthubert) <[email-masked]>
To: Julien Laganier <[email-masked]>; Vijay Devarapalli <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, June 25, 2008 8:17:54 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi Julien:

I have seen some discussions and I do not think that there is consensus
on the specific matter of removing the DHAAD based discovery from this
draft. If I did, I would have retracted the text already. What I've seen
is people interested in deprecating DHAAD which is a different thing.

I think there is confusion between a vision of a better future and the
practical work of adding a simple extension to an existing protocol.

Right now the MIP protocol suite still uses dhaad. A NEMO MR will set
the R bit to filter out HAs that do not support NEMO on top of MIP. It
just makes sense for the same MR to set the next bit to filter out HAs
that do not support PD on top of NEMO. Simple update, no new message or
FSM state.

I did not find a convincing alternate either. Making an additional DNS
request adds complexity whereas the idea scanning and binding to all HAs
in the DHAAD list till the PD request works makes very little sense to
me. Finally, making the bootstrap mechanism a prereq to PD is an
undesirable dependency and as a vendor I would not want such an artifact
to impact my product planning.

In a same spirit, I disagree with obsoleting DHAAD in NEMO if we keep it
in MIP. Yet I'm not saying that Vijay is wrong. He might be very right
to push DHAAD out through the window. My point is that we must be
consistent with ourselves. Should we deprecate DHAAD, I think we should
define a new discovery that does it all and obsolete the whole suite of
protocols so that the new flow is not heavier than the current flow.

If you can dedicate a slot in Dublin for PD discussion then we can
expose both viewpoints and see what the group favors. That should be
enough to break the knot.

Pascal

>-----Original Message-----
>From: julien laganier [mailto:[email-masked]] On Behalf Of
Julien Laganier
>Sent: mardi 24 juin 2008 12:19
>To: Vijay Devarapalli
>Cc: Pascal Thubert (pthubert); marcelo bagnulo braun; [email-masked]
>Vijay and Pascal,
><Chair Hat ON>
>Vijay Devarapalli wrote:
>>> -----Original Message-----
>>> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
>>> Sent: Monday, June 23, 2008 5:52 AM
>>> To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier
>>> Cc: [email-masked]
>>> Hi Vijay,
>>> I've not seen a consensus call on this and I'm sorry if I
>>> missed it. If there was none than let us have one with all
>>> the arguments from all parties on the table.
>>
>> There was no consensus call on this. But there were quite a few
>> emails sent on this topic. My conclusion from that discussion
>> was that most people agreed with removing extensions to DHAAD
>> from the prefix delegation document. I don't believe it is
>> Necessary, but we could have an explicit consensus call on this.
>> Julien, Marcelo?
>
>We do not necessary need a consensus call for every decision -- the
>consensus can appear by itself as the result of the discussion,
>consensus call is only needed in case no clear consensus appears after
>the discussion has ran for some time.
>
>So the question is, do you think all the arguments have been expressed
>already and we're now rehashing the same ones? In case the answer is
>yes, I'm happy to proceed with issuing a consensus call on the DHAAD
for
>NEMO-PD issue.