Subject: RE: [dhcwg] Revised Drafts on Source Address Selection Posted

From: "Bernie Volz" <[email-masked]>
Date: Wed, 9 Mar 2005 00:03:41 -0500

Hi:

Don't know if someone else has already commented on this, but in
draft-hirotaka-dhc-source-address-selection-opt-01.txt there is no reason to
align the options data or to have the "pad" bytes. The prefix lengths can
also be 1-byte (8-bit), not just multiples of 4 bytes. There is no point in
attempting to align the data or making it multiples of 4 bytes because other
options aren't -- so the alignment may be off anyway.

- Bernie 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tomohiro -INSTALLER-"Fujisaki/“¡è ’qG"
> Sent: Wednesday, February 02, 2005 11:22 PM
> To: [email-masked]
> Subject: [dhcwg] Revised Drafts on Source Address Selection Posted
> 
> 
> Hi all,
> 
> We've submitted a set of revised internet drafts about IPv6 source
> address selection policy distribution.
> 
> 
> Title : Source Address Selection Policy Distribution for Multihoming
> Filename	: draft-arifumi-ipv6-sas-policy-dist-00.txt
> 
>   This one is changed a bit drastically.
>   A section for problem clarification is included.
>   Also a brief consideration about policy merging, network
>   failure recovery and comparison with other solutionos are added.
> 
> 
> Title  : Source Address Selection Policy option for DHCPv6
> Filename	: draft-hirotaka-dhc-source-address-selection-opt-01.txt
> 
>   This one also isn't changed so much. Since we got some comments that
>   prefix information will become large in some cases, so in this
>   version, we modified to use prefix information compression technique
>   used in the RA draft below.
> 
> Title : Configuring Source Address Selection Policy by
>           Neighbor Discovery Protocol for IPv6
> Filename	: draft-arifumi-ipv6-nd-source-address-select-02.txt
> 
>   This isn't changed so much, but small changes about option format
>   are included.
> 
> We appreciate any suggestions or comments.
> 
> Best regards,
> 
> --
> Tomohiro Fujisaki, Nippon Telegraph and Telephone Corporation
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: (Tomohiro -INSTALLER- Fujisaki) <[email-masked]>
Date: Thu, 10 Mar 2005 01:33:04 +0900 (JST)

Bernie,

 | Don't know if someone else has already commented on this, but in
 | draft-hirotaka-dhc-source-address-selection-opt-01.txt there is no reason to
 | align the options data or to have the "pad" bytes. The prefix lengths can
 | also be 1-byte (8-bit), not just multiples of 4 bytes. There is no point in
 | attempting to align the data or making it multiples of 4 bytes because other
 | options aren't -- so the alignment may be off anyway.

As you point out, 4-bytes alignment is not necessary with this option
format.

I'll delete the 'pad' bytes in the next revision.

Thank you for your comment.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 9 Mar 2005 17:40:20 +0100

Here are my comments

RFC 3484 defines a policy table that allows both source and destination
address selection. I think this option should provide what is needed to
define that table. The main problem is that we need precedence I think.
Perhaps better to define option with label also, so more directly match
the table.

Also RFC 3484 states that scopes addresses may be qualified with zone
index, so perhaps that is needed too?

I think the ipv6 wg needs to consider whether DHCP is the right
solution, and also the questions above.

It's not quite clear to me how the option would be used for the example
you have. Perhaps good to also write that down in the draft.

Finally, to specify multiple source prefixes you send multiple options,
right? Is the ordering important?

Stig

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Thu, 10 Mar 2005 03:36:34 +0900 (JST)

Stig,

Thank you for your valuable comments.

 | RFC 3484 defines a policy table that allows both source and destination
 | address selection. I think this option should provide what is needed to
 | define that table. The main problem is that we need precedence I think.
 | Perhaps better to define option with label also, so more directly match
 | the table.

