Subject: Re: comments on draft-ietf-shim6-proto-05.txt {3}
From: Deguang Le <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: [email-masked]
Date: Thu, 30 Nov 2006 20:34:26 +0100

Hi Marcelo,
I am sorry for my late response.
Thanky you very much!
See my comments inline... :-)

marcelo bagnulo braun schrieb:

> Hi Deguang,
> 
> El 15/10/2006, a las 15:24, Deguang Le escribió:
> 
>> Hi all,
>> a slight comment on the Context Tag...
>>
>> -Page50
>>    o  The context tag used to transmit control messages and payload
>>       extension headers - allocated by the peer; CT(peer)
>> -Page51
>>    o  The context to expect in received control messages and payload
>>       extension headers - allocated by the local host; CT(local)
>>
>> In page 50 and 51, two parameters, namely CT(peer) and CT(local), are 
>> defined for each ULID-pair context. right?
>>
>> However, in page 13, the terminology of CT is given as follows:
>>    Context tag         Each end of the context allocates a context tag
>>                        for the context.  This is used to uniquely
>>                        associate both received control packets and
>>                        payload extension headers as belonging to the
>>                        context.
>>
>> Based on my understanding of above CT terminology, for a given 
>> context, there is only "A" unique context tag used to identify the 
>> context (i.e. the ULID-pair context, right?).
>>
> 
> no, the above terminology states that _each_ end of the context 
> allocates one context tag. since there are two ends in a shim context, 
> this sums two context tags, right? CT(peer) and CT(local)
You are right.
Thank you very much! I think I understand what the two CTs means and
their usages now.
You mean each established shim6 context is identified by two CTs (i.e. a
peer CT and a local CT) in fact, and the values of these two CTs are
different. Right? :-)

However, I wonder why two endpoints can not negotiate "a" CT to
establish and identify a shim6 context. Is it not feasible to establish
a shim6 context if only "one" CT is used for identifying a context?

Cheers,
Deguang

> 
> Regards, marcelo
> 
> 
>> Therfore, I am confused why each ULID-pair context needs these "TWO" 
>> context tags: CT(peer) and CT(local)? Are the CT(peer) and the 
>> CT(local) the same thing (or are they the same 47-bit number?)in essence?
>>
>>
>> Have a nice weekend!
>> Cheers,
>> Deguang
>>
>>
>>
>>
>>
> 

Delivery-date: Fri, 24 Nov 2006 12:57:55 +0000
Cc: Erik Nordmark <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: draft-ietf-shim6-proto-06 : Context confusion
Date: Fri, 24 Nov 2006 13:06:43 +0100
To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>

Hi,

El 23/11/2006, a las 20:52, S=E9bastien Barr=E9 escribi=F3:

> marcelo bagnulo braun wrote:
>>
>> El 22/11/2006, a las 23:38, Erik Nordmark escribi=F3:
>>
>>> S=E9bastien Barr=E9 wrote:
>>>
>>>> Now, there is an extreme solution for both cases :
>>>> - if following current spec, send all locators, then tune with=20
>>>> locators preferences (as proposed earlier in this mail)
>>>
>>> Why is this "extreme" in your mind?
>>> That's how the protocol is designed AFAICT.
>>>
>>>> - if supporting scenario 1, having a local configuration that=20
>>>> enforces
>>>> disjoint locator sets to stay disjoint during the whole life of the=20=

>>>> system. This seems to be more or less the solution of virtual=20
>>>> hosts, and could probably be dealt with entirely as an=20
>>>> implementation problem (because the requirement to check the=20
>>>> context tag *and* the destination locator could then be replaced by=20=

>>>> the use of separate context tag spaces).
>>>
>>> That seems like a sensible (and not "extreme") approach to me.
>>>
>>
>> i am ok with this option, just wanted to verify that we are all on=20
>> the same on this....
>>
>> does anyone has a problem with this approach?
> - I think I am more or less ok with this option, too. The only problem=20=

> I see is that for privacy reasons (for example, maybe there are other=20=

> reasons), a host might want to hide some of his addresses to certain=20=

> peers, while showing them to other peers. If this can be statically=20
> configured, then the (implementable) virtual host is sufficient.
> But in this case, it will be *prohibited* by the specification to ever=20=

> announce addresses from both sets. What I want to emphasize is that if=20=

> a host decides to separate addresses by using a virtual host concept,=20=

> it will be absolutely impossible next (unless changing the global=20
> configuration, and accepting possible unrecoverable context=20
> confusions) to mix the two sets. I see this like a limitation, but if=20=

> everyone agrees with that, I won't insist more... :-)

i think that the point w.r.t. to privacy is interesting, however, i=20
think we should send this asap as we agreed in san diego.
So i will suggest that we send the draft in its current form and if=20
some more people thinks this is an issue, we can address it with the=20
issues that will probably show during the iesg review, ok?

> - Another, less problematic, thing, is that probably it could be=20
> useful to clearly specify somewhere in the draft the requirement to=20
> send all locators to all peers (As I discovered this requirement only=20=

> by deduction after careful analysis). Or is it already done ?

the draft states that:
    The confusion can be detected when I2/I2bis/R2 is received since we
    require that those messages MUST include a sufficiently large set of
    locators in a Locator List option that the peer can determine =
whether
    or not two contexts have the same host as the peer by comparing if
    there is any common locators in Ls(peer).

this is a weaker limitation that including the complete sets but this=20
is what is needed afaict. including all the locators, would of course=20
do the trick, but is not necesarily needed.

