Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 04 Nov 2008 13:02:01 +0100

Hi,

We now start the WGLC for:

DHCPv6 Prefix Delegation for NEMO
draft-ietf-mext-nemo-pd-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt

Please send comments about the draft till the November 19.

Regards, Julien and marcelo

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

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 4 Nov 2008 14:03:23 -0500

Hi Marcelo,

We should remove the extensions to DHAAD from this document. IMO, it's a
bad idea to keep extending DHAAD every time we add an extension to
MIPv6.

We could extend DNS-based HA lookup for discovering a home agent that is
capable of NEMO prefix delegation. But I think this is also unnecessary.
The mobile router can always try the next home agent in the list of the
home agents if the first one does not respond to DHCPv6 messages. If
none of the home agents are capable of prefix delegation, then there is
nothing the mobile router can do about it, maybe use some static mobile
network prefixes. 

We had a discussion at the last IETF and on the mailing list before on
this, but there was no conclusion.

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of marcelo bagnulo braun
> Sent: Tuesday, November 04, 2008 4:02 AM
> To: mext; Julien Laganier; Ralph Droms
> Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt
> 
> Hi,
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 06 Nov 2008 17:35:50 +0100

Anyone else has an opinion on whether we should cover DHAAD on this 
document or not?

regards, marcelo

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 06 Nov 2008 12:29:50 -0600

I agree with Vijay. No reason to have DHAAD text in this document.

-Raj

---

From: Ralph Droms <[email-masked]>
Date: Thu, 06 Nov 2008 13:41:36 -0500

I'd be inclined to agree about not needing DHAAD if I knew more about
typical deployment scenarios.  What's the likelihood of multiple HAs and the
likelihood that some subset won't support NEMO PD?  If the typical scnenario
is just one or two Has, then a search across all HAs for NEMO PD is probably
a reasonable solution.

- Ralph

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 06 Nov 2008 12:49:33 -0600

With no practical experience in terms of MIP6 deployments, I would say that
there is essentially no real information to make a decision.
Multiple HAs are likely. But even in such a case, the numbers would be
small. 

-Raj

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 6 Nov 2008 13:36:19 -0800

I also think we should not have DHAAD on this document. If we need something about capability of the HA, we need it in the discovery defined in 5026 and not for DHAAD; but I think we don't need to indicate the support of PD at the discovery phase at all

Gerardo

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> marcelo bagnulo braun
> Sent: Thursday, November 06, 2008 8:36 AM
> To: Vijay Devarapalli
> Cc: Julien Laganier; mext
> Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Nov 2008 15:59:54 +0100

> Anyone else has an opinion on whether we should cover DHAAD on this 

I'd say yes.  Using DHAAD to remotely discover a DHCP Server may make
sense, as the MN can't use link-local scoped multicast - the typical
method to discover a DHCP Server - when it's away from home.

Alex

>> We should remove the extensions to DHAAD from this document. IMO,
>> it's a bad idea to keep extending DHAAD every time we add an
>> extension to MIPv6.
>> 
>> We could extend DNS-based HA lookup for discovering a home agent
>> that is capable of NEMO prefix delegation. But I think this is also
>> unnecessary. The mobile router can always try the next home agent
>> in the list of the home agents if the first one does not respond to
>> DHCPv6 messages. If none of the home agents are capable of prefix
>> delegation, then there is nothing the mobile router can do about
>> it, maybe use some static mobile network prefixes. We had a
>> discussion at the last IETF and on the mailing list before on this,
>> but there was no conclusion.
>> 
>> Vijay
>> 
>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
>>>  Sent: Tuesday, November 04, 2008 4:02 AM To: mext; Julien
>>> Laganier; Ralph Droms Subject: [MEXT] WGLC for
>>> DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt
>>> 
>>> _______________________________________________ MEXT mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/mext
>>> 
>>> 
>> 
>> 
> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mext
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Nov 2008 16:21:26 +0100

> Please send comments about the draft till the November 19.

I think it's very close to LC, my oppinion is.

Arnaud had some relevant points on IPsec and use of DHCPv6-PD between MR
and HA - if I'm to refine that: what do the SAs and SPDs look
like on MR and HA when they do DHCPv6-PD?  Example?  Then, if
potentially using IKE, what's the sequence: IKE/BUBack/DHCP?  Or
IKE/DHCP/BUBack?  Or DHCP/IKE/BUBack?  Or maybe IKE for DHCPv6PD/BUBAck
is too early to introduce now?  Then only the shared key method maybe.

Also, the draft has no picture.  I can draw topology pictures as ASCII
art showing MR, HA, DR, RR potentially a Relay and LFN and maybe CN.
I can also draw a diagram of the exchanged messages - does
the BU/BAck happen before or after the DHCP Sol/Advertise/Req/Ack?  I'm
asking because the draft currentlyis not clear on this:

> The MR initiates a DHCPv6 message exchange for prefix delegation 
> whenever it establishes an MR-HA tunnel to its HA.

'Whenver' - ok, but before or after?

