Re: [shim6] SHIM_LOC_*_PREF and SHIM_LOC_*_SEND

[Sébastien Barré <[e-mail]>]

Shinta,

Shinta Sugimoto a écrit :
> Sébastien,
>
> Let me address my view on SHIM_LOC_*_PREF and SHIM_LOC_*_SEND.
>
> The two have different meaning.  SHIM_LOC_*_SEND allows application to 
> specify source or destination locator, whereas SHIM_LOC_*_PREF allows 
> application to specify preference of a given locator.  Yes, they are 
> similar in the sense that both allow application to make selection of 
> source or destination locator in some form.  However, I prefer to keep 
> SHIM_LOC_*_PREF because  I think the concept of handling preference of 
> locators is useful, especially in the cases where are multiple 
> choices.  But I admit that the current definition of SHIM_LOC_*_PREF 
> in the document is not aligned with what is defined in RFC 5533, which 
> is confusing.  We should fix this.
>
> as stated in RFC 5533, preference of locator shall be handled in the 
> same way as RFC 2782 (DNS SRV).  That is, a preference is represented 
> by a pair of priority and weight values.  So, I would suggest to keep 
> SHIM_LOC_*_PREF by applying the following changes to the document:
>
> - update definition of locator information structure (shim_locator{}) 
> in section 7.1 (define a 16-bit unsigned integer parameter named 
> lc_weight to store weight value ranging from 0-65535)
makes sense.
> - update texts in section 5.5 and 5.6 to make the definition of 
> preference aligned with RFC 5533.
ok
> - provide explanations on how ths shim sub-layer would react in the 
> case of conflicting situations.  There are at least two situations 
> that we should think of.  I think Section 10 (Operational 
> Considerations) would be the right place to have these texts.
>
> 1) when the application specifies SHIM_LOC_*_SEND specifying a 
> different source or destination locator which does not have the 
> highest priority/weight specified by the SHIM_LOC_*_PREF, the request 
> made by SHIM_LOC_*_SEND must overwrite the prefenrece specified by 
> SHIM_LOC_*_PREF.
ok
>
> 2) when the peer provides preference of the locators, that must 
> overwrite the preference specified by SHIM_LOC_PEER_SEND or 
> SHIM_LOC_PEER_PREF.
Well, regarding that point: Are you sure we should not do it the other 
way around ? I mean, imagine a server, that for some applications, does 
not want to use one of its paths for security reasons. If now I want to 
force the use of the normally forbidden path, I can just send a locator 
preference option, and this will override the local preference of the 
server. This is why I think we should instead always give the priority 
to local choices. And if locally two paths are considered equal, only 
then can they be classified according to peer preferences.

Also, How does an application mention that its setting of locator 
preference is inbound or outbound ? If it is outbound, the shim must 
just reorder its locator list. If it is inbound, the shim must send 
locator preference option to the peer stating the new value of 
preferences. Or is it considered always true that the setting of a 
locator preference is both inbound and outbound ? It might be indeed, 
but anyway maybe it is good in that case to explicitly mention that the 
preference setting is bidirectional, and thus the shim should notify the 
peer about the new preference.

Did i miss something ?

regards,

Sébastien.
>
> does this sound reasonable?
>
> Regards,
> Shinta
>
> Sébastien Barré wrote:
>
>> *Section 5.5 and 5.6 : SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF: As 
>> defined, these options are duplicate of SHIM_LOC_LOCAL_SEND and 
>> SHIM_LOC_PEER_SEND. Thus I would remove two of them, and keep 
>> preferably the SHIM_LOC_*_SEND version, since the SHIM_LOC_*_PREF 
>> version is confusing due to section 5.15.3 of rfc 5533 that defines 
>> differently the locator preferences.
>
>
>> *Section 9, §2, again, confusion between SHIM_LOC_*_SEND and 
>> SHIM_LOC_*_PREF

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre