Subject: Re: [mif] I won't be in Taipei for MIF WG

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Oct 2011 16:33:46 +0200

[MIF list - this is ongoing private discussion about route-option vs
 drlo draft; much private discussion happened recently on this topic
 and I am now invited to publish this on the mailing list, so I do].

Tomasz,

Thank you for the remarks.  I am happy we have an opportunity to express
so obviously the difference in our points of view.

Let me try to reply.

Le 27/10/2011 16:06, Tomasz Mrugalski a écrit :
> On 27.10.2011 14:21, Alexandru Petrescu wrote:
>> I do not oppose the time decided by Chairs to do WGLC for 
>> route-option.
> I'm happy to learn that. Thank you.

Sure and genuinely wishing good luck.

>> Efficient (shorter messages) encoding is highly important for 
>> Machine-to-Machine communications which have stringent
>> requirements in terms of bandwidth usage (the lower the better).
> 
> That is a desired aspect of all protocols: choose shorter encoding if
> it is feasible. However, our perception is that the most optimal 
> approach is not to include redundant information at all.

Right, it is not good to include redundant information.  Our method of
encoding avoids redundancy as much as possible.  At its best it only
include the IPv6 address, and then if MAC is needed it is added without
inserting new subtype numbers - it just follows one after the other.

With your method - route option - if one needs to add MAC address then
one needs to add some separator, like suboption number, if I'm not mistaken.

> 
>>> I also ask for not postponing this process any further. There
>>> are customers who are asking for this feature and we would like
>>> to have it deployed sooner rather than later.
>> 
>> Are your customers asking for the draft?  Or for the
>> implementation of the features described in the draft?
> 
> I'll skip most of the rest of your post, because I find it 
> increasingly more inappropriate. Let me point out several things that
> I consider obvious.
> 
> 1. While having working implementation helps if the design is sound,
>  you can't use working implementation to substantiate a proposal.

Hm?  How does this statement compare to "rough consensus and running
code" substantiating a proposal?

> The approach you propose "I have a code that works. Let's write a 
> draft about it and make it a standard" is a negation of the very 
> spirit of IETF. I really hope I just mis-interpreted your mail.

Hm, I am not trying to expose the spirit of IETF.  You may have
misinterpreted me.

> 2. IETF is dedicated to development of protocols, recommendations
> and practices, not a sharing place for exchanging implementations.

But a protocol is made for two machines to exchange data understanding
each other.

> 3. Discussion about specific arrangements with customers is 
> definitely inappropriate in IETF.

I agree, so one would not mention as motivator for a Last Call the fact
that customers are waiting for this, no?