>>
>>
>> (i will be shipping the next version of the draft this weekend, i am=20=

>> already one week late from what we agreed on san diego :-(
> yes, my apologies to have sent my comments so late...
>

your comments are very helpful and please send more

thanks, marcelo

> regards,
>
> S=E9bastien.
>>
>> Regards, marcelo
>>
>>
>>>    Erik
>>>
>>>
>>>
>>
>

Delivery-date: Thu, 23 Nov 2006 19:54:42 +0000
Date: Thu, 23 Nov 2006 20:52:07 +0100
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Erik Nordmark <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: draft-ietf-shim6-proto-06 : Context confusion

marcelo bagnulo braun wrote:
>
> El 22/11/2006, a las 23:38, Erik Nordmark escribió:
>
>> Sébastien Barré wrote:
>>
>>> Now, there is an extreme solution for both cases :
>>> - if following current spec, send all locators, then tune with 
>>> locators preferences (as proposed earlier in this mail)
>>
>> Why is this "extreme" in your mind?
>> That's how the protocol is designed AFAICT.
>>
>>> - if supporting scenario 1, having a local configuration that enforces
>>> disjoint locator sets to stay disjoint during the whole life of the 
>>> system. This seems to be more or less the solution of virtual hosts, 
>>> and could probably be dealt with entirely as an implementation 
>>> problem (because the requirement to check the context tag *and* the 
>>> destination locator could then be replaced by the use of separate 
>>> context tag spaces).
>>
>> That seems like a sensible (and not "extreme") approach to me.
>>
>
> i am ok with this option, just wanted to verify that we are all on the 
> same on this....
>
> does anyone has a problem with this approach?
- I think I am more or less ok with this option, too. The only problem I 
see is that for privacy reasons (for example, maybe there are other 
reasons), a host might want to hide some of his addresses to certain 
peers, while showing them to other peers. If this can be statically 
configured, then the (implementable) virtual host is sufficient.
But in this case, it will be *prohibited* by the specification to ever 
announce addresses from both sets. What I want to emphasize is that if a 
host decides to separate addresses by using a virtual host concept, it 
will be absolutely impossible next (unless changing the global 
configuration, and accepting possible unrecoverable context confusions) 
to mix the two sets. I see this like a limitation, but if everyone 
agrees with that, I won't insist more... :-)
- Another, less problematic, thing, is that probably it could be useful 
to clearly specify somewhere in the draft the requirement to send all 
locators to all peers (As I discovered this requirement only by 
deduction after careful analysis). Or is it already done ?
>
>
> (i will be shipping the next version of the draft this weekend, i am 
> already one week late from what we agreed on san diego :-(
yes, my apologies to have sent my comments so late...

regards,

Sébastien.
>
> Regards, marcelo
>
>
>>    Erik
>>
>>
>>
>

Delivery-date: Thu, 23 Nov 2006 10:59:46 +0000
Cc: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: draft-ietf-shim6-proto-06 : Context confusion
Date: Thu, 23 Nov 2006 11:58:15 +0100
To: Erik Nordmark <[email-masked]>

El 22/11/2006, a las 23:38, Erik Nordmark escribi=F3:

> S=E9bastien Barr=E9 wrote:
>
>> Now, there is an extreme solution for both cases :
>> - if following current spec, send all locators, then tune with=20
>> locators preferences (as proposed earlier in this mail)
>
> Why is this "extreme" in your mind?
> That's how the protocol is designed AFAICT.
>
>> - if supporting scenario 1, having a local configuration that =
enforces
>> disjoint locator sets to stay disjoint during the whole life of the=20=

>> system. This seems to be more or less the solution of virtual hosts,=20=

>> and could probably be dealt with entirely as an implementation=20
>> problem (because the requirement to check the context tag *and* the=20=

>> destination locator could then be replaced by the use of separate=20
>> context tag spaces).
>
> That seems like a sensible (and not "extreme") approach to me.
>

i am ok with this option, just wanted to verify that we are all on the=20=

same on this....

does anyone has a problem with this approach?

(i will be shipping the next version of the draft this weekend, i am=20
already one week late from what we agreed on san diego :-(

Regards, marcelo

>    Erik
>
>
>

Delivery-date: Wed, 22 Nov 2006 22:39:12 +0000
Date: Wed, 22 Nov 2006 14:38:37 -0800
From: Erik Nordmark <[email-masked]>
To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: draft-ietf-shim6-proto-06 : Context confusion

S=E9bastien Barr=E9 wrote:

> Now, there is an extreme solution for both cases :
> - if following current spec, send all locators, then tune with locators=
=20
> preferences (as proposed earlier in this mail)

Why is this "extreme" in your mind?
That's how the protocol is designed AFAICT.

> - if supporting scenario 1, having a local configuration that enforces
> disjoint locator sets to stay disjoint during the whole life of the=20
> system. This seems to be more or less the solution of virtual hosts, an=
d=20
> could probably be dealt with entirely as an implementation problem=20
> (because the requirement to check the context tag *and* the destination=
=20
> locator could then be replaced by the use of separate context tag space=
s).

That seems like a sensible (and not "extreme") approach to me.

    Erik

Delivery-date: Wed, 22 Nov 2006 22:38:04 +0000
Date: Wed, 22 Nov 2006 14:35:59 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: draft-ietf-shim6-proto-06 : Context confusion

marcelo bagnulo braun wrote:

> We have a single stack A with 4 addresses, A1, A2, A3 and A4.
> Suppose this host A wants to establish a two contexts: one with node B 
> and another one with node C and A wants to include the following locator 
> sets:
> 
> context 1 between A and B : Ls(A1,A2)
> context 2 between A and C : Ls(A3,A4)
> 
> As i understand the current draft this is not supported because we are 
> requiring that all the locator sets that A uses in its shim context must 
> be non disjoint

We do require that I2/I2bis/R2 include essentially the full locator set.

But what problem are we trying to solve by changing this?

A host can express its preferences among those locators already.
Is it that the I2/I2bis/R2 packets are too big? Something else?

The reason we need to understand the problem we are trying to solve by 
changing this is that any change will add complexity to shim6. And I 
frankly think it is sufficiently complex already. (Not that I know of a 
way to reduce the complexity and satisfy the same set of requirements, 
but I would want to think very carefully before adding new requirements.)

Should we have consensus to add more flexibility in this area, I 
wouldn't be surprised if the lowest complexity addition is simply to 
avoid context confusion by adding the CLOSE timers and messages that HIP 
uses. With those we have an upper bound on how long A and B can be out 
of synch (with one having retained the state and the other having 
discarded it).

    Erik

Delivery-date: Wed, 22 Nov 2006 19:15:17 +0000
Date: Wed, 22 Nov 2006 19:05:55 +0100
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: draft-ietf-shim6-proto-06 : Context confusion

Hi Marcelo, Erik,

Thanks for these detailed answers.
see below...

marcelo bagnulo braun wrote:
> Hi Erik,
>
> El 22/11/2006, a las 2:22, Erik Nordmark escribió:
>
>> marcelo bagnulo braun wrote:
>>
>>> So as i see it, there are two different scenarios that are not 
>>> supported today and that we can update the spec to support:
>>> - scenario 1: i call it virtual hosts. the supported feature here is 
>>> to support the case of establishing context with the same peer with 
>>> disjoint locator sets. For instance the scenario above where host A 
>>> has locators A1 and A2 and host B has locators B1, B2, B3, B4 and to 
>>> be able to estbalish two contexts A1,B1/B2 and another context with 
>>> A2,B3/B4. In this case A and B would have something like two virtual 
>>> hosts and they cannot merge. i.e. it is not possible that B adds B1 
>>> to the second context
>>
>> Isn't this entirely an implementation matter? I run several Solaris 
>> zones on my laptop today each with disjoint sets of IP addresses, and 
>> no IETF standard had to be clarified to make that possible.
>> What is important for a virtual host is that the IP stacks be 
>> completely disjoint so that there can never be any confusion, but 
>> that is an implementation matter.
>>
>
> ok, maybe the calling them virtual hosts was not a good idea.
>
> Let me rephrase the scenario and see if we agree on supporting it or not
>
> We have a single stack A with 4 addresses, A1, A2, A3 and A4.
> Suppose this host A wants to establish a two contexts: one with node B 
> and another one with node C and A wants to include the following 
> locator sets:
>
> context 1 between A and B : Ls(A1,A2)
> context 2 between A and C : Ls(A3,A4)
>
> As i understand the current draft this is not supported because we are 
> requiring that all the locator sets that A uses in its shim context 
> must be non disjoint
>
> My understanding was that we we didn't mean not to support the above 
> described scenario....
> am i reading the draft correctly when i say that the current spec 
> doesn't support this?
> if so, should we support this case?
That was also my understanding : section 7.6 was requiring to have an 
intersection between each pair of locator sets announced to peers (as 
well described in Marcelo's previous mail). As I understand it, this 
would prohibit the above scheme of communication.
I also fully agree with Marcelo's solution to scenario 1, that is  :
----
In order to support scenario 1, we would need to process incoming 
payload packets considering both the context tag and the locator pair 
and we would need to soften the MUST included above to soemthing like: 
If two context have disjoint locator sets at the moment of the context 
establishemnt, then they must always be disjoint. We need to phrase this 
very precisely, in order to be able to cope with loosing contexts and so 
on. (another way to describe it would be to include a section about 
virtual hosts, meaning that it is possible to support virtual hosts as 
long as they don't merge)
----

I think also that part of this topic is an implementation issue, but 
there is also an implication on the check for incoming packets, which is 
worth mentioning in the draft, in the case we decide to support it :
So, I think the draft should be made clearer about :
- whether the above scheme (scenario 1) is supported.
- In such case, what are the checks to do in order to prevent context 
confusion when disjoint locator sets are used.

Regarding the first point, my opinion is that indeed scenario 1 is 
useful, because it allows applications (using some API) to choose 
dedicated locator sets for certain types of communication. Nevertheless, 
if it proves too hard to support this as is, we could just specify that 
the 'scenario 1' feature is not supported, and let as an implementation 
matter to find a workaround for supporting this kind of dedicated sets. 
(For example by tuning locators preferences).

And regarding the second point (what to do to support scenario 1), we 
should then, as aforementioned, check the destination address for 
incoming packets against the peer locator. But as stated in Marcelo's  
text above, there is a need to think more about what to do if one of two 
disjoint contexts disappears.

Put more generally, I think there is a common problem in either 
situation (current spec or scenario 1), which is to deal with limited 
subsets of locators.
In current spec, the simplest case for assuring that locators sets are 
not disjoint  is to always send *all* locators to every peer, then 
tuning preferences. This is the simplest for avoiding context confusion 
the 'standard' way.

Now, if we want to deal with limited subsets of locators, there is in 
both cases the following problem :
- B creates a locator set L_1, then drops it. Maybe the peer has still 
the corresponding context in memory.
- Later it creates a second context with the same peer (but we don't 
know it is the same peer, since we just dropped the previous context). 
The problem now is that
        *if following the spec, we MUST have overlapping locator set 
with the previous one.
       * if supporting scenario 1, we MUST have a locator set which is 
disjoint with the previous one.
The problem in both cases is that we have precisely dropped the previous 
context and don't know what the previous locator set was.

Now, there is an extreme solution for both cases :
- if following current spec, send all locators, then tune with locators 
preferences (as proposed earlier in this mail)
- if supporting scenario 1, having a local configuration that enforces 
disjoint locator sets to stay disjoint during the whole life of the 
system. This seems to be more or less the solution of virtual hosts, and 
could probably be dealt with entirely as an implementation problem 
(because the requirement to check the context tag *and* the destination 
locator could then be replaced by the use of separate context tag spaces).

Do you agree with this problem of sending subsets of locators ? (also in 
the current spec). In fact that was the initial thing i didn't like very 
much, but maybe this option it to complicated to deal with. But in such 
case, i suppose it could be useful to clearly specify in the draft that 
all locators must be sent to all peers, in order for context confusion 
to be properly avoided.

A last idea : I am thinking now that, worse, one might one to hide some 
locators to some peers. This would be impossible if i am not in the 
wrong way with the previous paragraph...

>
>
>>> -scenario 2: host merging. In this case it is possible that B adds 
>>> B1 to the second context
>>
>> Why would we want to support this in any other way than we do today 
>> in the spec? Any solution I've thought of would be quite complex.
>>
>
> I am not proposing supporting this, just wanted to verify that the 
> agree on not supporting this, specially after the note from Sebastien
>
> I am ok with not supporting this scenario
>
> Regards, marcelo
I also don't see scenario 2 as sufficiently useful to be worth 
supporting in the spec.

regards,

Sébastien.

>
>
>> Do we want this because we think the 47 bits of context tag is 
>> insufficient? Or is there some other motivation?
>>
>>    Erik
>>
>>
>>> In order to support scenario 1, we would need to process incoming 
>>> payload packets considering both the context tag and the locator 
>>> pair and we would need to soften the MUST included above to 
>>> soemthing like: If two context have disjoint locator sets at the 
>>> moment of the context establishemnt, then they must always be 
>>> disjoint. We need to phrase this very precisely, in order to be able 
>>> to cope with loosing contexts and so on. (another way to describe it 
>>> would be to include a section about virtual hosts, meaning that it 
>>> is possible to support virtual hosts as long as they don't merge)
>>> In order to support scenario 2 we need to modify quite a few things 
>>> in the spec. In particular what do we do when the hosts merge 
>>> through an UPDATe message and what do we do with the resulting 
>>> contexts if they have the same context tag allocated. This would be 
>>> quite hard to support. One option would be to renogotiate the 
>>> context tag, but this would be quite complex. the other option would 
>>> be to refuse the update messge, but we woud need to define a message 
>>> to reject an UPDATe message.
>>> So, imho, we may consider supporting the first case of virtual hosts 
>>> (it would imply some rewriting of the spec though) but i don't think 
>>> that it would be good idea to support the  second case, of merging 
>>> hosts....
>>> opinions?
>>> Regards, marcelo
>>>> 2. After some time, host B drops the first context.
>>>> 3. Now he wants to create another one : <A1,B3/B4> with CTx.
>>>> ----
>>>>
>>>> When A receives the I2 message from B, it is not able (as should 
>>>> be) to detect that it is speaking with the same host, as the 
>>>> locator sets are disjoint. As a consequence, the context in A with 
>>>> CT(peer)=CTx will not be discarded. We are now in the situation of 
>>>> A possibly sending packets to both the discarded context <A1,B1/B2> 
>>>> and the newly created one <A1, B3/B4>, using CTx in both cases.
>>>> IMHO, this can be detected by B, and should be stated in the draft 
>>>> as another case of confusion detection (in fact both confusion and 
>>>> context loss detection). For this to be done, section 12.1 could be 
>>>> slightly changed, to say that a receiver MUST NOT assume that a 
>>>> packet with the shim6 payload extension header and a context tag 
>>>> matching with a context is really attached to the context. Rather, 
>>>> to verify this, the source locator must be checked against Ls(peer) :
>>>> o if the source locator is included in Ls(peer), usual translation 
>>>> is done.
>>>> o if the source locator is not included in Ls(peer), then probably 
>>>> this packet belongs to an old, dropped context, and an R1bis 
>>>> message MUST be sent in this case, in order to recover the 
>>>> previously discarded context (in my example <A1,B1/B2>).
>>>>
>>>> I hope this proposal is clearer and more realistic than the one 
>>>> described in my previous mail.
>>>>
>>>> Thanks for any comment,
>>>>
>>>> Sébastien.
>>>>
>>
>>
>

Delivery-date: Wed, 22 Nov 2006 14:29:04 +0000
Cc: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: draft-ietf-shim6-proto-06 : Context confusion
Date: Wed, 22 Nov 2006 15:27:41 +0100
To: Erik Nordmark <[email-masked]>

Hi Erik,

El 22/11/2006, a las 2:22, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>> So as i see it, there are two different scenarios that are not=20
>> supported today and that we can update the spec to support:
>> - scenario 1: i call it virtual hosts. the supported feature here is=20=

>> to support the case of establishing context with the same peer with=20=

>> disjoint locator sets. For instance the scenario above where host A=20=

>> has locators A1 and A2 and host B has locators B1, B2, B3, B4 and to=20=

>> be able to estbalish two contexts A1,B1/B2 and another context with=20=

>> A2,B3/B4. In this case A and B would have something like two virtual=20=

>> hosts and they cannot merge. i.e. it is not possible that B adds B1=20=

>> to the second context
>
> Isn't this entirely an implementation matter? I run several Solaris=20
> zones on my laptop today each with disjoint sets of IP addresses, and=20=

> no IETF standard had to be clarified to make that possible.
> What is important for a virtual host is that the IP stacks be=20
> completely disjoint so that there can never be any confusion, but that=20=

> is an implementation matter.
>

ok, maybe the calling them virtual hosts was not a good idea.

Let me rephrase the scenario and see if we agree on supporting it or not

We have a single stack A with 4 addresses, A1, A2, A3 and A4.
Suppose this host A wants to establish a two contexts: one with node B=20=

and another one with node C and A wants to include the following=20
locator sets:

context 1 between A and B : Ls(A1,A2)
context 2 between A and C : Ls(A3,A4)

As i understand the current draft this is not supported because we are=20=

requiring that all the locator sets that A uses in its shim context=20
must be non disjoint

My understanding was that we we didn't mean not to support the above=20
described scenario....
am i reading the draft correctly when i say that the current spec=20
doesn't support this?
if so, should we support this case?

>> -scenario 2: host merging. In this case it is possible that B adds B1=20=

>> to the second context
>
> Why would we want to support this in any other way than we do today in=20=

> the spec? Any solution I've thought of would be quite complex.
>

I am not proposing supporting this, just wanted to verify that the=20
agree on not supporting this, specially after the note from Sebastien

I am ok with not supporting this scenario

Regards, marcelo

> Do we want this because we think the 47 bits of context tag is=20
> insufficient? Or is there some other motivation?
>
>    Erik
>
>
>> In order to support scenario 1, we would need to process incoming=20
>> payload packets considering both the context tag and the locator pair=20=

>> and we would need to soften the MUST included above to soemthing=20
>> like: If two context have disjoint locator sets at the moment of the=20=

>> context establishemnt, then they must always be disjoint. We need to=20=

>> phrase this very precisely, in order to be able to cope with loosing=20=

>> contexts and so on. (another way to describe it would be to include a=20=

>> section about virtual hosts, meaning that it is possible to support=20=

>> virtual hosts as long as they don't merge)
>> In order to support scenario 2 we need to modify quite a few things=20=

>> in the spec. In particular what do we do when the hosts merge through=20=

>> an UPDATe message and what do we do with the resulting contexts if=20
>> they have the same context tag allocated. This would be quite hard to=20=

>> support. One option would be to renogotiate the context tag, but this=20=

>> would be quite complex. the other option would be to refuse the=20
>> update messge, but we woud need to define a message to reject an=20
>> UPDATe message.
>> So, imho, we may consider supporting the first case of virtual hosts=20=

>> (it would imply some rewriting of the spec though) but i don't think=20=

>> that it would be good idea to support the  second case, of merging=20
>> hosts....
>> opinions?
>> Regards, marcelo
>>> 2. After some time, host B drops the first context.
>>> 3. Now he wants to create another one : <A1,B3/B4> with CTx.
>>> ----
>>>
>>> When A receives the I2 message from B, it is not able (as should be)=20=

>>> to detect that it is speaking with the same host, as the locator=20
>>> sets are disjoint. As a consequence, the context in A with=20
>>> CT(peer)=3DCTx will not be discarded. We are now in the situation of =
A=20
>>> possibly sending packets to both the discarded context <A1,B1/B2>=20
>>> and the newly created one <A1, B3/B4>, using CTx in both cases.
>>> IMHO, this can be detected by B, and should be stated in the draft=20=

>>> as another case of confusion detection (in fact both confusion and=20=

>>> context loss detection). For this to be done, section 12.1 could be=20=

>>> slightly changed, to say that a receiver MUST NOT assume that a=20
>>> packet with the shim6 payload extension header and a context tag=20
>>> matching with a context is really attached to the context. Rather,=20=

>>> to verify this, the source locator must be checked against Ls(peer)=20=

>>> :
>>> o if the source locator is included in Ls(peer), usual translation=20=

>>> is done.
>>> o if the source locator is not included in Ls(peer), then probably=20=

>>> this packet belongs to an old, dropped context, and an R1bis message=20=

>>> MUST be sent in this case, in order to recover the previously=20
>>> discarded context (in my example <A1,B1/B2>).
>>>
>>> I hope this proposal is clearer and more realistic than the one=20
>>> described in my previous mail.
>>>
>>> Thanks for any comment,
>>>
>>> S=E9bastien.
>>>
>
>

Delivery-date: Wed, 22 Nov 2006 01:23:59 +0000
Date: Tue, 21 Nov 2006 17:22:11 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: draft-ietf-shim6-proto-06 : Context confusion

marcelo bagnulo braun wrote:

> So as i see it, there are two different scenarios that are not supporte=
d=20
> today and that we can update the spec to support:
>=20
> - scenario 1: i call it virtual hosts. the supported feature here is to=
=20
> support the case of establishing context with the same peer with=20
> disjoint locator sets. For instance the scenario above where host A has=
=20
> locators A1 and A2 and host B has locators B1, B2, B3, B4 and to be abl=
e=20
> to estbalish two contexts A1,B1/B2 and another context with A2,B3/B4. I=
n=20
> this case A and B would have something like two virtual hosts and they =

> cannot merge. i.e. it is not possible that B adds B1 to the second cont=
ext

Isn't this entirely an implementation matter? I run several Solaris=20
zones on my laptop today each with disjoint sets of IP addresses, and no =

IETF standard had to be clarified to make that possible.
What is important for a virtual host is that the IP stacks be completely =

disjoint so that there can never be any confusion, but that is an=20
implementation matter.

> -scenario 2: host merging. In this case it is possible that B adds B1 t=
o=20
> the second context

Why would we want to support this in any other way than we do today in=20
the spec? Any solution I've thought of would be quite complex.

Do we want this because we think the 47 bits of context tag is=20
insufficient? Or is there some other motivation?

    Erik

> In order to support scenario 1, we would need to process incoming=20
> payload packets considering both the context tag and the locator pair=20
> and we would need to soften the MUST included above to soemthing like: =

> If two context have disjoint locator sets at the moment of the context =

> establishemnt, then they must always be disjoint. We need to phrase thi=
s=20
> very precisely, in order to be able to cope with loosing contexts and s=
o=20
> on. (another way to describe it would be to include a section about=20
> virtual hosts, meaning that it is possible to support virtual hosts as =

> long as they don't merge)
>=20
> In order to support scenario 2 we need to modify quite a few things in =

> the spec. In particular what do we do when the hosts merge through an=20
> UPDATe message and what do we do with the resulting contexts if they=20
> have the same context tag allocated. This would be quite hard to=20
> support. One option would be to renogotiate the context tag, but this=20
> would be quite complex. the other option would be to refuse the update =

> messge, but we woud need to define a message to reject an UPDATe messag=
e.
>=20
> So, imho, we may consider supporting the first case of virtual hosts (i=
t=20
> would imply some rewriting of the spec though) but i don't think that i=
t=20
> would be good idea to support the  second case, of merging hosts....
>=20
> opinions?
>=20
> Regards, marcelo
>=20
>=20
>=20
>> 2. After some time, host B drops the first context.
>> 3. Now he wants to create another one : <A1,B3/B4> with CTx.
>> ----
>>
>> When A receives the I2 message from B, it is not able (as should be)=20
>> to detect that it is speaking with the same host, as the locator sets =

>> are disjoint. As a consequence, the context in A with CT(peer)=3DCTx=20
>> will not be discarded. We are now in the situation of A possibly=20
>> sending packets to both the discarded context <A1,B1/B2> and the newly=
=20
>> created one <A1, B3/B4>, using CTx in both cases.
>> IMHO, this can be detected by B, and should be stated in the draft as =

>> another case of confusion detection (in fact both confusion and=20
>> context loss detection). For this to be done, section 12.1 could be=20
>> slightly changed, to say that a receiver MUST NOT assume that a packet=
=20
>> with the shim6 payload extension header and a context tag matching=20
>> with a context is really attached to the context. Rather, to verify=20
>> this, the source locator must be checked against Ls(peer) :
>> o if the source locator is included in Ls(peer), usual translation is =

>> done.
>> o if the source locator is not included in Ls(peer), then probably=20
>> this packet belongs to an old, dropped context, and an R1bis message=20
>> MUST be sent in this case, in order to recover the previously=20
>> discarded context (in my example <A1,B1/B2>).
>>
>> I hope this proposal is clearer and more realistic than the one=20
>> described in my previous mail.
>>
>> Thanks for any comment,
>>
>> S=E9bastien.
>>
>=20
>=20

Delivery-date: Tue, 21 Nov 2006 15:56:07 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: draft-ietf-shim6-proto-06 : Sending R2 in I2-SENT state
Date: Tue, 21 Nov 2006 16:55:59 +0100
To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>

Hi Sebastien,

El 09/11/2006, a las 19:23, S=E9bastien Barr=E9 escribi=F3:

> Hi,
>
> I have still a question regarding the proto draft. I'm sorry to post=20=

> it so late, I was delayed in re-reading the draft in depth, and could=20=

> not be present at IETF meeting. So, here is :
>
> (p76) In section 10.4, it is stated that upon reception of an update=20=

> request and if the state is I2-SENT or I2bis-SENT, we need to reply=20
> with an R2 then process the update. I agree with processing the update=20=

> request, but I don't understand why to send an R2 : If the responder=20=

> is in established state, it will anyway drop the R2. And I suppose=20
> that if the responder sent an update request, this implies that it is=20=

> already in established state.
>
> I suppose that you have a good reason of doing this, because I see in=20=

> section 12.1 that in state I2-SENT, if payload is received, an R2 must=20=

> also be sent (which I see equally as useless, since silently discarded=20=

> by the peer). Also, in section 10.5, the same behaviour is defined.=20
> Can you explain the reason for this ?

> btw,  in appendix B, the simplified state machine is inconsistent with=20=

> the text, saying that in I2-SENT state, an I2 (not an R2) must be=20
> replied to payload extension header packets, because the peer probably=20=

> has sent an R2 which was lost. This appears to me more appropriate=20
> than what is said in sections 10.4, 10.5 and 12.1.

this is the correct behaviour, but it seems that i corrected one place=20=

and not the other....

the idea is that if a peer is in I2-SENT/I2bis-SENT state it means that=20=

it hasn't received a R2 message back, so it can move to ESTABLISHED=20
state, right?

So, if the other peer is in ESTABLISHED state and is sending=20
UPDATE/payload, this basically means that the R2 message was lost, ok?
So we need the peer to retransmit the I2/I2bis message again so that=20
the peer retransmit the R2 message

i will fix this,

thanks marcelo

> otoh, the simplified state machine diagram in appendix B.1 agrees with=20=

> the text (so disagrees with appendix B).
>
> S=E9bastien.
>
> --=20
> S=E9bastien Barr=E9
> Researcher,
> CSE department, UCLouvain, Belgium
>

Delivery-date: Tue, 21 Nov 2006 15:29:25 +0000
Cc: shim6-wg <[email-masked]>, Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: draft-ietf-shim6-proto-06 : Context confusion
Date: Tue, 21 Nov 2006 16:23:30 +0100
To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>

Hi Sebastien,

sorry for the long delay and thank you for your feedback

i think you raise an interesting point here....
below...

El 08/11/2006, a las 14:27, S=E9bastien Barr=E9 escribi=F3:

> Hi,
>
> I think that in the previous mail, I had not well in mind the fact=20
> that the only way for a host to have multiple own context tags is to=20=

> first drop one context, then create a new one with the same context=20
> tag, so that in any case, there is only one possible context for the=20=

> context tag, with still the possibility of having packets arriving to=20=

> the newly created context, but addressed to the dropped context.
>
> With this in mind, I understand better the interest of having=20
> non-overlapping locators sets. This way we can work as if the two (or=20=

> more) locator sets were corresponding to different machines.
>
> But in this case the following sentence should probably be adapted a=20=

> bit (section 7.6):
> ----
> The confusion can be detected when I2/I2bis/R2 is received since we
>  require that those messages MUST include a sufficiently large set of
>  locators in a Locator List option that the peer can determine whether
>  or not two contexts have the same host as the peer by comparing if
>  there is any common locators in Ls(peer).
> ----
> Now, we could consider the case of a single host with multiple=20
> disjoint locator sets being seen by its pair as multiple hosts. This=20=

> is without problem except a little subtlety. Here is the adapted=20
> example of the previous mail :
> ----
> 1. host A has two contexts with host B, one with the set of locators=20=

> <A1,B1/B2> and CTx, the other with <A2,B3/B4> and CTy.

this situation is not supported in the current spec

in section 7.6.  Context confusion it is stated that:

    The confusion can be detected when I2/I2bis/R2 is received since we
    require that those messages MUST include a sufficiently large set of
    locators in a Locator List option that the peer can determine =
whether
    or not two contexts have the same host as the peer by comparing if
    there is any common locators in Ls(peer).

since B1/B2 is disjoint with B3/B4, this would be not complying with=20
the aforementioned MUST in the draft

However, i think it is a valid question whether we should or not=20
support this type of configuration...

I mean, this means that all pair of locator sets of all shim6 contexts=20=

of a host must be non disjoint

In other words, that if we take all the possible pairs of locators sets=20=

of existing contexts in a host, all of these must be non disjoint.

So, a scenario where a host B has 4 addresses B1,B2,B3,B4, it is not=20
possible that B establishes a context with B1,B2 and another context=20
with B3,B4, since they would be disjoint.

I may agree that this is an overkill and that we should lift this=20
limitation

An option to support this situation would be as you mention below, to=20
include the locator pair besides the context tag in the processing of=20
the incoming payload packets.
However, this by itself it is not enough to completely remove the need=20=

for the limitation above.

The limitation above is oriented to prevent the case of host merging.=20
This is the case when two contexts initially have disjoint contexts and=20=

then through an update message, a locator is added to one of the=20
context, resulting in a non disjoint locator set with an existing=20
context.

consider the  following case
the context A1,B1/B2 is created and B assigns CTx to this context
B looses the context
The context A2,B3/B4 is created and B reuses CTx
As you mention, this can be addressed if we add the locator pair and=20
the context tag to process payload packets.

Now what happen if B add locator B1 to the second context and A adds A1=20=

to the second context?

the result is that A will have two contexts:
A1,B1/B2 and
A1,A2,B1/B3/B4 both with the same CT(peer)=3DCTx, so when A sends =
packets=20
with the first context, they will flow with addresses A1,B1 and context=20=

CTx, fiting the second context and we have the problem again.

So as i see it, there are two different scenarios that are not=20
supported today and that we can update the spec to support:

- scenario 1: i call it virtual hosts. the supported feature here is to=20=

support the case of establishing context with the same peer with=20
disjoint locator sets. For instance the scenario above where host A has=20=

locators A1 and A2 and host B has locators B1, B2, B3, B4 and to be=20
able to estbalish two contexts A1,B1/B2 and another context with=20
A2,B3/B4. In this case A and B would have something like two virtual=20
hosts and they cannot merge. i.e. it is not possible that B adds B1 to=20=

the second context

-scenario 2: host merging. In this case it is possible that B adds B1=20
to the second context

In order to support scenario 1, we would need to process incoming=20
payload packets considering both the context tag and the locator pair=20
and we would need to soften the MUST included above to soemthing like:=20=

If two context have disjoint locator sets at the moment of the context=20=

establishemnt, then they must always be disjoint. We need to phrase=20
this very precisely, in order to be able to cope with loosing contexts=20=

and so on. (another way to describe it would be to include a section=20
about virtual hosts, meaning that it is possible to support virtual=20
hosts as long as they don't merge)

In order to support scenario 2 we need to modify quite a few things in=20=

the spec. In particular what do we do when the hosts merge through an=20
UPDATe message and what do we do with the resulting contexts if they=20
have the same context tag allocated. This would be quite hard to=20
support. One option would be to renogotiate the context tag, but this=20
would be quite complex. the other option would be to refuse the update=20=

messge, but we woud need to define a message to reject an UPDATe=20
message.

So, imho, we may consider supporting the first case of virtual hosts=20
(it would imply some rewriting of the spec though) but i don't think=20
that it would be good idea to support the  second case, of merging=20
hosts....

opinions?

Regards, marcelo

> 2. After some time, host B drops the first context.
> 3. Now he wants to create another one : <A1,B3/B4> with CTx.
> ----
>
> When A receives the I2 message from B, it is not able (as should be)=20=

> to detect that it is speaking with the same host, as the locator sets=20=

> are disjoint. As a consequence, the context in A with CT(peer)=3DCTx=20=

> will not be discarded. We are now in the situation of A possibly=20
> sending packets to both the discarded context <A1,B1/B2> and the newly=20=

> created one <A1, B3/B4>, using CTx in both cases.
> IMHO, this can be detected by B, and should be stated in the draft as=20=

> another case of confusion detection (in fact both confusion and=20
> context loss detection). For this to be done, section 12.1 could be=20
> slightly changed, to say that a receiver MUST NOT assume that a packet=20=

> with the shim6 payload extension header and a context tag matching=20
> with a context is really attached to the context. Rather, to verify=20
> this, the source locator must be checked against Ls(peer) :
> o if the source locator is included in Ls(peer), usual translation is=20=

> done.
> o if the source locator is not included in Ls(peer), then probably=20
> this packet belongs to an old, dropped context, and an R1bis message=20=

> MUST be sent in this case, in order to recover the previously=20
> discarded context (in my example <A1,B1/B2>).
>
> I hope this proposal is clearer and more realistic than the one=20
> described in my previous mail.
>
> Thanks for any comment,
>
> S=E9bastien.
>

Delivery-date: Fri, 17 Nov 2006 05:44:31 +0000
Content-class: urn:content-classes:message
Subject: option for setting non-default Keepalive Timeout in REAP
Date: Thu, 16 Nov 2006 21:41:48 -0800
From: "Henderson, Thomas R" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Cc: <[email-masked]>

Jari and Iljitsch,

As I mentioned at the mike at the meeting, I drafted some text to
suggest how shim6 nodes might notify a peer to use a non-default value
of the Keepalive Timeout interval.  In summary, it defines a new
Keepalive Timeout Option that can be sent in the I2, I2bis, R2, or
UPDATE packets.

There would need to be a Parameter Type allocated for this option; I
left it TBD.  There may need to be also a cross-reference in the
shim6-proto draft.

In the course of drafting the text, I noticed that the current draft was
a bit inconsistent in the use of Keepalive Timeout and Keepalive
Interval.  I took the liberty of trying to clarify and make consistent
what I thought was the intended behavior:  that multiple Keepalive
messages (spaced Keepalive Interval apart) may be sent during the
interval that Keepalive Timeout is running.  You should review these
changes to make sure that I did not change your intended behavior.

The below is a diff file against the -06 version that may be used also
as a patch -p0 file.

Regards,
Tom

--- draft-ietf-shim6-failure-detection-06.txt	2006-10-02
10:48:18.000000000 -0700
+++ draft-ietf-shim6-failure-detection-06.bis.txt	2006-11-16
21:32:18.000000000 -0800
@@ -83,6 +83,7 @@
    5.  Protocol Definition  . . . . . . . . . . . . . . . . . . . . .
14
        5.1.  Keepalive Message  . . . . . . . . . . . . . . . . . . .
14
        5.2.  Probe Message  . . . . . . . . . . . . . . . . . . . . .
15
+       5.3.  Keepalive Timeout Option . . . . . . . . . . . . . . . . ?
    6.  Behaviour  . . . . . . . . . . . . . . . . . . . . . . . . . .
20
    7.  Example Protocol Runs  . . . . . . . . . . . . . . . . . . . .
24
    8.  Protocol Constants . . . . . . . . . . . . . . . . . . . . . .
29
@@ -520,23 +521,26 @@
        packets from its peer but not sending any of its own.  The
        keepalives are sent at certain intervals so that the other side
        knows there is a reachability problem when it doesn't receive
any
-       incoming packets for 10 seconds, the Keepalive Timeout.
-       (Mechanisms to negotiate an alternative Keepalive Timeout may be
-       provided in the future.)
+       incoming packets for its Send Timeout period.  The host=20
+       communicates its Send Timeout value to the peer as an Keepalive
+       Timeout Option (section 5.3) in the I2, I2bis, R2, or UPDATE=20
+       messages.  The peer then maps this value to its Keepalive=20
+       Timeout value.
=20
        The interval after which keepalives are sent is named Keepalive
        Interval.  This document doesn't specify a value for Keepalive
        Interval, but recognizes that an often used approach is sending
-       keepalives at three times the timeout interval, which would be 3
-       seconds here, and suggest a possible alternative of 4 seconds so
-       that two keepalives are generated and have time to reach the
-       correspondent.  An upper bound would be 8 seconds, so that one
-       keepalive has time to reach the other side, assuming a maximum
-       one-way delay of 2 seconds.
+       keepalives at one-half to one-third of the Keepalive=20
+       Timeout interval, so that multiple keepalives are generated and=20
+       have time to reach the correspondent before it times out. =20
+       An upper bound on this interval would be (Keepalive Timeout - 2)

+       seconds, so that one keepalive has time to reach the other side,

+       assuming a maximum one-way delay of 2 seconds.
=20
    2.  Whenever outgoing data packets are generated, a timer is started
        to reflect the requirement that the peer should generate return
-       traffic from data packets.
+       traffic from data packets.  The timeout value is set to the=20
+       value of Send Timeout.
=20
        For the purposes of this specification, "data packet" refers to
        any packet that is part of a shim context, including both upper
@@ -546,7 +550,8 @@
    3.  Whenever incoming data packets are received, the timer
associated
        with the return traffic from the peer is stopped, and another
        timer is started to reflect the requirement for this node to
-       generate return traffic.
+       generate return traffic.  This timeout value is set to the
+       value of Keepalive Timeout.
=20
    4.  The reception of a REAP keepalive packet leads to stopping the
        timer associated with the return traffic from the peer.
@@ -566,18 +571,19 @@
        and transmitted to the correspondent.  A host may send the
        keepalive sooner than Keepalive Interval seconds if
        implementation considerations warrant this, but should take care
-       to avoid sending keepalives at an excessive rate.  After sending
-       a single keepalive message, no additional keepalive messages are
-       sent until a data packet is received within this shim context.
+       to avoid sending keepalives at an excessive rate.  REAP
keepalive
+       packets SHOULD continue to be sent at the Keepalive Interval
until
+       either a data packet in the shim context has been received from=20
+       the peer or the Keepalive Timeout expires.
        Keepalives are not sent at all when a data packet was sent since
        the last received data packet.
=20
-   6.  Send Timeout seconds (10 seconds; see Section 8) after the
+   6.  Send Timeout seconds after the
        transmission of a data packet with no return traffic on this
        context, a full reachability exploration is started.
=20
-   Note that the above timeout values are suggestions to be used as
-   defaults.  Experience from the deployment of the SHIM6 protocol is
+   Section 8 provides some suggested defaults for these timeout values.
+   Experience from the deployment of the SHIM6 protocol is
    needed in order to determine what values are most suitable.  The
    setting of these values is also related to various parameters in
    transport protocols, such as TCP keepalive interval.
@@ -1052,12 +1058,33 @@
       For future extensions.
=20
=20
+5.3.  Keepalive Timeout Option Format
=20
+   Either side of a shim6 context can notify the peer of the value
+   that it would prefer the peer to use as its Keepalive Timeout
+   value.  If the host is using a non-default Send Timeout value,
+   it SHOULD communicate this value as a Keepalive Timeout value
+   to the peer in the below option.  This option MAY be sent in
+   the I2, I2bis, R2, or UPDATE messages.  The option SHOULD only need=20
+   to be sent once in a given shim6 association.  If a host=20
+   receives this option it SHOULD update its Keepalive Timeout=20
+   value for the correspondent.
=20
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Type =3D TBD        |0|        Length  =3D 4            =
|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +           Reserved            |      Keepalive Timeout        |=20
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=20
+   Fields:
+=20
+   Reserved:       16-bit field reserved for future use.  Set to zero
+                   upon transmit and MUST be ignored upon receipt.
=20
-
-
+   Keepalive Timeout:   Value in seconds corresponding to suggested
+                        Keepalive Timeout value for the peer.
=20
=20
 Arkko & van Beijnum      Expires March 27, 2007                [Page
19]
@@ -1104,6 +1131,12 @@
    reception of SHIM6 control messages other than the Keepalive and
    Probe messages are treated similarly with payload packets.
=20
+   While the Keepalive timer is running, the node SHOULD send Keepalive
+   messages to the peer with an interval of Keepalive Interval seconds.
+   Conceptually, a separate timer is used to distinguish between the
+   interval between Keepalive messages and the overall Keepalive
Timeout
+   interval.
+
    When sending a Probe message, the State field MUST be set to a value
    that matches the conceptual state of the sender after sending the
    Probe.
@@ -1145,8 +1178,9 @@
      START Send;              -                      START Send
      STOP Keepalive
=20
-   Upon a timeout on the Keepalive timer the node sends a Keepalive
-   message.  This can only happen in the Operational state.
+   Upon a timeout on the Keepalive timer, the node cancels the timer
+   governing the sending of the next Keepalive message.  This can only=20
+   happen in the Operational state.
=20
      3. EVENT: Keepalive timeout
=20
@@ -1406,8 +1440,8 @@
       |            (A,B1) payload packet            |
       |----------------------------------------/    |
       |                                             |
-      |                                             |
-      |                                             | 10 seconds after
+      |                                             | Send Timeout=20
+      |                                             | seconds after
       |             (B1,A) Probe id=3Dp,              | T1, sends a =
com-
       |                          state=3Dexploring    | plaint that
       |   /-----------------------------------------| it is not rec-
@@ -1490,8 +1524,8 @@
       |                                             |
       |           (A1,B1) payload packet            |
       |----------------------------------------/    |
-      |                                             |
-      |                                             | 10 seconds after
+      |                                             | Send Timeout
+      |                                             | seconds after
       |          (B1,A1) Probe id=3Dp,                | T1, B sends a
com-
       |                        state=3Dexploring      | plaint that
       |<--------------------------------------------| it is not rec-
@@ -1579,6 +1613,9 @@
    Number of Initial Probes                   4 probes
    Max Probe Timeout                         60 seconds
=20
+   Alternate values of the Send Timeout may be selected by a host
+   and communicated to the peer in the Keepalive Timeout Option.
+

Delivery-date: Mon, 13 Nov 2006 08:04:19 +0000
Date: Mon, 13 Nov 2006 09:02:09 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Joe Abley <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, Harold Grovesteen <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt

Joe Abley wrote:
...
>>> There are a couple of variations of shim6 deployment scenario  that  
>>> probably deserve some thought:
> 
> 
> [...]
> 
>> Yes, so we do need to analyze these scenarios. (It would be better
>> if shim6 turned itself off in such cases.)
> 
> 
> I think we need more analysis than that :-)
> 
>  From the point of view of shim6 being used in the real world, it  would 
> be a far better result if it could be demonstrated that shim6  could 
> coexist happily with load balancers, at least in principle. The  
> alternative is that a shim6 client will see substantially no benefit  
> over a client with no shim6 stack at all when interacting with most  
> popular content.
> 
> To consider an extreme scenario for a second, if no servers support  
> shim6, then shim6 provides no benefit to clients. The motivation to  
> deploy shim6 in such a scenario might reasonably be expected to be  near 
> zero.

I think this is a good topic for draft-ietf-shim6-applicability
to discuss.

    Brian

Delivery-date: Sat, 11 Nov 2006 21:46:29 +0000
Date: Sun, 12 Nov 2006 08:44:19 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Shim6 base specification
Cc: Jari Arkko <[email-masked]>, "W. Mark Townsley" <[email-masked]>, [email-masked], MArcelo bagnulo braun <[email-masked]>

My understanding of the status of the three "base" specification 
documents following IETF 67 are:

draft-ietf-shim6-hba-02.txt
   - no further revisions required

draft-ietf-shim6-failure-detection-06.txt
   - Tom Henderson to send Jari and Iljitsch (document editors) words on:
   1) parameter value descriptions
   2) proposed words for the state machine description
   3) allowing the 10 second timer to be an option

   Tom, could you please complete this by the 20th November? We need to
   complete this last call, and your assistance in completing the review
   followup in a timely manner is appreciated

draft-ietf-shim6-proto-06.txt
   - add the text (in Section D4 (around page 109)?):
       "The SHIM6 approach does not preclude using IPSEC tunnels on 
SHIM6 packets within the network transit path"
   - alter paragraph 1 of Section 9 to propose that implementations 
SHOULD remove context state that refers to those ULIDS where the 
locator has been removed or withdrawn at the time of locator removal 
or withdrawal.
    - add text regarding CGA minimum key length, using the SEND spec 
as the guide to the appropriate text to use

Marcelo - could you please submit  a -07 version of the proto spec by 
the 20th November with these three changes incorporated?

many thanks for this,

Geoff & Kurtis

Delivery-date: Sat, 11 Nov 2006 00:32:34 +0000
Date: Sat, 11 Nov 2006 03:09:39 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Shim6 Meeting  at IETF 67 - Minutes
Cc: Jari Arkko <[email-masked]>, "W. Mark Townsley" <[email-masked]>, [email-masked], "Olaf M. Kolkman" <[email-masked]>

Thanks to Olaf for taking the minutes, and Wouter for the Jabber log and Brian for the additional notes!

Attached is the draft of the minutes - unless there are comments and/or corrections we'll run with this

regards,

  Geoff & Kurtis

---------------------

SHIM6 MINUTES

Meeting : IETF67  Nov 9, 2006
Location: Grand Ballroom AB, 13:00
Chairs  : Geoff Huston
	  Kurtis Linqvist

Minutes : Olaf Kolkman ([email-masked])
	  (substantive input from Brian Carpenter)

=========================================================
AGENDA:

 1) Administrivia                                             5 minutes
    - Mailing list: http://ops.ietf.org/lists/shim6/
    - Scribe?
    - Blue Sheets
    - Agenda Bashing   

 2) Last Call Review of "base specification" document set    75 minutes
    1. Level 3 multi-homing shim protocol
       draft-ietf-shim6-proto-06.txt
    2. Hash Based Addresses (HBA)
       draft-ietf-shim6-hba-02.txt
    3. Failure Detection and Locator Pair Exploration Protocol for IPv6
       draft-ietf-shim6-failure-detection-06.txt
       
 3) Shim6 API Draft Update                                   10 minutes
    draft-ietf-shim6-multihome-shim-api-00.txt
    
 4) Update on Applicability & Locator Pair Selection drafts  10 minutes
    draft-ietf-shim6-applicability-02.txt
    draft-ietf-shim6-locator-pair-selection-01.txt
    
 5) Final Report for SHIM Implementation.                    15 minutes

 6) WG Direction                                              5 minutes

==========================================================
SUMMARY:

  The WG agenda items covered the WG Last Call on the base protocol specification documents, and reviewed progress with related drafts, as well as the status of an implementation of SHIM6.
  
  Some further minor modifications were proposed to the protocol specification and failure detection documents, but no other issues were raised in the meeting. The chairs are confident that this will allow for a consensus call on advancing these documents as Proposed Standards to the IESG.

  There are a number of implementation efforts underway.
  
  The chairs proposed that the WG not meet at IETF 68, and decide on IETF 69 at a later date, and allow some time for experience to be gathered with the base specification before moving on to considering any form of extensions to the protocol.

==========================================================  
NOTES:

 1) Meeting Administrivia

     Nobody volunteered as scribe (Olaf Kolkman did it anyway).
     Wouter Wijngaards volunteered as jabber scribe.

     Agenda accepted as is.

 2) Last Call Review of "base specification" document set
 
    === Documents:
    
    1. Level 3 multi-homing shim protocol
       http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-06.txt
    2. Hash Based Addresses (HBA)
       http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-02.txt
    3. Failure Detection and Locator Pair Exploration Protocol for IPv6
       multi-homing
       http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt
       
     Slides: http://www3.ietf.org/proceedings/06nov/slides/shim6-1.pdf
 
     Co-Chair Geoff Huston pointed out that there is not sufficient
     indication for him and co-chair Kurtis Lindqvist to push the 3 core
     documents to the IESG for draft standard. More feedback is needed.

     Huston went into a mini-tutorial of the architecture and
     backgrounds. After that Marcello Bagnulo went over the 
     issues that came up during last call.

     == SHIM6 HBA issues.
     
     - IPR issues.

       Are the Ericsson statements acceptable for the WG? 
     
       Chair asked for last-call feedback: Nobody had issues.

     - IANA considerations

       Any problems to use CGA extensions registry as defined in
       RFC4581?
     
       Chair asked for last-call feedback: Nobody had issues.

     - Security Considerations 

       Are there any residual security considerations ?

       Carpenter brought up the reference to another draft
       (multiple-hash-cga). It is not clear if this is a normative
       reference.

       Jari Arkko argued that SHA1 dependency issue is general. It does
       not need to be resolved here.

       There was not objection to this not being considered as a normative
       dependency. 

       Jim Bound stated that all his issues have been resolved. He gave the
       advice that the drafts be published as Proposed Standards, and warns
       that people are not buying into this.

       Via jabber Iljitsch van Beijnum asked if the work be held off to
       see what happens with respect to the routing and addressing
       workshop?

       Several people respond that the existing efforts should continue
       while the work on the bigger issues also continues. Besides,
       there are several interest groups, the folk that will need to
       make SHIM6 happen are the implementors of TCP stacks. And this
       work may provide context to other groups.

     === SHIM6 Protocol issues.

     Marcello continues to describe the issues with the proto
     draft.

     - The interaction with IPsec bump in the wire (BITW)

       Implementing part of shim6 in BITW is the obvious way forward.
       The alternative is to layer shim6 above IPSec? But then there
       would need to be an SA for each locator pair. This still doesn't
       protect shim6 itself.  And it's complicated, so no work proposed
       on this.

       Via jabber, Iljitsch van Beijnum commented that it did not appear
       feasible to support disconnected SHIM6 in BITW.

       Chair asked for last-call feedback with providing the advice that
       BITW implementations of IPSEC also needed to support SHIM6: Nobody
       had issues.
       
**     Brian Carpenter proposed to add the following text to the proto
       document:
       
         "This does not preclude using IPSEC tunnels on SHIM6 packets
          within the network transit path."

     - Provide SHIM 6 security based on IPSec SAs 

       Could we layer shim6 above IPSec? But then there would need to be
       an SA for each locator pair. One approach proposed was to support
       the SA with certificates with ULIDs, and the consequent issues
       relating to certificate issuance and revocation. The second option
       is to use pre-existing IPSec trust relationships, which is in effect
       Mobile IKE. No work proposed on this.
     
       Chair asked for last-call feedback: Nobody had issues with this
       proposal.

     - ULID security mechanism
     
       Based on WG mailing list comments, the question was posed as to
       whether there should there be an alternative to the HBA method, and
       should the binding security be more modular?  
       
       Chair asked for last-call feedback: Nobody had issues with the
       proposition that we already have sufficient ULID security
       mechanisms.

     - On DOS attacks on exhausting the context tags

       4-way handshake will create state, but TCP does that as well and
       this is equivalent, so this is no worse than TCP. 
       
       Chair asked for last-call feedback: There was no consensus for
       change.

     - Allow forking

       Context forking has been there for applications to request different
       contexts for different circumstances. The issue is addressed
       sufficiently according to Dave Meyer (the reviewer who raised this
       issue).

     - Use of ULID after prefix renumbering 
     
       The security properties are being explained and Huston, Carpenter
       and Bound support the proposal that once the site is renumbered,
       the context is destroyed. It should be clear that after the old
       prefix is removed the context is destroyed.
     