We define this option with the viewpoint of providing the information
that is necessary to source address selection.  In RFC3484, the
'precedence' is used to arrange the order of multiple destination
addresses if the destination node has multiple IPv6 address, so this
is not necessary for the source address selection itself.

However, I agree this option should include all information to create
the policy table, so I'll change the packet format.

Labels can be decided by the host to assign the same label to the
'related prefix' field and 'destination prefixes' field pair in my
draft format, so I think it is not necessary to deliver the label with
this option.

 | Also RFC 3484 states that scopes addresses may be qualified with zone
 | index, so perhaps that is needed too?

The site local address is deprecated, so this zone index is not
necessary.

 | It's not quite clear to me how the option would be used for the example
 | you have. Perhaps good to also write that down in the draft.

> Filename	: draft-arifumi-ipv6-sas-policy-dist-00.txt

but I'll rewrite the example more clearly.

 | Finally, to specify multiple source prefixes you send multiple options,
 | right? Is the ordering important?

Actually, we want multiple source address prefixes to be delivered
both in one option and multiple options.  We want to support both.

However, I've missed the 'number of destination prefixes' field in my
format, that is necessary to deliver in one option, when I revised the
draft from -00 to -01. I'll correct this in the next revision.

Matching of the address policy table is done by best-matching, so
the ordering is not important.

Yours sincerely,
--
Tomohiro Fujisaki

---

From: Stig Venaas <[email-masked]>
Date: Wed, 9 Mar 2005 19:50:17 +0100

> draft format, so I think it is not necessary to deliver the label with

Yes, I agree, whether to make the label explicit or implicit like you
suggest is a matter of taste. I don't have an opinion on which is best.

> The site local address is deprecated, so this zone index is not

Haven't given it careful thought, but what about multicast addresses or
link-local addresses?

> draft from -00 to -01. I'll correct this in the next revision.

OK, I see.

> the ordering is not important.

OK

Stig

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Thu, 10 Mar 2005 06:52:16 +0900 (JST)

| >  | Also RFC 3484 states that scopes addresses may be qualified with zone
 | >  | index, so perhaps that is needed too?
 | > 
 | > The site local address is deprecated, so this zone index is not
 | > necessary.
 | 
 | Haven't given it careful thought, but what about multicast addresses or
 | link-local addresses?

I've missed the site-scope multicast case. 

As you say, there may be some cases to use zone index in scoped multicast
environment. The 'zone index' should be included to deliver RFC 3484 policy
table. I'll add this parameter to the option.

Yours sincerely,
--
Tomohiro Fujisaki

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 10 Mar 2005 07:38:28 +0900

>>>>> On Thu, 10 Mar 2005 01:33:04 +0900 (JST), 
>>>>> (Tomohiro -INSTALLER- Fujisaki) <[email-masked]> said:

> I'll delete the 'pad' bytes in the next revision.

I encountered the same question, and I'm about to ask that.  I agree
with removing pad bytes and using variable length prefix fields
without alignment.  But then I'd like to note that you'll need to
specify the number of prefixes in the option; otherwise, the receiving
node cannot (always) determine the end of prefixes (you already seemed
to come to this conclusion in a different thread, though).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 10 Mar 2005 09:08:06 +0900

>>>>> On Thu, 10 Mar 2005 06:52:16 +0900 (JST), 
>>>>> <[email-masked]> said:

> table. I'll add this parameter to the option.

I don't think this works, since specific values of scope zone indices
are only meaningful within a single node.

					JINMEI, Tatuya

---

From: Stig Venaas <[email-masked]>
Date: Thu, 10 Mar 2005 14:52:49 +0100

On Thu, Mar 10, 2005 at 09:08:06AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
[...]
> are only meaningful within a single node.

I mentioned it because it's in 3484, but you're right, this is
problematic. There might be cases where the DHCP administrator knows
which clients are on the network and wants specific interfaces to be
used though. Whether it should be there or not would be something the
ipv6 wg could help us with perhaps.

Stig