>> Can you provide me implementation of route-option to replace my 
>> existing draft-mouton implementation?
> 
> You chose to document your implementation (or implement -00 
> individual draft, doesn't matter), you publish -00 draft and are 
> expecting that it will not change a bit and be approved as is?

Right... please allow me to say I do not try to be arrogant.

I can agree to modify my implementation, but you're proposing is to get
rid of it alltogether.

> And now you asking that I provide a contingency solution for your 
> mis-planned project? This is ridiculous.

No no, I am not asking for a contingency plan; but what if we tried to
interoperate code?  Interoperability is useful right?

>> (I can provide you our implementation of draft-mouton, under a 
>> certain license.)
> 
> I believe you mentioned that on a list. You have patches for ISC
> DHCP (that is distributed under BSD license). You also have patches
> for wireshark (that you are obliged to publish as source code under
> GPLv2 as soon as you distribute patched wireshark in any form). That
> does say nothing about reasonableness (or lack of thereof) of 
> draft-moulton proposal.

It does say that there is implementation of draft-mouton, i.e. time
spent and software I don't want to through awat.

Hm... then tell me about your implementation and your licensing scheme?

At this point I have no indication whatsoever that route-option draft is
implemented at all.

What happens if I submit my code to ISC and to kernel.org?  Would they
accept it?  Would they ask whether a similar implementation exist?

> I'm sorry. I don't see any point in continuing this discussion any 
> further. If you want to continue it, I suggest that you your comments
> on a list. Maybe someone else is interested in continuing this
> conversation.

Let me Cc the list based on your invitation.

Alex

> Tomek

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Oct 2011 15:29:35 +0000

On Oct 27, 2011, at 10:33 AM, Alexandru Petrescu wrote:
1. While having working implementation helps if the design is sound,
you can't use working implementation to substantiate a proposal.

There is no rough consensus for your proposal, Alexandru.

If your implementation is so complicated that it requires you to contribute code to the ISC, that should already be a clue that it's a bad idea: DHCP options are simple, not complicated.   You aren't supposed to have to change the server source code to add an option.   You are supposed to be able to just specify the option format, and the existing server should be able to parse it.   This is a feature of every server I know of, certainly including the ISC server, which has an option format grammar, and the Nominum server, which has something very similar.

The ISC DHCP client is likewise configurable to allow new options to be described without source code changes.   So the sum total code required to implement the route option should be zero lines.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Oct 2011 18:15:20 +0200

Le 27/10/2011 17:29, Ted Lemon a écrit :
>>> 1. While having working implementation helps if the design is 
>>> sound, you can't use working implementation to substantiate a 
>>> proposal.
>> 

And  is there running code for route-option?

> If your implementation is so complicated that it requires you to 
> contribute code to the ISC, that should already be a clue that it's
> a bad idea: DHCP options are simple, not complicated.

Efficiency sometimes rightfully implies code complexity (check e.g.
PacketBB encoding for wireless settings).

> You aren't supposed to have to change the server source code to add 
> an option. You are supposed to be able to just specify the option 
> format, and the existing server should be able to parse it.

I believe the code format is C code currently (e.g. some quoted text).

> This is a feature of every server I know of, certainly including the
>  ISC server, which has an option format grammar, and the Nominum 
> server, which has something very similar.
> 
> The ISC DHCP client is likewise configurable to allow new options to 
> be described without source code changes.

I am not sure about it.

> So the sum total code required to implement the route option should 
> be zero lines.

I am not sure really.  There should be some code (script? bash? textual
conf lines?)

Please provide some sort of explanation or proof or so, if possible,
thank you.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Oct 2011 18:42:50 +0200

Let me add further to this.

One of the first steps some implementers do is make sure their wireshark
understands their messages... has one tried that on route-option? (for
my information thanks).

(we have tried wireshark extensions for drlo and it works, dissectors
available upon request - that is C code as well).

Alex

---

From: Hui Deng <[email-masked]>
Date: Fri, 28 Oct 2011 16:06:40 +0800

Hello all
 
People are asking the implementation here, 
thanks Okimoto-san about their information below,
 
thanks a lot
 
-Hui

From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: mif route implementation
Date: Fri, 28 Oct 2011 17:01:44 +0900

Hi Teemu and Jun-ya,
 
How do you think about posting below information to MIF list?
# up to you. ;-)
 
Best Regards,
Tadahisa Okimoto

From: Hui Deng [mailto:[email-masked]] 
Sent: Friday, October 28, 2011 4:58 PM
To: 西研開 沖本 忠久; [email-masked]; Teemu Savolainen; Margaret; Jari Arkko; ralph droms; [email-masked]
Subject: RE: mif route implementation

Hi Okimoto-san,
 
Can you kindly help to forward this information to the mif mailing list?
thanks a lot for your help
 
-Hui

From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: mif route implementation
Date: Fri, 28 Oct 2011 16:55:46 +0900

Hi Hui-san,
 
NTT lab shows demonstration with running codes at both IETF78 and IETF79.
 
https://github.com/otroan/IETF-Non-Congruent-Multi-homing/wiki
 
Jun-ya is the guy.
 
Best Regards,
Tadahisa Okimoto

From: Hui Deng [mailto:[email-masked]] 
Sent: Friday, October 28, 2011 4:12 PM
To: 西研開 沖本 忠久; [email-masked]; Teemu Savolainen; Margaret; Jari Arkko; ralph droms
Subject: mif route implementation

Dear Okimoto-san
 
MIF mailing list is discussing the implementation, I remeber that NTT has showed this demonstration before.
Can you share this in the mailing list?
 
thanks a lot
 
-Hui

---

From: <[email-masked]>
Date: Fri, 28 Oct 2011 08:06:59 +0000

> And  is there running code for route-option?

At the IETF#79 we had demonstration of our client side implementation (using ISC's DHCP-client) done with Nokia N900 against NTT's implementation of the DHCPv6 server: http://www.ietf.org/registration/MeetingWiki/wiki/79bofs (see section " Interoperability demonstration regarding IPv6 Multihoming with multiple prefixes and interfaces").

In addition to that, in my lab I configured ISC's DHCP-4.2.0 server with the following configuration (masquerading real addresses with 'x'). The unassigned option code 92 refers to DNS server selection option (as was specified in draft-savolainen-mif-dns-server-selection-04) and unassigned code 93 for DHCPv6 option (as was specified in draft-dec-dhcpv6-route-option-05). I had to use "string" type for OPTION-IA-RT as the grammar for some reason (bug or not-yet-implemented or my lack of skill, don't recall which) did not work with options having multiple sub-options. Please note that all option codes are just "random numbers" selected for implementation.
--
option dhcp6.option-dns-server-selection-policy code 92 = 
			{ ip6-address, integer 8, domain-list };

option dhcp6.option-ia-rt code 93 = string;

subnet6 2001:xxx:xxx:42::/64 {
option dhcp6.name-servers 2001:xxxx:xxxx:xx::x;
option dhcp6.option-dns-server-selection-policy
2001:xxxx:xxxx:xxxx::x 00 "nokia.com", "ovi.com";

option dhcp6.option-ia-rt	
00:01:00:3C:					       // OPTION_NEXT_HOP + len
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:  // next hop address
00:01:00:12:					       // OPTION_RT_PREFIX + len
60:01:                                                                                  // Prefix Length + metric
64:FF:9B:00:00:00:00:00:00:00:00:00:00:00:00:00:  // Prefix
00:01:00:12: 					      // OPTION_RT_PREFIX + len
30:02:				 	 	      // Prefix Length + metric
2A:00:xx:xx:xx:xx:00:00:00:00:00:00:00:00:00:00:   // Prefix
00:01:00:26:                                                                      // OPTION_NEXT_HOP + len
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: // Next Hop address
00:01:00:12:  					      // OPTION_RT_PREFIX + len
00:00:             					     // Prefix Length + metric
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 // Prefix == default route
--
The point here is  that the option could be defined without touching server's source code (or scripts) and I imagine some GUI-based configuration creation tool could also use the string-format without trouble.

The ISC's client side implementation was similarly unable to parse the sub-options, hence I used "string" also there:
--
option dhcp6.option-dns-server-selection-policy code 92 = { ip6-address, integer 8, domain-list };

option dhcp6.option-ia-rt code 93 = string;
--

I admit that on the client side I had to do quite many lines of scripting into "dhclient-enter-hooks" for fetching the data out of the said string.

I also had to modify the C-code of the client to fetch the IPv6 address of the DHCP server, as that was not provided by the ISC DHCP client via any environment variable (this was needed for this case:
--copy--
   When processing a received Route Option a client MUST substitute a
   received 0::0 value in the Next Hop Option with the source IPv6
   address of the received DHCPv6 message.
--copy--

Of course I then needed some addition code for implementing all the actions received information triggered (setting up routes etc), but I guess that part is out of scope of this thread. The dhclient-enter-hooks script actually called a small program that did the actual tricks:
--
/usr/sbin/parse_ia_rt $new_dhcp6_option_ia_rt $interface $dhcpv6_server_address
--

Best regards,

	Teemu

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Oct 2011 13:52:46 +0200

Thank you for the information below, this is relevant support to 
route-option draft.

Side remark: it says to support route-option-02, whereas now 
route-option is at its version 03.  There is difference in message 
format which may impact implementation.

Alex

Le 28/10/2011 10:06, Hui Deng a écrit :
> ------------------------------------------------------------------------
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
>     ------------------------------------------------------------------------
>     *From:* Hui Deng [mailto:[email-masked]]
>     *Sent:* Friday, October 28, 2011 4:58 PM
>     *To:* 西研開 沖本 忠久; [email-masked]; Teemu
>     Savolainen; Margaret; Jari Arkko; ralph droms; [email-masked]
>     *Subject:* RE: mif route implementation
>
>     Hi Okimoto-san,
>
>     ------------------------------------------------------------------------
>     To: [email-masked]; [email-masked];
>     [email-masked]; [email-masked];
>     [email-masked]; [email-masked]; [email-masked]
>         ------------------------------------------------------------------------
>         *From:* Hui Deng [mailto:[email-masked]]
>         *Sent:* Friday, October 28, 2011 4:12 PM
>         *To:* 西研開 沖本 忠久; [email-masked]; Teemu
>         Savolainen; Margaret; Jari Arkko; ralph droms
>         *Subject:* mif route implementation
>
>         Dear Okimoto-san
>
>         MIF mailing list is discussing the implementation, I remeber
>         that NTT has showed this demonstration before.
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Oct 2011 14:04:23 +0200

Le 28/10/2011 10:06, [email-masked] a écrit :
> At the IETF#79 we had demonstration of our client side implementation
> (using ISC's DHCP-client) done with Nokia N900 against NTT's
> implementation of the DHCPv6 server:
> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs (see section
> " Interoperability demonstration regarding IPv6 Multihoming with
> multiple prefixes and interfaces").
>
> In addition to that, in my lab I configured ISC's DHCP-4.2.0 server
> with the following configuration (masquerading real addresses with
> 'x'). The unassigned option code 92 refers to DNS server selection
> option (as was specified in
> draft-savolainen-mif-dns-server-selection-04) and unassigned code 93
> for DHCPv6 option (as was specified in
> draft-dec-dhcpv6-route-option-05). I had to use "string" type for
> OPTION-IA-RT as the grammar for some reason (bug or
> not-yet-implemented or my lack of skill, don't recall which) did not
> work with options having multiple sub-options. Please note that all
> option codes are just "random numbers" selected for implementation.
> -- option dhcp6.option-dns-server-selection-policy code 92 = {
> ip6-address, integer 8, domain-list };
>
> subnet6 2001:xxx:xxx:42::/64 { option dhcp6.name-servers
> 2001:xxxx:xxxx:xx::x; option
> dhcp6.option-dns-server-selection-policy 2001:xxxx:xxxx:xxxx::x 00
> "nokia.com", "ovi.com";
>
> option dhcp6.option-ia-rt 00:01:00:3C:					       // OPTION_NEXT_HOP
> + len 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:  // next hop
> address 00:01:00:12:					       // OPTION_RT_PREFIX + len 60:01:
> // Prefix Length + metric
> 00:01:00:12: 					      // OPTION_RT_PREFIX + len 30:02:
> // Prefix Length + metric
> 00:01:00:12:  					      // OPTION_RT_PREFIX + len 00:00:
> // Prefix Length + metric
> 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 // Prefix == default
> route -- The point here is  that the option could be defined without
> touching server's source code (or scripts) and I imagine some
> GUI-based configuration creation tool could also use the
> string-format without trouble.

I understand.

Let me tell further how I understand it.

The way ISC DHCP software is written, it does not allow to define new
options in the DHCP messages such as to convey lifetime and MAC address
(be it for a default route, or for other route) in an efficient manner
(i.e. avoid artificial "type" and "len" separators).  If one wants to do
that then one has to modify the ISC software more than just reusing its
standard software way of extensions like option dhcp6.option-ia-rt.

This further modification (MAC, lifetime) can only be done by C code.

If find it artificial to limit the specification of protocol to the way
one particular implementation (ISC, which is very good) lets an
implementer to do.

In this sense, I do not think the current route-option spec is
extensible in a way my requirements needs it (limited ressources
wireless, interactions with ND); the current route-option spec is
extensible only in the way that ISC software is extensible.

If route-option draft would not do "default route" - but do "all routes
except default" - then another later option will be able to do "default
route" in a more efficient manner.

Alex

Let me put it otherwise: because ISC implementation doesn't allow one to
avoid touching C code defining new option (e.g. MAC), or a more
efficient way of sequencing
>
> The ISC's client side implementation was similarly unable to parse
> the sub-options, hence I used "string" also there: -- option
> dhcp6.option-dns-server-selection-policy code 92 = { ip6-address,
> integer 8, domain-list };
>
> option dhcp6.option-ia-rt code 93 = string; --
>
> I admit that on the client side I had to do quite many lines of
> scripting into "dhclient-enter-hooks" for fetching the data out of
> the said string.
>
> I also had to modify the C-code of the client to fetch the IPv6
> address of the DHCP server, as that was not provided by the ISC DHCP
> client via any environment variable (this was needed for this case:
> --copy-- When processing a received Route Option a client MUST
> substitute a received 0::0 value in the Next Hop Option with the
> source IPv6 address of the received DHCPv6 message. --copy--
>
> Of course I then needed some addition code for implementing all the
> actions received information triggered (setting up routes etc), but I
> guess that part is out of scope of this thread. The
> dhclient-enter-hooks script actually called a small program that did
> the actual tricks: -- /usr/sbin/parse_ia_rt $new_dhcp6_option_ia_rt
> $interface $dhcpv6_server_address --
>
> Best regards,
>
> Teemu
>
>
>