**     There was consensus to include in the document that once a prefix is
       withdrawn that any further use in SHIM6 as a ULID should not be
       supported, and that the associated context states should be
       withdrawn.

     - Do we need a minimum CGA key length specified?

       Huston argues to use normative references to the CGA specs. 
       
       Jari argues that this document only specifies the minimum length.
       
**     Jari suggests to take the value from the SEND  spec. There was
       support to make this modification to the document
       
     - Definition of Broken flag.
     
       This has been addressed.
       
       Chair asked for last-call feedback: Nobody had issues with this
       text.

     === SHIM6 Failure Detection draft

       [No slides.]

       Jari noted that he had 3 items to mention:

       1. More detail in the behavior section, Jari requests for feedback
          on the text on-list

       2. Drawing the state machine using a different representation. That
          has been suggested previously, and rejected, because the number
          of states would be much bigger and therefore the state machine
          description would be less clear than now.

       3. There is a timeout of 10 seconds, unilateral, an option may be
          good instead of a fixed value. Jari requests for feedback.

**     Tom Henderson suggested to make textual clarifications of the state
       machine and offered to provide text on an option to negotiate
       timeout.

 3) Shim6 API Draft Update
    Shinta Sugimoto

    This API Allows upper layer to have better control of Locator
    management, failure detection and path exploration. It covers
    requirements but needs further work on solution aspects. This version
    defines data structures and various read and write operations, and
    cleans up the socket options defines.

    David Thaler and Erik Nordmark had a discussion on ancillary data,
    sessions, contexts and their interaction. One suggestion is that
    if sockets use different options, the one forks the shim6 context.

    Chair suggests to send carefully crafted words on this topic to
    the working group.

 4) Update on Applicability & Locator Pair Selection drafts
    Marcelo Bagnulo
    
    === On shim6-applicability

       Brian Carpenter commented that SHIM6 may work for a small client but
       for a big server the CPU might melt; The document could address the
       considerations for the different usage scenarios and what the effect
       on the amount of state is.  Huston suggests that Nordmark supplies
       text. Nordmark refers to multi6 work for what the effect on
       applications is. Huston reminds himself that he has an action to dig
       up text.

       Jim Bound suggests a description of several use cases to push
       deployment.

    === On shim6-locator-pair selection

       Dave Thaler argues that RFC3484 provides a number of constraints and
       asks  what the goal of this document is. This document integrates
       SHIM6 into the RFC 3484 framework.

 5) Final Report for SHIM Implementation.
    Kunwoo Park, SNU

    The project does not have a web page yet. The project completed a
    shim6 core daemon and REAP on simple testbed all based on the -05
    drafts. Platform is Linux 2.6 or higher. The daemon is in user
    space as a callback from the IP stack. See slides for features
    included.  (Clarification for slides: Implementation features in
    blue are done, in black are not) (No security yet.)  Phase 2 will
    have shim6 integrated in stack.

    Plan a policy component too, and API.

    No discussion.

  6) Next steps.

    Assuming consensus on Working Group Last Call, the chairs will ship off
    the documents to the IESG and propose that the working group will not
    meet at IETF 68, and maybe meet at IETF 69. In that time people can get
    experience with the base shim6 specification and implementations, and
    these experiences can be collected.
    
    The Chair noted that there are four implementation efforts underway
    with the SHIM6 protocol.

