headers
Hesham Soliman | 1 Jun 2008 04:59

Re: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-03.txt

Thanks, will do that. I changes a lot of them in the revision before last
but it seems there are some still there.

Hesham

On 29/05/08 7:46 PM, "George Tsirtsis" <tsirtsis <at> googlemail.com> wrote:

> Hesham,
> 
> I noticed some typos which you can fix whenever convinient.
> It looks like some initial letters have been omitted in several places e.g.:
> Page 36:
> "
>    Home Agent SPD-S:
> 
>       F local_address = home_agent_1 &
> 
>       remote_address = home_address_1 &
> "
> I think this F is an "IF"
> and in page 37
> "   The above should result in BU/BA messages with the following BU
>    received by the home agent.
> 
>       Pv4 header (src=V4ADDR, dst=HA_V4ADDR)
> 
>       UDP header (sport=Z, dport=DSMIPv6)"
> 
> "Pv4" should be "IPv4"
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
George Tsirtsis | 1 Jun 2008 09:50

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

On Sat, May 31, 2008 at 12:47 AM, Arnaud Ebalard <arno <at> natisbad.org> wrote:
> Hi Marcelo,
>
> marcelo bagnulo braun <marcelo <at> it.uc3m.es> writes:
>
>>> In practice (as a HA and MR administrator), I'd like to be able to
>>> simply configure the prefixes for my MR in the HA configuration section
>>> for this MR and that those prefixes be sent to the MR during the
>>> initial binding if it ask for prefix(es). In a sense considering the
>>> an initial static configuration of a MR, switching to PD would mean:
>>>
>>>   - changing a knob in the MR config to switch to prefix delegation
>>>   - giving the prefix in the HA config, indicating PD for that MR
>>>
>>> i.e. no need for IDs, specific keys for auth, or additional relay and
>>> associated IPsec credentials config.
>>>
>>>
>> I am not sure what you mean hre. Are you suggesting any additional
>> changes in the document?
>
> Not in that part of my first reply.
>
>> Or are you proposing using a different  mechanism other than dhcp for
>> this?
>
> No, I do not propose another mechanism. I just give my feedback on the
> pros and cons of the proposal in term of coverage. To make it clear, I
> think that the proposal will cover the needs of big infrastructures. As
> it is probably a part of the audience, I think the document deserves to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnaud Ebalard | 1 Jun 2008 14:23
Favicon

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

Hi George,

"George Tsirtsis" <tsirtsis <at> googlemail.com> writes:

>> That been said, it's not because I consider that the document deserves
>> to be WG item for that part of the audience that I think it will provide
>> a "one size fits all" solution for NEMO PD, for instance for very small
>> devices like PDA or Phones. I was basically wondering if I will ever
>> have to install and configure a DHCPv6 server with Relay and PD support
>> on my Phone or PDA just for the purpose of getting a prefix from my
>> HA. But considering what you write below (hiring DHCP for the job is
>> the consensus), this will be the case.
>>
>
> Arnaud,
>
> This maybe simply a misunderstanding but draft-droms does not require
> you to do this. The Mobile Router, is a Requesting Router (RR) i.e., a
> DHCP-PD client. So no server functionality is required in you small
> devices.

You are correct, the terms I used were not precise: I thought "daemon"
but used "server". I should have said "DHCPv6 relay and/or DHCPv6 client
with PD support". My point was that DHCPv6 is in all cases not a light
requirement for small devices just for providing a prefix.

Anyway, the use of DHCPv6 is the consensus, so I will not argue anymore.

Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romain KUNTZ | 2 Jun 2008 00:49
Picon
Picon
Favicon

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

Hi,

I'm in favor of accepting this document as WG doc.
I have however one major concern: it proposes to use DHAAD to discover  
DHCPv6PD-enabled HA. However, the MIPv6 bootstrapping documents does  
not rely on DHAAD at all. More relationship should be considered  
between MIPv6 and NEMO bootstrapping, to enable the selection of a  
DHCPv6PD-enabled HA when the HA selection is performed during the  
MIPv6 bootstrapping time (e.g. by extending the DNS SRV lookup).

