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

[Shinta Sugimoto <[e-mail]>]

Hi Sébastien,

Please find my comments inline.

Sébastien Barré wrote:
> 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.

You are right.  My intention was the other way around, as the choice of 
destination locator must be made by the sender (as far as the selected 
destination locator appears in the locator list).  Sorry for the 
confusion.  So, the proposal is to add the following texts:

2) preference of the destination locator specified by SHIM_LOC_PEER_SEND 
or SHIM_LOC_PEER_PREF must supersede the preference specified by the peer.

> Also, How does an application mention that its setting of locator 
> preference is inbound or outbound ? If it is outbound, the shim must

SHIM_LOC_{PEER,LOCAL}_PREF is only for outbound.  In my understanding, 
it does not make sense to allow application to set preference for 
inbound packet processing (it's up to the peer).  As far as the locators 
(source and destination) appear in the locator list that the receiving 
peer has, it needs to receive the packet.  And the Shim6 spec does not 
specify any means for a peer to inform the preference of the destination 
locator of inbound traffic (and I think it makes sense to not define 
such a means).

The name SHIM_LOC_{PEER,LOCAL}_PREF does not explicitly tell whether the 
preference is for inbound or outbound (or both), and there is no 
explanation in each section either.  So, let me add texts to section 5.5 
(SHIM_LOC_LOCAL_PREF) and section 5.6 (SHIM_LOC_PEER_PREF) stating that 
the preference set by application is only effective for outbound traffic.

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

Please let me know if my explanation above makes sense.

Regards,
Shinta

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