Delivery-date: Thu, 09 Nov 2006 22:41:00 +0000
Cc: marcelo bagnulo braun <[email-masked]>, Harold Grovesteen <[email-masked]>, shim6-wg <[email-masked]>
From: Joe Abley <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt
Date: Thu, 9 Nov 2006 17:39:49 -0500
To: Brian E Carpenter <[email-masked]>

A brief diversion regarding anycast follows. We swing back on-topic  
back towards the bottom.

On 9-Nov-2006, at 17:11, Brian E Carpenter wrote:

> Joe Abley wrote:
>> On 4-Nov-2006, at 19:13, Brian E Carpenter wrote:
>>> Are you talking about anycast? That clearly breaks in mobility  
>>> and  multihoming
>>> scenarios, and can only be used for fairly classical fixed servers.
>>> See draft-ietf-grow-anycast-04.txt.
>> Anycast doesn't break anything in most multihoming scenarios, and  
>> I'm  not sure I understand your implications regarding mobility.
>
> If a client trying to contact a server via an anycast address
> moves in the network or changes its source address, its packets may
> well be routed differently and be sent to a different instance of
> the server. That breaks anycast in the general case; anycast relies
> on stable routing.

Indeed, outing stability is important for the lifetime of a  
transaction. I don't believe it is reasonable to say that anycast  
"clearly breaks in [...] multi-homing scenarios", however. Mmany  
sites are multi-homed, and many services are distributed using  
anycast; since no large-scale unavailability of such services has  
been observed, clearly it's possible to use anycast to provide  
services to clients multi-homed sites.

