Stig Venaas | 9 Mar 2005 19:50
Picon
Picon

Re: Revised Drafts on Source Address Selection Posted

On Thu, Mar 10, 2005 at 03:36:34AM +0900, Tomohiro -INSTALLER- Fujisaki/?$BF#:j ?$BCR9( wrote:
> 
> 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.

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.

>  | 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?

>  | 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.
> 
> We've shown some examples in other draft : 
> 
> > Title : Source Address Selection Policy Distribution for Multihoming
> > 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.

OK, I see.

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

OK

Stig

Gmane