This clarification can help the implementer.

Section 3.3.2 (and in other places) implies MR may be a Relay, or at
least run the DHCPv6 Relay software:
> In this configuration, when the DHCPv6 client in the MR sends a 
> message, it hands the message to the DHCPv6 relay agent in the MR.

Huh?  I thought the HA could be a Relay, but not the MR be a Relay too.
  BEcause earlier it says this:
> To use DHCPv6PD for Mobile Networks, the HA assumes the role of 
> either the DR or a DHCPv6 relay agent and the MR assumes the role of 
> the RR.  Throughout the remainder of this document, the HA will be 
> assumed to be acting as a DHCPv6PD DR or relay agent and the MR will 
> be assumed to be acting as a RR.

I understand ok why it's proposed the MR to be a Relay (such that it
unicasts the requests across the Internet, instead of sending link-local
multicast packets).  But the MR could simply be a client and put the
multicast request in the tunnel _if_ the tunnel is established prior to
the DHCPv6-PD exchange.  Which brings it back (se mord la queue) to the
question whether DHCPv6-PD happens prior or after the BU/BAck exchange.
  Let's fix this; I can draw the pictures.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Nov 2008 09:56:26 -0800 (PST)

Hi Alex,
  You have a mobile RR in this draft. That's why you need a DHCP Relay Agent at the MR's egress interface.
  If you're saying no, then simply talk to Francis.

Regards,

Behcet

________________________________
From: Alexandru Petrescu <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: Julien Laganier <[email-masked]>; mext <[email-masked]>
Sent: Friday, November 7, 2008 9:21:26 AM
Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt

asking because the draft currentlyis not clear on this:

> The MR initiates a DHCPv6 message exchange for prefix delegation whenever it establishes an MR-HA tunnel to its HA.

Section 3.3.2 (and in other places) implies MR may be a Relay, or at
least run the DHCPv6 Relay software:
> In this configuration, when the DHCPv6 client in the MR sends a message, it hands the message to the DHCPv6 relay agent in the MR.

Huh?  I thought the HA could be a Relay, but not the MR be a Relay too.
BEcause earlier it says this:
> To use DHCPv6PD for Mobile Networks, the HA assumes the role of either the DR or a DHCPv6 relay agent and the MR assumes the role of the RR.  Throughout the remainder of this document, the HA will be assumed to be acting as a DHCPv6PD DR or relay agent and the MR will be assumed to be acting as a RR.

Alex

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

For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Nov 2008 21:08:51 +0100

Behcet Sarikaya wrote:
> Hi Alex, You have a mobile RR in this draft.

YEs I agree, it is as a mobile Requesting Router.

> That's why you need a DHCP Relay Agent at the MR's egress interface.

If we consider MR to also be a DHCP Relay Agent on its egress interface,
and - in addition to being a DHCPClient - have the DHCPServer's address 

> be assumed to be acting as a RR.

because at its end it should say "the MR will be assumed to be acting as
a RR and as a DHCP Relay", instead of just saying "the MR will be
assumed to be acting as a RR".

BEsides, whereas it's common to have a topology like this:

DHCPClient-----DHCPRelay-----------DHCPServer

(I think) DHCPv6 does not suggest to have a topology with 'serialized'
DHCPRelays, like this:

DHCPClient-----DHCPRelay-----DHCPRelay---....----DHCPRelay----DHCPServer

If we agree on this impossibility, then once the MR is a DHCPRelay the
HA can't be a DHCPRelay at the same time, and vice-versa.  Which would
imply further changes in the above mentioned paragraph.

> If you're saying no, then simply talk to Francis.

Well I guess he's reading this list and if he considers the above remark
worth a dime he'd reply a cent.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 08 Nov 2008 12:47:09 +0900

Hi Marcelo,

I agree with Vijay and Raj. 

We had similar discussion for MCoA. We decided not to have DHAAD
extension to discover MCoA capable HA.

regards,
ryuji

At Thu, 06 Nov 2008 17:35:50 +0100,

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 13 Nov 2008 13:59:06 +0100

I would also be in favour of removing the DHAAD extension from this  
document. DHCPv6-PD would most likely be used with other bootstrapping  
mechanisms that are based on DNS SRV for HA lookup, which makes this  
DHAAD extenstion useless.

If a HA discovery mechanism should be included in the document, I  
would prefer the definition of a new DNS SRV request.

Regards,
-- 
Romain KUNTZ
[email-masked]
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

On 2008/11/06, at 17:35, marcelo bagnulo braun wrote:

>> it's a
>> that is

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Nov 2008 12:43:56 +0100

Hi Vijay:

Same old discussion. My position is still the same. Either we deprecate
DHAAD fully (from 3775bis), or we need to extend it when it makes sense.
The draft-ietf-mext-nemo-pd draft is not the right place for making this
decision.

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vijay Devarapalli
>Sent: mardi 4 novembre 2008 20:03
>To: marcelo bagnulo braun; mext; Julien Laganier; Ralph Droms (rdroms)