[Note I am not claiming that it's impossible to shoot yourself in the  
foot when deploying services using anycast. If anycast were  
universally safe, we wouldn't have bothered writing draft-ietf-grow- 
anycast.]

As far as mobility goes, if your source address changes then it's a  
stretch to suggest that any common protocols will survive elegantly,  
anycast or not.

In mobility scenario where a client's source address is preserved as  
it moved (the motion through the topology being obscured from the  
application by the use of a tunnel to a home agent) the effective  
topology from the application's perspective is stable, and changing a  
tunnel endpoint on the client side should have no effect on node  
selection.

If the home agent end of a tunnel endpoint changes it's certainly  
philosophically possible that the change in outbound path will cause  
packets to be routed to a different anycast node. However, it's not  
obvious to me that

(a) collapse of an application is inappropriate given such a  
disruption, in practical terms (since a change of home agent in  
common implementations looks to the user like a reconnection to the  
network), or

(b) alternate home agents supporting the same client source address  
will be substantially separated when considering the topology of the  
global Internet: for the world to reach the client in both cases, the  
chances are good that both HAs are in the same AS, which might  
reasonably be expected to have a site-wide exit policy.

In cases where a service is distributed within a site it's easier to  
imagine scenarios where a change of HA would result in a node  
selection change for a particular client. However, within such a  
single administrative domain the network topology should be well- 
known and predictable, and so modulating the details to avoid  
services breaking seems entirely possible.

So I don't see that anycast "clearly breaks in mobility [...]  
scenarios" either.

In any case, to return to the topic at hand:

>> There are a couple of variations of shim6 deployment scenario  
>> that  probably deserve some thought:

[...]

> Yes, so we do need to analyze these scenarios. (It would be better
> if shim6 turned itself off in such cases.)

I think we need more analysis than that :-)

 From the point of view of shim6 being used in the real world, it  
would be a far better result if it could be demonstrated that shim6  
could coexist happily with load balancers, at least in principle. The  
alternative is that a shim6 client will see substantially no benefit  
over a client with no shim6 stack at all when interacting with most  
popular content.

To consider an extreme scenario for a second, if no servers support  
shim6, then shim6 provides no benefit to clients. The motivation to  
deploy shim6 in such a scenario might reasonably be expected to be  
near zero.

Joe

Delivery-date: Thu, 09 Nov 2006 22:13:14 +0000
Date: Thu, 09 Nov 2006 23:11:49 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Joe Abley <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, Harold Grovesteen <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt

Joe Abley wrote:
> 
> On 4-Nov-2006, at 19:13, Brian E Carpenter wrote:
> 
>> Are you talking about anycast? That clearly breaks in mobility and  
>> multihoming
>> scenarios, and can only be used for fairly classical fixed servers.
>> See draft-ietf-grow-anycast-04.txt.
> 
> 
> Anycast doesn't break anything in most multihoming scenarios, and I'm  
> not sure I understand your implications regarding mobility.

If a client trying to contact a server via an anycast address
moves in the network or changes its source address, its packets may
well be routed differently and be sent to a different instance of
the server. That breaks anycast in the general case; anycast relies
on stable routing.

> 
>> If you are talking about hacks for building server pools, well,
>> I would expect those hacks to break too, but we can't know what hacks
>> people are deploying.
> 
> 
> The characteristics of server load balancing as performed by products  
> from f5, foundry, cisco, etc are well-known informally, even if they  
> are not fully-specified in a standards document.

We can't design a standard to deal with that, but I suspect the impact
on moving clients may be exactly what I just described.

> 
> I have lost the original messages in this thread through over-zealous  
> ietf mailbox pruning out of cron, so what follows may well be an  obtuse 
> tangent.
> 
> There are a couple of variations of shim6 deployment scenario that  
> probably deserve some thought:
> 
>  + shim6 support present/absent on clients
>  + shim6 support present/absent on load balancers
>  + shim6 support present/absent on origin servers
>  + whether or not destination addresses are re-written by the load- 
> balancer (cf "pass-through mode")
> 
> It would be of benefit, I think, to consider at least the cases:
> 
>  + shim6/client + non-shim6/load-balancer + non-shim6/origin-server
>  + shim6/client + non-shim6/load-balancer + shim6/origin-server
>  + non-shim6/client + non-shim6/load-balancer + shim6/origin-server
> 
> and confirm that there is no fundamental architectural reason why  
> services shouldn't be able to work at least as well as they might in  a 
> non-shim6, non-multi-homed environment.
> 
> I hear the inference with respect to packet-mangling middleboxes, but  I 
> think we need to be somewhat pragmatic and acknowledge the fact  that if 
> shim6 is destined to break a user's ebay/yahoo/google/myspace/ whatever 
> experience, then ISP helpdesks around the world will rapidly  become 
> adept at instructing their customers how to turn shim6 off.

Yes, so we do need to analyze these scenarios. (It would be better
if shim6 turned itself off in such cases.)

     Brian

Delivery-date: Thu, 09 Nov 2006 20:41:09 +0000
Date: Thu, 09 Nov 2006 12:39:45 -0800
From: Jari Arkko <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>
CC:  [email-masked]
Subject: Re: comments on draft-ietf-shim6-failure-detection-06.txt {4}