About the text itself, for clarity I think that the section about to  
the home link (3.4) should be merged with section 3.1 ("When the MR  
uses DHCPv6").

Regards,
--

-- 
Romain KUNTZ
kuntz <at> lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

On 2008/05/30, at 16:51, 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romain KUNTZ | 2 Jun 2008 01:08
Picon
Picon
Favicon

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

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
Louis Pasteur University - Networks and Protocols Team

 

_______________________________________________
MEXT mailing list
MEXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext
Permalink | Reply | 0 comments |
headers
Vijay Devarapalli | 2 Jun 2008 03:45
Favicon

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

Hi Roamin and others,

IMO, we should remove the extensions to DHAAD from this document. 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.

Vijay

> -----Original Message-----
> From: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] On 
> Behalf Of Romain KUNTZ
> Sent: Sunday, June 01, 2008 3:50 PM
> To: marcelo bagnulo braun
> Cc: Julien Laganier; mext <at> ietf.org
> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
> 
> Hi,
> 
> I'm in favor of accepting this document as WG doc.
> I have however one major concern: it proposes to use DHAAD to 
> discover  
> DHCPv6PD-enabled HA. However, the MIPv6 bootstrapping documents does  
> not rely on DHAAD at all. More relationship should be considered  
> between MIPv6 and NEMO bootstrapping, to enable the selection of a  
> DHCPv6PD-enabled HA when the HA selection is performed during the  
> MIPv6 bootstrapping time (e.g. by extending the DNS SRV lookup).
> 
> About the text itself, for clarity I think that the section about to  
> the home link (3.4) should be merged with section 3.1 ("When the MR  
> uses DHCPv6").
> 
> Regards,
> -- 
> Romain KUNTZ
> kuntz <at> lsiit.u-strasbg.fr
> Louis Pasteur University - Networks and Protocols Team
> 
> 
> On 2008/05/30, at 16:51, 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: 	Internet-Drafts <at> ietf.org
> > Responder a: 	internet-drafts <at> ietf.org
> > Para: 	i-d-announce <at> ietf.org
> >
> >
> >
> > 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.txt
> >
> > 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.
> >
> >
> > Content-Type: text/plain
> > Content-ID: <2008-05-30054232.I-D <at> ietf.org>
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > _______________________________________________
> > MEXT mailing list
> > MEXT <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/mext
> 
> 
> _______________________________________________
> MEXT mailing list
> MEXT <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>
Permalink | Reply | 0 comments |
headers
marcelo bagnulo braun | 2 Jun 2008 10:58
Picon

[MEXT] RFC3775 update

Hi,

In last IETF we said that we will accept input for RFC3775 changes for 
about 3 months and then try to wrap up this issues.

This is reminder of that plan and that proposals for changes for RFC3775 
are accepted till the 15 of june.

After that we will go through the proposed changes and try to reach 
consensus on each of the proposed changes (including the text to be 
included and removed) in the ml.

After that we will ask the authors of rfc3775 to submit a 3775bis 
including the accepted changes and go to WGLC.

Regards, Julien and marcelo
Permalink | Reply | 0 comments |
headers
Alexandru Petrescu | 2 Jun 2008 11:44
Picon

Re: [MEXT] TC/flow label copying (was: RFC3775 update)

Hi Marcelo, I'm not sure whether this has been discussed or not.

rfc3775 is silent about HA copying or ignoring the Trafic Class and Flow 
Label fields when de/encapsulating from/to MN.  It can prove to be an 
issue when using that field.  In some implementations the field _is_ 
copied, which is a good thing IMHO.

On this topic, rfc3775 points to rfc2473 ("Generic Packet Tunneling in 
IPv6") which further says "Depending on the entry-point node tunnel 
configuration, the [flow label]/traffic class can be set to that of 
either the original packet or a pre-configured value."

In practice however, many implementations of rfc2473 don't have a means 
to set a pre-configured value for the traffic class/flow label.  This is 
something relatively difficult to implement because it's difficult to 
link a set of parameters into a pre-configured traffic class/flow label: 
What does a pre-configured traffic class/flow label correspond to: a 
pair of IP addresses?  port numbers?  etc.

On this reasoning, I prefer 3775 to say that the HA must either copy the 
traffic class/flow label, or set it to 0.

Just say a good recommendation instead of relying on rfc2473 
unimplemented means of this behaviour.

Alex

marcelo bagnulo braun wrote:
> Hi,
> 
> In last IETF we said that we will accept input for RFC3775 changes for 
> about 3 months and then try to wrap up this issues.
> 
> This is reminder of that plan and that proposals for changes for RFC3775 
> are accepted till the 15 of june.
> 
> After that we will go through the proposed changes and try to reach 
> consensus on each of the proposed changes (including the text to be 
> included and removed) in the ml.
> 
> After that we will ask the authors of rfc3775 to submit a 3775bis 
> including the accepted changes and go to WGLC.
> 
> Regards, Julien and marcelo
> 
> _______________________________________________
> MEXT mailing list
> MEXT <at> ietf.org
> 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 
______________________________________________________________________
Permalink | Reply | 0 comments |
headers
Alexandru Petrescu | 2 Jun 2008 11:51
Picon

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

Vijay Devarapalli wrote:
> Hi Roamin and others,
> 
> IMO, we should remove the extensions to DHAAD from this document. It's a
> bad idea to keep extending DHAAD every time we add an extension to
> MIPv6.

It's a bad  idea to not extend DHAAD.

> We could extend DNS-based HA lookup for discovering a home agent that is
> capable of NEMO prefix delegation.

It's a bad idea to extend DNS for discovering stuff.  DNS is not for 
discovery.

Alex

  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.
> 
> Vijay
> 
>> -----Original Message-----
>> From: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] On 
>> Behalf Of Romain KUNTZ
>> Sent: Sunday, June 01, 2008 3:50 PM
>> To: marcelo bagnulo braun
>> Cc: Julien Laganier; mext <at> ietf.org
>> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
>>
>> Hi,
>>
>> I'm in favor of accepting this document as WG doc.
>> I have however one major concern: it proposes to use DHAAD to 
>> discover  
>> DHCPv6PD-enabled HA. However, the MIPv6 bootstrapping documents does  
>> not rely on DHAAD at all. More relationship should be considered  
>> between MIPv6 and NEMO bootstrapping, to enable the selection of a  
>> DHCPv6PD-enabled HA when the HA selection is performed during the  
>> MIPv6 bootstrapping time (e.g. by extending the DNS SRV lookup).
>>
>> About the text itself, for clarity I think that the section about to  
>> the home link (3.4) should be merged with section 3.1 ("When the MR  
>> uses DHCPv6").
>>
>> Regards,
>> -- 
>> Romain KUNTZ
>> kuntz <at> lsiit.u-strasbg.fr
>> Louis Pasteur University - Networks and Protocols Team
>>
>>
>> On 2008/05/30, at 16:51, 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: 	Internet-Drafts <at> ietf.org
>>> Responder a: 	internet-drafts <at> ietf.org
>>> Para: 	i-d-announce <at> ietf.org
>>>
>>>
>>>
>>> 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.txt
>>>
>>> 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.
>>>
>>>
>>> Content-Type: text/plain
>>> Content-ID: <2008-05-30054232.I-D <at> ietf.org>
>>>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/mext
>>
>> _______________________________________________
>> MEXT mailing list
>> MEXT <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>>
> _______________________________________________
> MEXT mailing list
> MEXT <at> ietf.org
> 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 
______________________________________________________________________
Permalink | Reply | 0 comments |
headers
Alexandru Petrescu | 2 Jun 2008 11:53
Picon

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

Arnaud Ebalard wrote:
> Hi George,
> 
> "George Tsirtsis" <tsirtsis <at> googlemail.com> writes:
> 
>>> That been said, it's not because I consider that the document deserves
>>> to be WG item for that part of the audience that I think it will provide
>>> a "one size fits all" solution for NEMO PD, for instance for very small
>>> devices like PDA or Phones. I was basically wondering if I will ever
>>> have to install and configure a DHCPv6 server with Relay and PD support
>>> on my Phone or PDA just for the purpose of getting a prefix from my
>>> HA. But considering what you write below (hiring DHCP for the job is
>>> the consensus), this will be the case.
>>>
>> Arnaud,
>>
>> This maybe simply a misunderstanding but draft-droms does not require
>> you to do this. The Mobile Router, is a Requesting Router (RR) i.e., a
>> DHCP-PD client. So no server functionality is required in you small
>> devices.
> 
> You are correct, the terms I used were not precise: I thought "daemon"
> but used "server". I should have said "DHCPv6 relay and/or DHCPv6 client
> with PD support". My point was that DHCPv6 is in all cases not a light
> requirement for small devices just for providing a prefix.

That sounds reasonable, but what do you mean by small devices?  Most if 
not all such small devices first things they do when they come alive is 
DHCP and then TCP and then HTTP.

DHCP PD is not heavier than DHCP tout court in terms of message numbers 
and size.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
Permalink | Reply | 0 comments |

Gmane