Re: Design decisions made at the interim SHIM6 WG meeting

[marcelo bagnulo braun <[e-mail]>]

Hi Iljitsch,


El 27/10/2005, a las 14:42, Iljitsch van Beijnum escribió:

> On 19-okt-2005, at 6:11, Geoff Huston wrote:
>
>> The following is a list of SHIM6 design decisions
>
> I don't think "decisions" is the right word here... These are more 
> like suggestions by the chairs.
>

sorry, but i disagree here.
The points below were accepted by most of the people in the room (i 
certainly accepted most of them)

(perhaps there is some points where there may be some misunderstanding 
on the final outcome, like the point about the preferences that Erik 
brought up (my understanding was similar to Erik's one) but this is a 
natural problem when summarizing long discussions as the ones we had, 
and they are  being clarified through this discussion)


>> 1.  The specification for initial contact will use RFC3484, as 
>> modified by
>>     this draft in terms of source address ordering.
>
> Well, all IPv6 hosts are expected to use RFC 3484 address selection, 
> nothing new there. In fact, we have to break RFC 3484 from time to 
> time because otherwise we'd be selecting non-working addresses.
>
> The real point is what happens when the address pair selected by 
> either the application or RFC 3484 doesn't work. How do we handle this 
> case?
>

the idea, (and i think this is was this decision point is about) is 
that we need an update to rfc 3484 to deal with this.
i am currently working on a document about this (as we agreed in the 
meeting) with some proposals of how to update rfc3484 to deal with 
this.

>> 2.  Use an 8 byte IP SHIM6 header in the base protocol specification 
>> for
>>     packets that require specific SHIM6 processing by the receiver, 
>> and
>>     allow optimizations on this, including that of a zero-length 
>> header, to
>>     be an experimental protocol extension.
>
> I have no problem with a shim header for demultiplexing in cases where 
> demultiplexing would otherwise be very hard or impossible. For 
> instance, in the case of several extension headers, an explicit shim 
> header makes it possible to indicate which headers see modified 
> addresses and which headers see unmodified addresses unambiguously.
>
> However, I think it's a very bad idea to have a shim header in EVERY 
> packet with rewritten addresses, because there are cases where the 
> shim context can be determined from information that's already in the 
> packet unambiguously so an extra header is unnecessary.
>
> Mandating a shim header first and then optionally allow it to be 
> suppressed is useless in practice: we need have the capability to have 
> the shim header suppressed

so far i think that we all agree

>  as a mandatory part of the inital base spec.
>

this is the point of debate: whether this extension should be mandatory 
in the base spec or not.

my opinion about this, is that this would be indeed quite complex. I 
mean i like the idea but i am afraid that when we try to define the 
details, the result will be complex. If not i would certainly support 
this

I think that the best approach is what (i understood that it) was 
decided in the meeting:
- for now the base spec does not includes this.
- a document is produced to understand what it would take to support 
this extension. that is a full fleshed proposal of what would be 
required to do this. (my recall is that you and Pekka? were to produce 
this?)

>> 4.  Use a 32 bit context field with no checksum, and 15 reserved bits 
>> and a
>>     1 bit flag to indicate control / payload. Note potential DOS risks
>
> If we know there are risks today, maybe it makes more sense to make 
> the tag variable size (to be negotiated between the peers) rather than 
> fixed?
>

what about making it fixed of 47 bits from the start?


> Remember, there are no second chances: if we botch the initial packet 
> layouts we'll have to live with them for a long time.
>
>>      * Adopt HIP parameter format for options; HIP parameter format
>>        defines length in bytes but guarantees 64-bit alignment.
>
> I don't want this alignment. It wastes space, it's an implementation 
> headache and it buys us nothing.
>

i think that this is a small price to pay to allow future convergence 
with hip that is anther protocol somehow related with shim6

>> 11. Proposed to drop specific mechanism for locator test and response
>
> ???
>
>> 13. [What are privacy requirements for locator lists? Also integrity 
>> - this
>>      protocol is currently "in the clear".]
>
> One person's privacy is the next person's debugging nightmare.
>
> There is no privacy in today's multihoming either.
>
>> 14. View forking as a unidirectional context state fork (based on a 
>> ULP
>>     signal) that assumes that the forked context state may then use a
>>     different outgoing locator pair.
>
> Forking is a bad idea, it increases the complexity of the shim 
> manifold while pretty much the same functionality can also be provided 
> in a different way.

i guess it depends on how you handle it... i mean for me, i see it just 
as multiple contexts with the same ulid pair, but with different 
context tag. In this view, it doesn't seems very complex, it is just 
multiple contexts..., am i missing something?

>
>> 16. SHIM6 control message sequence numbers are not needed here. 
>> [control
>>     messages]
>
> My reachability/failure detection draft has sequence numbers of its 
> own in the reachability probes.
>

right
locator sets also have the generation number which is a seq number
i guess that the point is that the protocol as a whole does not have 
seq numbers, like first packet I1 with seq number 1, next packet I2 seq 
number 2 and so on...

>> 18. Use a statically specified in the initial protocol specification 
>> of
>>     (10) seconds.
>
> This means that senders must transmit something (data, keepalive) 
> every 10 seconds, right? So the receiver needs to wait a bit LONGER 
> than 10 seconds to time out.
>

as i recall it, 10 seconds was the time of 3 packets i.e. a node is 
expected to send packets every 3 seconds, so if 3 packets are missing, 
then we have a problem detected.

> Note that the tradeoff is:
>
> < 240 seconds: we MUST repair the problem before TCP times out
> > 180 seconds: wait for BGP (90 - 180 second timeout) to fix the 
> problem
> < 90 & > 40 seconds: don't wait for BGP, but do wait for OSPF (40 
> second timeout) to fix the problem
> < 40 seconds: don't wait for OSPF
>

are you suggesting that we change this to a higher value? i think that 
this was one proposal, and i think that it can be easily changed...

regards, marcelo