Many thanks for your review Thomas. Some further
discussion inline:
> I reviewed the failure detection draft today and have the following
> comments.
>
> Clarity issues
> ==============
> 1. The state machine could be clarified a bit.  There is an
> "Operational" state but associated with this state are two timers, and
> depending on which timers are active at a given time, there are actually
> three substates, which one might call "Idle" (no timers running),
> "Operational-In" (KeepAlive running), and "Operational-Out" (Send
> running).  The draft implies that Send and Keepalive are not running
> simultaneously ("Upon the reception of a payload packet in the
> Operational state, the node starts the Keepalive timer if it is not yet
> running, and stops the Send timer if it was running."); this implies
> that a bidirectional data flow will (conceptually) be toggling
> continuously between Operational-In and Operational-Out.  It could be
> better clarified that if a host moves to a quiescent state upon sending
> a single keepalive message, unless woken up by either its own send event
> or the reception of another peer data packet.     
>
> It might be worth considering to break out the Operational state into
> substates to see what the implications are for the state machine, and
> only then decide whether one wants to collapse the substates into a
> single state.  Perhaps this has already been considered and rejected
> (I'm new to this discussion). 
>   
We have had variants of the same design that had
more states, but people found this confusing. We can
indeed model the timers with states too, but I fear that
the end result is not any clearer. In some sense the
current model allows you to consider only three
states if you do not look at the timers at all; with the
substates expanded you would have to look at everything
simultaneously.

But I will clarify what the relationship between the
two timers is.
> 2.  The linkage between these failure detection mechanisms and return
> routability checks is fuzzy.  If REAP detects through probing that a
> locator pair works, does this suffice for reachability, or does separate
> shim6 process need to send Update Request?  The last paragraph of 3.3
> seems to imply that shim6 must separately verify return routability.
> But the shim6 draft says that the Probe message exchange handles this
> routability check.    This really ought to be clarified somewhere in
> this draft.
>   
I removed this text and edited the explanation in the security
considerations section to say:

"Other parts of the SHIM6 protocol ensure that the set of addresses
we are switching between actually belong together. REAP itself
provides no such assurances. Similarly, REAP provides some protection
against third party flooding attacks [ref]; when
REAP is run its Probe nonces can be used as a return routability check
that the claimed address is indeed willing to receive
traffic. However, this needs to be complemented with another mechanism
to ensure that the claimed address is also the correct host. SHIM6
does this by performing binding of all operations to context tags.
> 3. There seems to be a mismatch with the shim6-proto draft, where it
> says that there are "Probe Option", "Reachability Option", and "Payload
> Reception Report Option" TLVs defined in this draft.  I couldn't find
> any such Option definitions.
>   
Indeed. We updated the failure detection draft as a result
of comments that called for simplification of the protocol.
The shim6-proto draft needs to reflect the changes, too,
but it has not yet been updated.
> 4.   There could be more clarity in the terminology for address pairs.
> The protocol draft talks of ULID-pairs and current locator pair, while
> this draft talks about primary address pair and current address pair.
>   
ULID term is not actually needed here and it is removed.
> Second, it probably needs to be distinguished that there is an inbound
> address pair and an outbound address pair that may be the same or
> different.  I suggest to consistently use the terms "ULID-pair",
> "outbound locator pair", "inbound locator pair" and possibly to clarify
> that when "locator pair" is used without reference to inbound or
> outbound, it refers to the case where they are the same pair.
>
> 5.  In general, sections 6 and 7 seem drafty to me.  Section 7
> (examples) probably should be an appendix, and section 6 should be
> expanded into more detailed elements of procedure, such as how to fill
> in parameter values and what are the legal values, that do not require
> reading section 7 to find the details.
>   
I will move Section 7 to an appendix.

And add parameter values. The legal values are in the format
descriptions, and I don't think they should be added here.
> 6.  In section 7, examples 4 and 5, where are the keepalives preceding
> the 10 second timeout.  Why won't peer A be the one to first have a Send
> timeout in example 4?
>
>   
It just the one that happens to notice it first. I will add
text about this.
> Suggested technical change
> ==========================
> I disagree with fixing the KeepaliveTimeout to 10 seconds and making the
> possible negotiation an area for future study.  I don't see why each
> node couldn't set a parameter in the initial exchange that directed a
> peer to use a particular timeout value.   There doesn't have to be any
> negotiation; each side can configure the KeepaliveTimeout that the peer
> must use for setting Keepalive timer, and optionally include the
> parameter in the I2, R2, and possibly I2-bis packets.  Send timer can be
> aligned with the Keepalive timer interval given to the peer.  The
> default (if no such parameter is present) could be 10 seconds.  I
> suggest to define the parameter now, as well as instructing
> implementations to honor it if they receive such a parameter, and say
> that the heuristics for sending it are for further study.
I'm fine doing this either way. But there was some prior
discussion where we wanted to limit the size of the
protocol and were unsure if we ever needed to provide
a negotiation mechanism. Does anyone else care about this?
> Minor
> ====
> title of section 4.2 "Alternate Address Pair Exploration" should
> probably be "Full Reachability Exploration" to match other references in
> the text to this procedure
>
> in section 3.5, s/multible/multiple
>
> in section 3.4, the acronym "ULID" is used for the first time without
> any expansion or reference.
>
> ExploringOK state could have a name that is more indicative of the state
> of the exploration, such as InboundOK
>
> In section 6, the explanatory text for each event precedes the numbered,
> underlined event definition, and it is somewhat confusing to read
> because the numbered lines seem to delineate the sections but they in
> fact do not.
>   
All taken into account.

--Jari

Delivery-date: Thu, 09 Nov 2006 18:26:57 +0000
Date: Thu, 09 Nov 2006 19:23:42 +0100
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked]
Subject: draft-ietf-shim6-proto-06 : Sending R2 in I2-SENT state

Hi,

I have still a question regarding the proto draft. I'm sorry to post it 
so late, I was delayed in re-reading the draft in depth, and could not 
be present at IETF meeting. So, here is :

(p76) In section 10.4, it is stated that upon reception of an update 
request and if the state is I2-SENT or I2bis-SENT, we need to reply with 
an R2 then process the update. I agree with processing the update 
request, but I don't understand why to send an R2 : If the responder is 
in established state, it will anyway drop the R2. And I suppose that if 
the responder sent an update request, this implies that it is already in 
established state.

I suppose that you have a good reason of doing this, because I see in 
section 12.1 that in state I2-SENT, if payload is received, an R2 must 
also be sent (which I see equally as useless, since silently discarded 
by the peer). Also, in section 10.5, the same behaviour is defined. Can 
you explain the reason for this ?

btw,  in appendix B, the simplified state machine is inconsistent with 
the text, saying that in I2-SENT state, an I2 (not an R2) must be 
replied to payload extension header packets, because the peer probably 
has sent an R2 which was lost. This appears to me more appropriate than 
what is said in sections 10.4, 10.5 and 12.1.
otoh, the simplified state machine diagram in appendix B.1 agrees with 
the text (so disagrees with appendix B).

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium

Delivery-date: Wed, 08 Nov 2006 13:47:43 +0000
Date: Wed, 08 Nov 2006 14:27:47 +0100
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
CC: [email-masked], David Meyer <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-shim6-proto-06 : Context confusion

Hi,

I think that in the previous mail, I had not well in mind the fact that 
the only way for a host to have multiple own context tags is to first 
drop one context, then create a new one with the same context tag, so 
that in any case, there is only one possible context for the context 
tag, with still the possibility of having packets arriving to the newly 
created context, but addressed to the dropped context.

With this in mind, I understand better the interest of having 
non-overlapping locators sets. This way we can work as if the two (or 
more) locator sets were corresponding to different machines.

But in this case the following sentence should probably be adapted a bit 
(section 7.6):
----
The confusion can be detected when I2/I2bis/R2 is received since we
  require that those messages MUST include a sufficiently large set of
  locators in a Locator List option that the peer can determine whether
  or not two contexts have the same host as the peer by comparing if
  there is any common locators in Ls(peer).
----
Now, we could consider the case of a single host with multiple disjoint 
locator sets being seen by its pair as multiple hosts. This is without 
problem except a little subtlety. Here is the adapted example of the 
previous mail :
----
1. host A has two contexts with host B, one with the set of locators 
<A1,B1/B2> and CTx, the other with <A2,B3/B4> and CTy.
2. After some time, host B drops the first context.
3. Now he wants to create another one : <A1,B3/B4> with CTx.
----

When A receives the I2 message from B, it is not able (as should be) to 
detect that it is speaking with the same host, as the locator sets are 
disjoint. As a consequence, the context in A with CT(peer)=CTx will not 
be discarded. We are now in the situation of A possibly sending packets 
to both the discarded context <A1,B1/B2> and the newly created one <A1, 
B3/B4>, using CTx in both cases.
IMHO, this can be detected by B, and should be stated in the draft as 
another case of confusion detection (in fact both confusion and context 
loss detection). For this to be done, section 12.1 could be slightly 
changed, to say that a receiver MUST NOT assume that a packet with the 
shim6 payload extension header and a context tag matching with a context 
is really attached to the context. Rather, to verify this, the source 
locator must be checked against Ls(peer) :
o if the source locator is included in Ls(peer), usual translation is done.
o if the source locator is not included in Ls(peer), then probably this 
packet belongs to an old, dropped context, and an R1bis message MUST be 
sent in this case, in order to recover the previously discarded context 
(in my example <A1,B1/B2>).

I hope this proposal is clearer and more realistic than the one 
described in my previous mail.

Thanks for any comment,

Sébastien.

Delivery-date: Mon, 06 Nov 2006 19:23:23 +0000
Cc: marcelo bagnulo braun <[email-masked]>, Harold Grovesteen <[email-masked]>, shim6-wg <[email-masked]>
From: Joe Abley <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt
Date: Mon, 6 Nov 2006 14:20:52 -0500
To: Brian E Carpenter <[email-masked]>

On 4-Nov-2006, at 19:13, Brian E Carpenter wrote:

> Are you talking about anycast? That clearly breaks in mobility and  
> multihoming
> scenarios, and can only be used for fairly classical fixed servers.
> See draft-ietf-grow-anycast-04.txt.

Anycast doesn't break anything in most multihoming scenarios, and I'm  
not sure I understand your implications regarding mobility.

> If you are talking about hacks for building server pools, well,
> I would expect those hacks to break too, but we can't know what hacks
> people are deploying.

The characteristics of server load balancing as performed by products  
from f5, foundry, cisco, etc are well-known informally, even if they  
are not fully-specified in a standards document.

I have lost the original messages in this thread through over-zealous  
ietf mailbox pruning out of cron, so what follows may well be an  
obtuse tangent.

There are a couple of variations of shim6 deployment scenario that  
probably deserve some thought:

  + shim6 support present/absent on clients
  + shim6 support present/absent on load balancers
  + shim6 support present/absent on origin servers
  + whether or not destination addresses are re-written by the load- 
balancer (cf "pass-through mode")

It would be of benefit, I think, to consider at least the cases:

  + shim6/client + non-shim6/load-balancer + non-shim6/origin-server
  + shim6/client + non-shim6/load-balancer + shim6/origin-server
  + non-shim6/client + non-shim6/load-balancer + shim6/origin-server

and confirm that there is no fundamental architectural reason why  
services shouldn't be able to work at least as well as they might in  
a non-shim6, non-multi-homed environment.

I hear the inference with respect to packet-mangling middleboxes, but  
I think we need to be somewhat pragmatic and acknowledge the fact  
that if shim6 is destined to break a user's ebay/yahoo/google/myspace/ 
whatever experience, then ISP helpdesks around the world will rapidly  
become adept at instructing their customers how to turn shim6 off.

Joe

Delivery-date: Sun, 05 Nov 2006 00:16:45 +0000
Date: Sun, 05 Nov 2006 01:13:56 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: Harold Grovesteen <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt

Harold,

Are you talking about anycast? That clearly breaks in mobility and multihoming
scenarios, and can only be used for fairly classical fixed servers.
See draft-ietf-grow-anycast-04.txt.

If you are talking about hacks for building server pools, well,
I would expect those hacks to break too, but we can't know what hacks
people are deploying.

     Brian

marcelo bagnulo braun wrote:
> Hi Harold,
> 
> El 02/11/2006, a las 11:43, Harold Grovesteen escribió:
> 
>>
>>>>>
>>>>> the assumption here is that there is no situation of merging hosts,
>>>>> meaning that if two contexts are initiated with a disjoint set of
>>>>> locators, they will remain disjoint during the lifetiem of the 
>>>>> context,
>>>>> and the situation where two contexts have disjoint sets and then later
>>>>> on one of them adds new locators that interject with another 
>>>>> previously
>>>>> disjoint context is not supported. This is what the above 
>>>>> assumption is
>>>>> expressing... makes sense?
>>>>
>>>>
>> How does this assumption relate to various host-based load-balancing 
>> and fail-over designs that currently depend upon a single IPv4 address 
>> for a set of services?
> 
> 
> i am not sure i fully understand your comment here...
> 
> In the shim6 scenario, a multihomed site obtains multiple PA prefixes, 
> one per provider, so hosts within the multihomed site obtain multiple 
> addresses, again one per provider. So, this is implies that selecting 
> one address for using in a communication determines the ISP used for 
> routing these packets. So, load sharing mechanisms would rely in using 
> different addresses so that packets flow through different providers.
> 
> would this clarify your question?
> 
> regards, marcelo
> 
> 
>>   Is there a need for server-side host-to-host coordination of 
>> locators ala VRRP or similar mechanisms?
>>
>> Since the multi-homing direction was determined in the multi6 WG, for 
>> various reasons, I have not followed the minute details of protocol 
>> development.  So, if this has been discussed elsewhere, a simple 
>> pointer will suffice to bring me upto speed.
>>
>> Thanks,
>> Harold Grovesteen
>>
>>
> 
> 
> 

Delivery-date: Thu, 02 Nov 2006 17:15:18 +0000
Date: Thu, 02 Nov 2006 18:13:37 +0100
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To: [email-masked]
CC: David Meyer <[email-masked]>, [email-masked]
Subject: draft-ietf-shim6-proto-06 : Context confusion

Hi,

I have a doubt regarding context confusion, please find my comment below :

>> ...
>>     
>>> 7.6.  Context confusion
>>>
>>>   Since each end might garbage collect the context state we can have
>>>   the case when one end has retained the context state and tries to 
>>> use
>>>   it, while the other end has lost the state.  We discussed this in 
>>> the
>>>   previous section on recovery.  But for the same reasons, when one
>>>   host retains context tag X as CT(peer) for ULID pair <A1, B1>, the
>>>   other end might end up allocating that context tag as CT(local) for
>>>   another ULID pair, e.g., <A3, B1> between the same hosts.  In this
>>>   case we can not use the recovery mechanisms since there needs to be
>>>   separate context tags for the two ULID pairs.
>>>
>>>   This type of "confusion" can be observed in two cases (assuming it 
>>> is
>>>   A that has retained the state and B has dropped it):
>>>
>>>   o  B decides to create a context for ULID pair <A3, B1>, and
>>>      allocates X as its context tag for this, and sends an I1 to A.
>>>
>>>
>>>
>>>
>>>
>>> Nordmark & Bagnulo      Expires November 16, 2006              [Page 
>>> 58]
>>>
>>> Internet-Draft               Shim6 Protocol                     May 
>>> 2006
>>>
>>>
>>>   o  A decides to create a context for ULID pair <A3, B1>, and starts
>>>      the exchange by sending I1 to B. When B receives the I2 message,
>>>      it allocates X as the context tag for this context.
>>>
>>>   In both cases, A can detect that B has allocated X for ULID pair 
>>> <A3,
>>>   B1> even though that A still X as CT(peer) for ULID pair <A1, B1>.
>>>   Thus A can detect that B must have lost the context for <A1, B1>.
>>>
>>>   The confusion can be detected when I2/I2bis/R2 is received since we
>>>   require that those messages MUST include a sufficiently large set of
>>>   locators in a Locator List option that the peer can determine 
>>> whether
>>>   or not two contexts have the same host as the peer by comparing if
>>>   there is any common locators in Ls(peer).
>>>
>>> dmm> not really sure how this works. Is it not possible to have
>>> dmm> a situation where Ls_i(peer) \intersect Ls_j(peer) is empty
>>> dmm> (where Ls_1(peer),...,Ls_n(peer) is the sequence of changing
>>> dmm> locator sets for peer)? Or is the "sufficiently slowly
>>> dmm> changing locator sets" assumption operative here?
>>>
>>>       
>> the assumption here is that there is no situation of merging hosts, 
>> meaning that if two contexts are initiated with a disjoint set of 
>> locators, they will remain disjoint during the lifetiem of the context, 
>> and the situation where two contexts have disjoint sets and then later 
>> on one of them adds new locators that interject with another previously 
>> disjoint context is not supported. This is what the above assumption is 
>> expressing... makes sense?
>>     
>
> dmm> yes. Maybe exactly that text, or something like it, would clarify?
>
>   
As far as I understand this explanation, we are in the situation of two 
contexts being created using disjoint sets of locators. The assumption 
is that until both contexts die, the sets won't intersect. Right ? But 
why those locators should never intersect ? I think the point for 
avoiding context confusion is to have, as stated in the original text, a 
sufficiently large set of locators, so that each context established 
with a given host will have at least one locator present in the Locator 
List Option. Maybe it's simpler to discuss with an example :
1. host A has two contexts with host B, one with the set of locators 
<A1,B1/B2> and CTx, the other with <A2,B3/B4> and CTy.
2. After some time, host B drops the first context.
3. Now he wants to create another one. B knows (for example from a fixed 
configuration) that it usually announce as locators B1/B2 for one 
purpose (say low cost links) and B3/B4 for another purpose (say low 
delay links). Because of that, B knows that A may have an old context  
with either one of these pairs. So he creates a context in A with 
locators <A1,B1/B3/B4> and CTx.  This is correct because the locator 
list option contains at least one locator from each set.
4. Indeed A will notice that the context <A1,B1/B2>, CTx is established 
with the same peer, and will discard it.

The example above illustrates a scenario with no special problem. Now 
let's suppose that between step 1 and step 2, B receives a new prefix, 
with which it creates a new address B5 and announce it to both contexts 
in A. We have now in A (<A1,B1/B2/B5>,CTx) and (<A2,B3/B4/B5>,CTy). This 
change is exactly (as far as i understand it) what it assumed not to be 
supported, because the two sets were initially disjoint, but this is not 
the case anymore.
Where is the problem ? On the contrary, the situation appears to me as 
simpler : now step 3 is still correct, and another correct case appears, 
which is to create a context with locators <A1,B5> and CTx.

---------------

Now I have another question, regarding the original text. The above 
scenario serves also the purpose of my second question. I have chosen a 
case where B uses always locators B1/B2 for one type of traffic (low 
cost), and B3/B4 for the other type (low delay). The above example shows 
that dealing with it is impossible to keep these two sets fully 
disjoint. The reason is that if they are disjoint one time, then we have 
to mix them next, in order to enable context confusion detection. Do you 
see any good solution for that ? Or am i misunderstanding something ?
One idea I have to solve this problem is to split the context tag space 
in B in two parts, so that 'low cost' context tags are always different 
from 'low delay' context tags.
Put in a more general way, I would say that if there is a need within a 
host to separate the locators into disjoint locators sets (for example 
in order to deal with different QoS requirements), then the Context Tag 
space must also be split into disjoint context tag spaces, one context 
tag space for each locator set. Now one could argue that the case where 
a host suddenly decides to split his locator sets is still a problem, as 
newly allocated contexts (with split locator sets) may create undetected 
confusion with previously allocated contexts. Well, for that problem I 
have'nt a solution right now. In fact I would like to have some 
confirmation that I'm not misunderstanding some things before to think 
more about this problem.

Another idea would be to rely on the random cycle through the 2^47 
context tag values (section 7.1). But if this option is chosen, maybe 
the SHOULD statement in section 7.1 should become a MUST. In that case 
it is probably no longer necessary to split the context tags space the 
way I described it previously.

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium

Delivery-date: Thu, 02 Nov 2006 14:36:03 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt
Date: Thu, 2 Nov 2006 15:34:59 +0100
To: Harold Grovesteen <[email-masked]>

Hi Harold,

El 02/11/2006, a las 11:43, Harold Grovesteen escribi=F3:

>
>>>>
>>>> the assumption here is that there is no situation of merging hosts,
>>>> meaning that if two contexts are initiated with a disjoint set of
>>>> locators, they will remain disjoint during the lifetiem of the=20
>>>> context,
>>>> and the situation where two contexts have disjoint sets and then=20
>>>> later
>>>> on one of them adds new locators that interject with another=20
>>>> previously
>>>> disjoint context is not supported. This is what the above=20
>>>> assumption is
>>>> expressing... makes sense?
>>>
> How does this assumption relate to various host-based load-balancing=20=

> and fail-over designs that currently depend upon a single IPv4 address=20=

> for a set of services?

i am not sure i fully understand your comment here...

In the shim6 scenario, a multihomed site obtains multiple PA prefixes,=20=

one per provider, so hosts within the multihomed site obtain multiple=20
addresses, again one per provider. So, this is implies that selecting=20
one address for using in a communication determines the ISP used for=20
routing these packets. So, load sharing mechanisms would rely in using=20=

different addresses so that packets flow through different providers.

would this clarify your question?

regards, marcelo

>   Is there a need for server-side host-to-host coordination of=20
> locators ala VRRP or similar mechanisms?
>
> Since the multi-homing direction was determined in the multi6 WG, for=20=

> various reasons, I have not followed the minute details of protocol=20
> development.  So, if this has been discussed elsewhere, a simple=20
> pointer will suffice to bring me upto speed.
>
> Thanks,
> Harold Grovesteen
>
>

Delivery-date: Thu, 02 Nov 2006 11:54:40 +0000
Date: Thu, 02 Nov 2006 04:43:42 -0600
From: Harold Grovesteen <[email-masked]>
To: shim6-wg <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt

>>>
>>> the assumption here is that there is no situation of merging hosts,
>>> meaning that if two contexts are initiated with a disjoint set of
>>> locators, they will remain disjoint during the lifetiem of the context,
>>> and the situation where two contexts have disjoint sets and then later
>>> on one of them adds new locators that interject with another previously
>>> disjoint context is not supported. This is what the above assumption is
>>> expressing... makes sense? 
>>
How does this assumption relate to various host-based load-balancing and 
fail-over designs that currently depend upon a single IPv4 address for a 
set of services?  Is there a need for server-side host-to-host 
coordination of locators ala VRRP or similar mechanisms?

Since the multi-homing direction was determined in the multi6 WG, for 
various reasons, I have not followed the minute details of protocol 
development.  So, if this has been discussed elsewhere, a simple pointer 
will suffice to bring me upto speed.

Thanks,
Harold Grovesteen