Subject: RE: New version of charter text
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Fri, 28 Jan 2005 08:12:40 +0200

Kurt, 

A small comment:

> The WG will not consider items outside the above scope, such as
> interaction with mobility, transport level solutions, or alternative
> identifier formats. However, the WG will consider developing methods
> for the shim6 level to handle transport layer signalling to the shim6
> layer as in scope.

I'd suggest changing the last sentence to:

  ... However, the WG will consider developing methods
  for the shim6 level to handle transport layer events (or indicators) 
  to the shim6 layer as in scope.

i.e. - change 'signaling' to 'events.'

TCP retransmit timeout, for example, being an event the shim6 might be
interested in.

> [What other topics are explicitly in/out of scope?]

Definition of multihoming policy should be out of scope.  It should be possible
that different policies can be used with shim6; policies such as link rotation,
failover policies, etc.; but definition of the policies themselves should be
out of scope, as these policies may be dependent on deployment issues.

John

Delivery-date: Fri, 28 Jan 2005 01:09:41 +0000
Date: Thu, 27 Jan 2005 17:08:56 -0800
From: Erik Nordmark <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>
CC: [email-masked]
Subject: Re: about draft-ietf-multi6-l3shim-00.txt

Henderson, Thomas R wrote:
> Erik, just a few more nits:

Thanks for the careful read.

> page 5:  "identifier - an IP layer identifier" seems like a circular
> definition, especially since "identifier" does not seem to be often
> used in the text without a qualifying "IP" preceding it.  Perhaps, in
> parallel to the address definition it could say: "IP identifier - an
> IP layer name for an endpoint (stack name in [NSRG])..."

ok

> page 5:  "NOTE:  This proposal does not contain any IP layer
> identifiers"  But it does discuss a number of options.  Suggest
> "NOTE:  This proposal does not define any IP layer identifiers, but
> discusses some options in Section 9."

How about
NOTE: This proposal does not specify any new form of IP layer 
identifier, but
still separates the identifying and locating properties of the IP addresses.

> page 19: Previously (Sec 2.1) you define X as a malicious host, but
> then you seem to use host X in a non-malicious context here.
> Actually, I don't recall where X is malicious within this document,
> so maybe revise 2.1?

I'll fix this use of X.

I fixed the other nits as well.

    Erik

Delivery-date: Thu, 27 Jan 2005 22:17:01 +0000
Date: Thu, 27 Jan 2005 14:15:58 -0800
From: Erik Nordmark <[email-masked]>
To: Kurt Erik Lindqvist <[email-masked]>
CC: Brian E Carpenter <[email-masked]>, [email-masked], marcelo bagnulo braun <[email-masked]>
Subject: Re: New version of charter text

Kurt Erik Lindqvist wrote:

>>I'm not sure we should commit to an API. We might well want to
>>specify it conceptually, i.e. a bit more than hints, but
>>not really get into the API deinition game, which the IETF
>>usually leaves to others.
> 
> 
> I used the word signalling in the new version. Not sure if that is 
> "conceptual" enough?

I suspect a single overloaded word such as "signaling" isn't sufficient 
to explain this; you need a sentence.

>>>TE, and perhaps ingress filtering I envisioned in the applicability 
>>>document. The new communication establishment I envisioned to be 
>>>addressed in the multihoming event trigger document (but come to 
>>>think about it, this perhaps should be somewhere else).
>>
>>It might be separate. But we could decide that later.
> 
> 
> So we leave it as it is? Or should we explicitly describe the 
> applicability document?

I feel the charter gets into too much detail of which documents will be 
delivered. We should focus it on which pieces remain to be worked on 
(i.e., things that multi6 didn't do or finish), and which pieces need to 
be delivered, and not worry too much whether the deliverable in fall '05 
or spring '06 consists of N or M internet drafts.

Kurt Erik Lindqvist wrote:

 >>I think that area is interesting, but could be a rat hole. Those
 >>issues are more about interface selection and performance
 >>characteristics of the path, then about multihoming. That is, such
 >>approaches would be useful (or not) even in the absence of shim6
 >>below. There might be some added motivation for addressing this in the
 >>multihoming context, if multihoming causes more dynamic variation in
 >>the paths that are being used over time than what we see in today's.
 >>However, in the case of site multihoming, I think the variation will
 >>not be much different than IPv4 single prefix multihoming today when
 >>routing selects different paths; it is the host multihoming case which
 >>potentially makes this a more pressing issue - see the GRPS vs. WLAN
 >>examples above.
 >>
 >>I don't see a need to add anything about this to the charter though.
 >
 >
 > Ok, I think I misunderstood Marcelo then. However, I would assume that
 > at least some text on application layer 'events'  should be included in
 > either the architecture or the protocol document?

I'm not sure, for two reasons:
  - I don't know if 'events' imply information delivered from the shim 
to the application, or from the application to the shim (or both)
  - I'm not sure we understand how applications might have different 
needs and desires than transport protocols.

We *do* know that the shim's failure detection can make use of transport 
protocol hints (such as "things are ok" or even "I might be having 
problems"), but I don't know what else we know is needed on this front.
Note that such transport level hints should be usable when the 
retransmission layer is implemented above UDP, which means "application 
or middleware layer" from an implementation perspective.

    Erik

Delivery-date: Thu, 27 Jan 2005 21:50:00 +0000
Date: Thu, 27 Jan 2005 13:49:06 -0800
From: Erik Nordmark <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: New version of charter text

[email-masked] wrote:
> I take it to mean that shim6 will not modify the transport layer, but
> may have some interaction with the transport layer (aka - transport
> layer triggers or indicators).
> 
> 
>>I think it would be interesting to look at how multi-locator aware 
>>protocols like SCTP and DCCP would operate when there is a shim below, 
>>but I don't think this is on the critical path and should be a separate 
>>document.
> 
> 
> I think that this would be premature to consider at this point, but might
> be reasonable later on, once we have a good idea of the problem space
> - i.e. - leave this type of stuff for rechartering.

Agreed.
Might make sense making the above distinctions more clear in the charter.

    Erik

Delivery-date: Thu, 27 Jan 2005 15:51:55 +0000
content-class: urn:content-classes:message
Subject: RE: about draft-ietf-multi6-l3shim-00.txt
Date: Thu, 27 Jan 2005 07:51:42 -0800
From: "Henderson, Thomas R" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: <[email-masked]>

Erik, just a few more nits:

page 5:  "identifier - an IP layer identifier" seems like a circular definition, especially since "identifier" does not seem to be often used in the text without a qualifying "IP" preceding it.  Perhaps, in parallel to the address definition it could say: "IP identifier - an IP layer name for an endpoint (stack name in [NSRG])..." 

page 5:  "NOTE:  This proposal does not contain any IP layer identifiers"  But it does discuss a number of options.  Suggest "NOTE:  This proposal does not define any IP layer identifiers, but discusses some options in Section 9."

page 7:  RFC 3484 is cited but not referenced later

page 12: s/multi6 one some packets/multi6 some packets/

page 12: s/packet to big/packet too big/

page 15: s/advise/advice/

page 19: Previously (Sec 2.1) you define X as a malicious host, but then you seem to use host X in a non-malicious context here.  Actually, I don't recall where X is malicious within this document, so maybe revise 2.1?

Tom

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2005 2:01 PM
> To: marcelo bagnulo braun
> Cc: [email-masked]
> Subject: Re: about draft-ietf-multi6-l3shim-00.txt
> 
> 
> 
> marcelo bagnulo braun wrote:
>  > Hi Erik,
>  >
>  > I think the document is very clear. I have some comments below...
> 
> Thanks for the careful review.
> 
>  > I would say that the assumption being made is even 
> stronger than this.
>  > In addition to what is stated, there is another assumption 
> being made
>  > w.r.t. to the site exit router selection. Precisely, i 
> think that the
>  > solution assumes that a modification in the source and destination
>  > addresses would result in a change of the site exit path 
> used to route
>  > both incoming and outgoing packets. This assumption holds 
> true trivially
>  > for incoming packets since we are assuming provider aggregatable
>  > addressing, but for the case of outgoing traffic, this is 
> not trivial
>  > and some mechanisms are needed for this (in particular some of the
>  > ingress filtering mechanisms also provide such 
> functionality, but note
>  > that there are some solution for the ingress filtering 
> compatibility
>  > problem (like address rewriting or simply relaxing ingress 
> filters) that
>  > solve the ingress filtering problem but don't provide this 
> functionality)
> 
> That might very well be one way we end up addressing the ingress 
> filtering and source address relationship, but I don't think 
> the shim6 
> approach necessarily assumes that the source address must affect the 
> chose exit. If there is a need to be able to explore all 
> exits (which is 
> actually a question) i.e. packets transmitted by A to B 
> should take all 
> possible exits from A's site, then the source,destination pair of 
> locators need to be able to cause the different exits.
> But depending on the complexity of such solutions we might 
> decide that 
> they are not worth-while.
> 
> In any case, I think it is premature to state this as an 
> assumption of 
> the form "the source address must affect the exit".
> 
>  >
>  >> 2.  Terminology
>  >
>  >
>  > [...]
>  >
>  >>       identifier  - an IP layer identifier for an IP 
> layer endpoint
>  >>                     (stack name in [NSRG]).  The 
> transport endpoint is a
>  >
>  > 
> ^name?
>  >
>  > maybe i am not understanding this, but isn't a "name" 
> missing above?
> 
> Yes, that is the easiest edit. It could say "The transport 
> endpoint is a 
> function of the transport level, and the transport endpoint 
> *name* would 
> typically ..." but that doesn't add much.
> 
>  >>                     function of the transport protocol and would
>  >>                     typically include the IP identifier 
> plus a port
>  >>                     number.  NOTE: This proposal does not 
> contain any IP
>  >>                     layer identifiers.
>  >>
>  >>       upper-layer identifier (ULID)
>  >>                   - an IP locator which has been selected for
>  >
>  >
>  > Wouldn't be better to substitute locator for address in 
> this definition?
> 
> Well, it is a locator, so I guess it could be either.
> FWIW The document tries to use the term "address" very sparingly (and 
> I'll fix it to be even more careful). The document uses the term 
> "address field" liberally, but that is not the same as the 
> "address" term.
> 
>  >> 4.2.  Renumbering Implications
>  >>
>  >>    As stated above, this approach does not target to not make
>  >
>  >
>  > remove one of the "not" above
> 
> Oops
> 
> 
>  >>    This potential source for confusion can be avoided if 
> we require that
>  >>    any communication using a ULID must be terminated when the ULID
>  >>    becomes invalid (due to the underlying prefix becoming 
> invalid).
>  >>
>  >
>  > I think this is an overkill.
>  > Which is the probability of this event? i mean, the event 
> is that the
>  > prefix is renumbered and assigned to another site within 
> the lifetime of
>  > an established communication, and then that the same 
> address is assigned
>  > to a host (only this is 2^(-64)) and then that this host 
> establishes a
>  > communication with the same host that the initial one is 
> communicating...
>  > I wouldn't worry about this case.
> 
> I'll edit your text above and add it to the document.
> 
> 
>  > But, presumably, the MTU change would occur, as you 
> mention, after a
>  > locator failure. This means that a new path will be used 
> after this, and
>  > this, by itself, may imply a change in the available MTU. 
> So, my point
>  > is that the change on the MTU is inherent of the fact that we are
>  > changing the path used for an established communication 
> and not only due
>  > to the addition of an additional extension header.
> 
> I'll also add the above to the document.
> 
> 
> 
>  >> 7.1.  DNS and Centrally Assigned Unique-local Addresses
>  >>
>  >>    Earlier we've mentioned that the protocol might 
> provide the basic
>  >>    mechanism to use Unique-local addresses as ULIDs.
>  >>
>  >>    In the cases where hosts have been assigned centrally 
> assigned ULAs
>  >>    [ULA-CENTRAL], one can potentially take advantage of 
> this to provide
>  >>    better support for applications.  With centrally 
> assigned ULAs it is
>  >>    possible to register them in the reverse DNS tree.  As 
> a result, one
>  >>    could use the DNS not only for applications which care 
> about reverse
>  >>    and forward tree being consistent, but also to find 
> the full set of
>  >>    locators from the ULID.
>  >>
>  >>
>  >
>  >
>  > But this is the case not only for Centrally assigned ULAs, 
> but for also
>  > for all routable addresses, right?
>  > So i would suggest to move this (very valuable) comment to 
> the previous
>  > section, that makes general observations about the DNS.
> 
> Yes, text needs to be yet more clear on what is ULA specific.
> The key point the doc should make is that in some cases consistent 
> reverse and forward trees for a locator set are hard (such as two 
> "consumer" ISPs each providing DNS, but no way for the site 
> to control 
> what goes in the DNS for the reverse tree). Using centrally assigned 
> ULAs means that the site can interact with the entity 
> assigning the ULA 
> to get consistent reverse DNS.
> 
> 
> 
>  >>         When the policy is triggered, which could be on 
> either A or B,
>  >>         an initial context establishment takes place.  
> This exchange
>  >>         might fail should the peer not support the multi6 
> protocol.  If
>  >
>  >
>  > I don't understand the usage of the "should" of the last 
> sentence (but
>  > this is probably me)
> 
> English isn't my mother tongue either. I'll reword to use 
> "if" instead:
> "This exchange will fail if the peer does not support the 
> multi6 protocol."
> 
>  >>         it succeeds it results in both ends receiving the 
> locator sets
>  >>         from their respective peer, and the security 
> mechanism provides
>  >>         some way to verify these sets.
>  >>
>  >>         At this point in time it is possible for the 
> hosts to change to
>  >>         a different locator in the set.  But until they 
> have exchanged
>  >>         the locator sets, and probably until they rehome 
> the context to
>  >
>  >
>  > i would remove the "probably" in the previous sentence ( i 
> mean, only
>  > after a rehoming they will start using a new locator, right?)
> 
> Well, they might send test packets after they have a locator 
> set for the 
> peer, so there would be some difference in the packets they send.
> 
>  >>    Note that we do not yet understand how beneficial it 
> would be to be
>  >>    able to accept packets from unknown source locators 
> (the rules for
>  >>    packet injection can probably be more relaxed than for 
> where packets
>  >
>  >
>  > i don't understand this sentence... wouldn't it be 
> "reception" rather
>  > than "injection"?
> 
> Yes
> 
> 
>  >>    The alternative would be to layer multi6 above IPsec, but that
>  >>    doesn't seem to provide any benefits and it would add 
> the need to
>  >>    create different IPsec SAs when the locators change 
> due to rehoming.
>  >>
>  >
>  > wouldn't be good to refer to the mobike work at this point?
> 
> Would should the document say other than just "[MOBIKE]"
> ?
> 
>     Erik
> 
> 
> 

Delivery-date: Thu, 27 Jan 2005 09:44:02 +0000
Cc: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: about draft-ietf-multi6-l3shim-00.txt
Date: Thu, 27 Jan 2005 10:45:18 +0100
To: marcelo bagnulo braun <[email-masked]>

On 2005-01-26, at 18.43, marcelo bagnulo braun wrote:

> I don't know if the chairs agree with discussing this doc here, but 
> considering the title, i thought it was the right place.
> If you prefer to move it to the multi6 list, please let me know.

As multi6 does not expect to issue an update of any of the docs that 
has gotten draft-ietf-multi6, all updates to does docs would end up 
being in a future to be shim6 WG, so I think we can have the the 
discussion here (if not at least for the list archives).

I haven't discussed this with Brian so he might now say I am wrong..:)

- - kurtis -

Delivery-date: Thu, 27 Jan 2005 09:16:10 +0000
Cc: [email-masked], marcelo bagnulo braun <[email-masked]>
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: New version of charter text
Date: Thu, 27 Jan 2005 10:17:32 +0100
To: Erik Nordmark <[email-masked]>

On 2005-01-26, at 21.04, Erik Nordmark wrote:

> Kurt Erik Lindqvist wrote:
>
>>> what about a new shim API? I mean a new API that allows the apps to 
>>> communicate with the shim and inform about failures or other stuff, 
>>> would this be within scope?
>> Well, I added the transport layer "hints" as proposed by Erik, 
>> perhaps we should rewrite this into simply "shim layer API" ?
>
> I think the charter is reasonably clear on the hints/interactions with 
> failure detection.
>
> I read Marcelo's comment as a more application layer thing, i.e. a 
> question whether we should work on an abstract API (not a binding to a 
> particular programming language) which applications can use to
>  - observe what is going on below (which locator pair is used now? 
> what interface - GPRS or 802.11 - is being used?),
>  - express preferences (don't even try over GPRS type things) or some 
> other way to control things
>
> I think that area is interesting, but could be a rat hole. Those 
> issues are more about interface selection and performance 
> characteristics of the path, then about multihoming. That is, such 
> approaches would be useful (or not) even in the absence of shim6 
> below. There might be some added motivation for addressing this in the 
> multihoming context, if multihoming causes more dynamic variation in 
> the paths that are being used over time than what we see in today's. 
> However, in the case of site multihoming, I think the variation will 
> not be much different than IPv4 single prefix multihoming today when 
> routing selects different paths; it is the host multihoming case which 
> potentially makes this a more pressing issue - see the GRPS vs. WLAN 
> examples above.
>
> I don't see a need to add anything about this to the charter though.

Ok, I think I misunderstood Marcelo then. However, I would assume that 
at least some text on application layer 'events'  should be included in 
either the architecture or the protocol document?

- - kurtis -

Delivery-date: Thu, 27 Jan 2005 09:12:49 +0000
Cc: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: New version of charter text
Date: Thu, 27 Jan 2005 10:14:06 +0100
To: Erik Nordmark <[email-masked]>

On 2005-01-26, at 20.56, Erik Nordmark wrote:

> Kurt Erik Lindqvist wrote:
>
>> Some state transitions may result from external events however, such
>> as failure detection rather than from protocol events. These should be
>> documented in a seperate draft.
>
> I don't know if I understand the first sentence, since "failure 
> detection" will be part of the shim6 suite. I think what you want to 
> say is that there are events (or hints) external to the multi6 
> protocol
> (for instance, interfaces coming and going, ICMP errors, transport 
> protocol hints about working/not-working), that need to be fed into 
> the shim6 failure detection.
> How about
> "The shim6 failure detection can take advantage of external events or 
> hints, from instance from the network or from the transport protocols, 
> to operate more efficiently."

Ok, agreed.

>> The WG will not consider items outside the above scope, such as
>> interaction with mobility, transport level solutions, or alternative
>> identifier formats. However, the WG will consider developing methods
>> for the shim6 level to handle transport layer signalling to the shim6
>> layer as in scope.
>
> Are you trying to say "interaction with transport level solutions" are 
> out of scope, or that "transport level solutions" are out of scope?
> The latter is clearly out of scope, but the text above can be read as 
> the interactions applying to the text after the comma.
>
> I think it would be interesting to look at how multi-locator aware 
> protocols like SCTP and DCCP would operate when there is a shim below, 
> but I don't think this is on the critical path and should be a 
> separate document.

I think that text was originally written by Brian, but I always read it 
as "transport level solutions". However, I think that adding additional 
work like what you describe above might be something for later. Still 
it should be done, and I think that was one of the things we discussed 
in D.C (brought up by Jim Bound and later channelled by Brian). Not 
sure that we want to include it from the start though?

- - kurtis -

Delivery-date: Thu, 27 Jan 2005 09:07:40 +0000
Cc: [email-masked], marcelo bagnulo braun <[email-masked]>
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: New version of charter text
Date: Thu, 27 Jan 2005 10:08:45 +0100
To: Brian E Carpenter <[email-masked]>

On 2005-01-26, at 17.26, Brian E Carpenter wrote:

>>>
>>> what about a new shim API? I mean a new API that allows the apps to 
>>> communicate with the shim and inform about failures or other stuff, 
>>> would this be within scope?
>> Well, I added the transport layer "hints" as proposed by Erik, 
>> perhaps we should rewrite this into simply "shim layer API" ?
>
> I'm not sure we should commit to an API. We might well want to
> specify it conceptually, i.e. a bit more than hints, but
> not really get into the API deinition game, which the IETF
> usually leaves to others.

I used the word signalling in the new version. Not sure if that is 
"conceptual" enough?

>>> Don't we need to include the additional items that are mentioned 
>>> above as milestones also, such as: ingress filtering solution, 
>>> mechanism for establishing new communications with legacy hosts, TE 
>>> capabilities description?
>> TE, and perhaps ingress filtering I envisioned in the applicability 
>> document. The new communication establishment I envisioned to be 
>> addressed in the multihoming event trigger document (but come to 
>> think about it, this perhaps should be somewhere else).
>
> It might be separate. But we could decide that later.

So we leave it as it is? Or should we explicitly describe the 
applicability document?

- - kurtis -

Delivery-date: Wed, 26 Jan 2005 22:01:35 +0000
Date: Wed, 26 Jan 2005 14:00:45 -0800
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked]
Subject: Re: about draft-ietf-multi6-l3shim-00.txt

marcelo bagnulo braun wrote:
 > Hi Erik,
 >
 > I think the document is very clear. I have some comments below...

Thanks for the careful review.

 > I would say that the assumption being made is even stronger than this.
 > In addition to what is stated, there is another assumption being made
 > w.r.t. to the site exit router selection. Precisely, i think that the
 > solution assumes that a modification in the source and destination
 > addresses would result in a change of the site exit path used to route
 > both incoming and outgoing packets. This assumption holds true trivially
 > for incoming packets since we are assuming provider aggregatable
 > addressing, but for the case of outgoing traffic, this is not trivial
 > and some mechanisms are needed for this (in particular some of the
 > ingress filtering mechanisms also provide such functionality, but note
 > that there are some solution for the ingress filtering compatibility
 > problem (like address rewriting or simply relaxing ingress filters) that
 > solve the ingress filtering problem but don't provide this functionality)

That might very well be one way we end up addressing the ingress 
filtering and source address relationship, but I don't think the shim6 
approach necessarily assumes that the source address must affect the 
chose exit. If there is a need to be able to explore all exits (which is 
actually a question) i.e. packets transmitted by A to B should take all 
possible exits from A's site, then the source,destination pair of 
locators need to be able to cause the different exits.
But depending on the complexity of such solutions we might decide that 
they are not worth-while.

In any case, I think it is premature to state this as an assumption of 
the form "the source address must affect the exit".

 >
 >> 2.  Terminology
 >
 >
 > [...]
 >
 >>       identifier  - an IP layer identifier for an IP layer endpoint
 >>                     (stack name in [NSRG]).  The transport endpoint is a
 >
 > 
^name?
 >
 > maybe i am not understanding this, but isn't a "name" missing above?

Yes, that is the easiest edit. It could say "The transport endpoint is a 
function of the transport level, and the transport endpoint *name* would 
typically ..." but that doesn't add much.

 >>                     function of the transport protocol and would
 >>                     typically include the IP identifier plus a port
 >>                     number.  NOTE: This proposal does not contain any IP
 >>                     layer identifiers.
 >>
 >>       upper-layer identifier (ULID)
 >>                   - an IP locator which has been selected for
 >
 >
 > Wouldn't be better to substitute locator for address in this definition?

Well, it is a locator, so I guess it could be either.
FWIW The document tries to use the term "address" very sparingly (and 
I'll fix it to be even more careful). The document uses the term 
"address field" liberally, but that is not the same as the "address" term.

 >> 4.2.  Renumbering Implications
 >>
 >>    As stated above, this approach does not target to not make
 >
 >
 > remove one of the "not" above

Oops

 >>    This potential source for confusion can be avoided if we require that
 >>    any communication using a ULID must be terminated when the ULID
 >>    becomes invalid (due to the underlying prefix becoming invalid).
 >>
 >
 > I think this is an overkill.
 > Which is the probability of this event? i mean, the event is that the
 > prefix is renumbered and assigned to another site within the lifetime of
 > an established communication, and then that the same address is assigned
 > to a host (only this is 2^(-64)) and then that this host establishes a
 > communication with the same host that the initial one is communicating...
 > I wouldn't worry about this case.

I'll edit your text above and add it to the document.

 > But, presumably, the MTU change would occur, as you mention, after a
 > locator failure. This means that a new path will be used after this, and
 > this, by itself, may imply a change in the available MTU. So, my point
 > is that the change on the MTU is inherent of the fact that we are
 > changing the path used for an established communication and not only due
 > to the addition of an additional extension header.

I'll also add the above to the document.

 >> 7.1.  DNS and Centrally Assigned Unique-local Addresses
 >>
 >>    Earlier we've mentioned that the protocol might provide the basic
 >>    mechanism to use Unique-local addresses as ULIDs.
 >>
 >>    In the cases where hosts have been assigned centrally assigned ULAs
 >>    [ULA-CENTRAL], one can potentially take advantage of this to provide
 >>    better support for applications.  With centrally assigned ULAs it is
 >>    possible to register them in the reverse DNS tree.  As a result, one
 >>    could use the DNS not only for applications which care about reverse
 >>    and forward tree being consistent, but also to find the full set of
 >>    locators from the ULID.
 >>
 >>
 >
 >
 > But this is the case not only for Centrally assigned ULAs, but for also
 > for all routable addresses, right?
 > So i would suggest to move this (very valuable) comment to the previous
 > section, that makes general observations about the DNS.

Yes, text needs to be yet more clear on what is ULA specific.
The key point the doc should make is that in some cases consistent 
reverse and forward trees for a locator set are hard (such as two 
"consumer" ISPs each providing DNS, but no way for the site to control 
what goes in the DNS for the reverse tree). Using centrally assigned 
ULAs means that the site can interact with the entity assigning the ULA 
to get consistent reverse DNS.

 >>         When the policy is triggered, which could be on either A or B,
 >>         an initial context establishment takes place.  This exchange
 >>         might fail should the peer not support the multi6 protocol.  If
 >
 >
 > I don't understand the usage of the "should" of the last sentence (but
 > this is probably me)

English isn't my mother tongue either. I'll reword to use "if" instead:
"This exchange will fail if the peer does not support the multi6 protocol."

 >>         it succeeds it results in both ends receiving the locator sets
 >>         from their respective peer, and the security mechanism provides
 >>         some way to verify these sets.
 >>
 >>         At this point in time it is possible for the hosts to change to
 >>         a different locator in the set.  But until they have exchanged
 >>         the locator sets, and probably until they rehome the context to
 >
 >
 > i would remove the "probably" in the previous sentence ( i mean, only
 > after a rehoming they will start using a new locator, right?)

Well, they might send test packets after they have a locator set for the 
peer, so there would be some difference in the packets they send.

 >>    Note that we do not yet understand how beneficial it would be to be
 >>    able to accept packets from unknown source locators (the rules for
 >>    packet injection can probably be more relaxed than for where packets
 >
 >
 > i don't understand this sentence... wouldn't it be "reception" rather
 > than "injection"?

Yes

 >>    The alternative would be to layer multi6 above IPsec, but that
 >>    doesn't seem to provide any benefits and it would add the need to
 >>    create different IPsec SAs when the locators change due to rehoming.
 >>
 >
 > wouldn't be good to refer to the mobike work at this point?

Would should the document say other than just "[MOBIKE]"
?

    Erik

Delivery-date: Wed, 26 Jan 2005 20:07:11 +0000
Content-class: urn:content-classes:message
Subject: RE: New version of charter text
Date: Wed, 26 Jan 2005 22:04:36 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Eric,

I think your comments seem reasonable, some comments:

> > Some state transitions may result from external events however, such
> > as failure detection rather than from protocol events. These should be
> > documented in a seperate draft.
> 
> I don't know if I understand the first sentence, since "failure 
> detection" will be part of the shim6 suite. I think what you want to say 
> is that there are events (or hints) external to the multi6 protocol
> (for instance, interfaces coming and going, ICMP errors, transport 
> protocol hints about working/not-working), that need to be fed into the 
> shim6 failure detection.
> How about
> "The shim6 failure detection can take advantage of external events or 
> hints, from instance from the network or from the transport protocols, 
         ^^^^ 
         for

> to operate more efficiently."
> 
> > The WG will not consider items outside the above scope, such as
> > interaction with mobility, transport level solutions, or alternative
> > identifier formats. However, the WG will consider developing methods
> > for the shim6 level to handle transport layer signalling to the shim6
> > layer as in scope.
> 
> Are you trying to say "interaction with transport level solutions" are 
> out of scope, or that "transport level solutions" are out of scope?
> The latter is clearly out of scope, but the text above can be read as 
> the interactions applying to the text after the comma.

I take it to mean that shim6 will not modify the transport layer, but
may have some interaction with the transport layer (aka - transport
layer triggers or indicators).

> I think it would be interesting to look at how multi-locator aware 
> protocols like SCTP and DCCP would operate when there is a shim below, 
> but I don't think this is on the critical path and should be a separate 
> document.

I think that this would be premature to consider at this point, but might
be reasonable later on, once we have a good idea of the problem space
- i.e. - leave this type of stuff for rechartering.

John

Delivery-date: Wed, 26 Jan 2005 20:05:40 +0000
Date: Wed, 26 Jan 2005 12:04:57 -0800
From: Erik Nordmark <[email-masked]>
To: Kurt Erik Lindqvist <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: Re: New version of charter text

Kurt Erik Lindqvist wrote:

>>what about a new shim API? I mean a new API that allows the apps to 
>>communicate with the shim and inform about failures or other stuff, 
>>would this be within scope?
> 
> 
> Well, I added the transport layer "hints" as proposed by Erik, perhaps 
> we should rewrite this into simply "shim layer API" ?

I think the charter is reasonably clear on the hints/interactions with 
failure detection.

I read Marcelo's comment as a more application layer thing, i.e. a 
question whether we should work on an abstract API (not a binding to a 
particular programming language) which applications can use to
  - observe what is going on below (which locator pair is used now? what 
interface - GPRS or 802.11 - is being used?),
  - express preferences (don't even try over GPRS type things) or some 
other way to control things

I think that area is interesting, but could be a rat hole. Those issues 
are more about interface selection and performance characteristics of 
the path, then about multihoming. That is, such approaches would be 
useful (or not) even in the absence of shim6 below. There might be some 
added motivation for addressing this in the multihoming context, if 
multihoming causes more dynamic variation in the paths that are being 
used over time than what we see in today's. However, in the case of site 
multihoming, I think the variation will not be much different than IPv4 
single prefix multihoming today when routing selects different paths; it 
is the host multihoming case which potentially makes this a more 
pressing issue - see the GRPS vs. WLAN examples above.

I don't see a need to add anything about this to the charter though.

    Erik

Delivery-date: Wed, 26 Jan 2005 19:57:35 +0000
Date: Wed, 26 Jan 2005 11:56:43 -0800
From: Erik Nordmark <[email-masked]>
To: Kurt Erik Lindqvist <[email-masked]>
CC: [email-masked]
Subject: Re: New version of charter text

Kurt Erik Lindqvist wrote:

> Some state transitions may result from external events however, such
> as failure detection rather than from protocol events. These should be
> documented in a seperate draft.

I don't know if I understand the first sentence, since "failure 
detection" will be part of the shim6 suite. I think what you want to say 
is that there are events (or hints) external to the multi6 protocol
(for instance, interfaces coming and going, ICMP errors, transport 
protocol hints about working/not-working), that need to be fed into the 
shim6 failure detection.
How about
"The shim6 failure detection can take advantage of external events or 
hints, from instance from the network or from the transport protocols, 
to operate more efficiently."

> The WG will not consider items outside the above scope, such as
> interaction with mobility, transport level solutions, or alternative
> identifier formats. However, the WG will consider developing methods
> for the shim6 level to handle transport layer signalling to the shim6
> layer as in scope.

Are you trying to say "interaction with transport level solutions" are 
out of scope, or that "transport level solutions" are out of scope?
The latter is clearly out of scope, but the text above can be read as 
the interactions applying to the text after the comma.

I think it would be interesting to look at how multi-locator aware 
protocols like SCTP and DCCP would operate when there is a shim below, 
but I don't think this is on the critical path and should be a separate 
document.

    Erik

Delivery-date: Wed, 26 Jan 2005 17:43:59 +0000
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: about draft-ietf-multi6-l3shim-00.txt
Date: Wed, 26 Jan 2005 18:43:59 +0100
To: [email-masked]

I don't know if the chairs agree with discussing this doc here, but 
considering the title, i thought it was the right place.
If you prefer to move it to the multi6 list, please let me know.

Regards, marcelo
El 26/01/2005, a las 18:29, marcelo bagnulo braun escribió:

> Hi Erik,
>
> I think the document is very clear. I have some comments below...
>
> Regards, marcelo
>
>
> El 11/01/2005, a las 7:08, Erik Nordmark escribió:
>
>>
>>
>> 1.2.  Assumptions
>>
>>    This approach assumes that packets with arbitrary combinations of
>>    source and destination locators will make it from end to end unless
>>    there is some form of failure.  Due to the interaction between
>>    ingress filtering [RFC2827] and source address selection, this
>>    assumption might not be true in IPv6 today.  As a result there is a
>>    need to work out a solution that doesn't make the ingress filtering
>>    in ISPs drop more packets than needed.  Some solutions to this have
>>    been proposed in [INGRESS].
>>
>
> I would say that the assumption being made is even stronger than this. 
> In addition to what is stated, there is another assumtion being made 
> w.r.t. to the site exit router selection. Precisely, i think that the 
> solution assumes that a modification in the source and destination 
> addresses would result in a change of the site exit path used to route 
> both incoming and outgoing packets. This assumption holds true 
> trivially for incoming packets since we are assuming provider 
> aggregatable addressing, but for the case of outgoing traffic, this is 
> not trivial and some mechanisms are needed for this (in particular 
> some of the ingress filtering mechanisms also provide such 
> functionality, but note that there are some solution for the ingress 
> filtering compatibility problem (like address rewriting or simply 
> relaxing ingress filters) that solve the ingress filtering problem but 
> don't provide this functionality)
>
>
>
>
>> 2.  Terminology
>
> [...]
>
>>       identifier  - an IP layer identifier for an IP layer endpoint
>>                     (stack name in [NSRG]).  The transport endpoint 
>> is a
>                                                                     
> ^name?
>
> maybe i am not understanding this, but isn't a "name" missing above?
>
>
>>                     function of the transport protocol and would
>>                     typically include the IP identifier plus a port
>>                     number.  NOTE: This proposal does not contain any 
>> IP
>>                     layer identifiers.
>>
>>       upper-layer identifier (ULID)
>>                   - an IP locator which has been selected for
>
> Wouldn't be better to substitute locator for address in this 
> definition?
>
>
>>                     communication with a peer to be used by the upper
>>                     layer protocol.  128 bits.  This is used for
>>                     pseudo-header checksum computation and connection
>>
>>
>
> [...]
>
>>
>>
>> 4.2.  Renumbering Implications
>>
>>    As stated above, this approach does not target to not make
>
> remove one of the "not" above
>
>>    communication survive renumbering.  However, the fact that a ULID
>>    might be used with a different locator over time open up the
>>    possibility that communication between two ULIDs might continue to
>>    work after one or both of those ULIDs are no longer reachable as
>>    locators, for example due to a renumbering event.  This opens up 
>> the
>>    possibility that the ULID (or at least the prefix on which it is
>>    based) is reassigned to another site while it is still being used
>>    (with another locator) for existing communication.
>>
>>    Worst case we could end up with two separate hosts using the same
>>    ULID while both of them are communicating with the same host.
>>
>>    This potential source for confusion can be avoided if we require 
>> that
>>    any communication using a ULID must be terminated when the ULID
>>    becomes invalid (due to the underlying prefix becoming invalid).
>>
>
> I think this is an overkill.
> Which is the probability of this event? i mean, the event is that the 
> prefix is renumbered and assigned to another site within the lifetime 
> of an established communication, and then that the same address is 
> assigned to a host (only this is 2^(-64)) and then that this host 
> establishes a communication with the same host that the initial one is 
> communicating...
> I wouldn't worry about this case.
>
> [...]
>
>> 5.4.  MTU Implications
>>
>>    Depending on how demultiplexing is handled at the receiver (see
>>    subsequent sections) there may or may not be a need for the shim to
>>    add an extension header to the packets.  In some cases such an
>>    extension header would only need to be added to some and not all 
>> data
>>    packets.
>>
>>    This has implications on the MTU that is available to the upper 
>> layer
>>    protocols hence will require some extra handling in the host
>>    implementation.  At some level this is similar to the MTU
>>    implementations of IPsec, in that the IP layer would add bytes to
>>    some ULP packets and not others, but in the case of IPsec one would
>>    expect all or no packets in a particular ULP connection to be
>>    affected, whereas in multi6 one some packets, such as those sent
>>    after a locator failure, would be subject to a reduction in the
>>    available MTU.
>>
>
> But, presumably, the MTU change would occur, as you mention, after a 
> locator failure. This means that a new path will be used after this, 
> and this, by itself, may imply a change in the available MTU. So, my 
> point is that the change on the MTU is inherent of the fact that we 
> are changing the path used for an established communication and not 
> only due to the addition of an additional extension header.
>
> [...]
>> 7.  Assumptions about the DNS
>>
>>    This approach assumes that hosts in multihomed sites have multiple
>>    AAAA records under a single name, in order to allow initial
>>    communication to try all the locators.  For multi6 capable hosts, 
>> the
>>    content of those records are the locators (which also serve as
>>    ULIDs).
>>
>>    However, the approach does not assume that all the AAAA records 
>> for a
>>    given name refer to the same host.  Instead the context 
>> establishment
>>    allows each host to pass its locators to the peer.  This set could 
>> be
>>    either smaller or larger (or neither) than the AAAA record set.
>>
>>    The approach makes no assumption about the reverse tree since the
>>    approach does not use it.  However, applications might rely on the
>>    reverse tree whether multi6 is used or not.
>>
>> 7.1.  DNS and Centrally Assigned Unique-local Addresses
>>
>>    Earlier we've mentioned that the protocol might provide the basic
>>    mechanism to use Unique-local addresses as ULIDs.
>>
>>    In the cases where hosts have been assigned centrally assigned ULAs
>>    [ULA-CENTRAL], one can potentially take advantage of this to 
>> provide
>>    better support for applications.  With centrally assigned ULAs it 
>> is
>>    possible to register them in the reverse DNS tree.  As a result, 
>> one
>>    could use the DNS not only for applications which care about 
>> reverse
>>    and forward tree being consistent, but also to find the full set of
>>    locators from the ULID.
>>
>>
>
>
> But this is the case not only for Centrally assigned ULAs, but for 
> also for all routable addresses, right?
> So i would suggest to move this (very valuable) comment to the 
> previous section, that makes general observations about the DNS.
>
>>
>> 8.  Protocol Walkthrough
>> 8.1.  Initial Context Establishment
>>
>>
>>    Here is the sequence of events when A starts talking to B:
>>
>>     1.  A looks up FQDN(B) in the DNS which returns a locator set 
>> which
>>         includes some locators for B.  (The set could include locators
>>         for other hosts since e.g., www.example.com might include AAAA
>>         records for multiple hosts.)  The application would typically
>>         try to connect using the first locator in the set i.e., 
>> ULID(B)
>>         = L1(B).  The application is prepared to try the other 
>> locators
>>         should the first one fail.
>>
>>     2.  The ULP creates "connection" state between ULID(A)=L1(A) and
>>         ULID(B) and sends the first packet down to the IP/multi6 shim
>>         layer on A.  L1(A) was picked using regular source address
>>         selection mechanisms.
>>
>>     3.  The packet passes through the multi6 layer, which has no state
>>         for ULID(B).  A local policy will be used to determine when, 
>> if
>>         at all, to attempt to setup multi6 state with the peer.  Until
>>         this state triggers packets pass back and forth between A and 
>> B
>>         as they do in unmodified IPv6 today.
>>
>>         When the policy is triggered, which could be on either A or B,
>>         an initial context establishment takes place.  This exchange
>>         might fail should the peer not support the multi6 protocol.  
>> If
>
> I don't understand the usage of the "should" of the last sentence (but 
> this is probably me)
>
>
>>         it succeeds it results in both ends receiving the locator sets
>>         from their respective peer, and the security mechanism 
>> provides
>>         some way to verify these sets.
>>
>>         At this point in time it is possible for the hosts to change 
>> to
>>         a different locator in the set.  But until they have exchanged
>>         the locator sets, and probably until they rehome the context 
>> to
>
> i would remove the "probably" in the previous sentence ( i mean, only 
> after a rehoming they will start using a new locator, right?)
>>
>
> [...]
>
>> 9.2.1.  Flow-label
>>
>>
>
> [...]
>
>>
>>    Note that we do not yet understand how beneficial it would be to be
>>    able to accept packets from unknown source locators (the rules for
>>    packet injection can probably be more relaxed than for where 
>> packets
>
> i don't understand this sentence... wouldn't it be "reception" rather 
> than "injection"?
>>
>
> [...]
>
>> 10.  IPSEC INTERACTIONS
>>
>>    As specified, all of ESP, AH, and key management is layered above 
>> the
>>    multi6 layer.  Thus they benefit from the stable ULIDs provided 
>> above
>>    the multi6 layer.  This means the IPsec security associations are
>>    unaffected by switching locators.
>>
>>    The alternative would be to layer multi6 above IPsec, but that
>>    doesn't seem to provide any benefits and it would add the need to
>>    create different IPsec SAs when the locators change due to 
>> rehoming.
>>
>
> wouldn't be good to refer to the mobike work at this point?
>
>

Delivery-date: Wed, 26 Jan 2005 17:29:25 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: about draft-ietf-multi6-l3shim-00.txt
Date: Wed, 26 Jan 2005 18:29:16 +0100
To: Erik Nordmark <[email-masked]>

Hi Erik,

I think the document is very clear. I have some comments below...

Regards, marcelo

El 11/01/2005, a las 7:08, Erik Nordmark escribió:

>
>
> 1.2.  Assumptions
>
>    This approach assumes that packets with arbitrary combinations of
>    source and destination locators will make it from end to end unless
>    there is some form of failure.  Due to the interaction between
>    ingress filtering [RFC2827] and source address selection, this
>    assumption might not be true in IPv6 today.  As a result there is a
>    need to work out a solution that doesn't make the ingress filtering
>    in ISPs drop more packets than needed.  Some solutions to this have
>    been proposed in [INGRESS].
>

I would say that the assumption being made is even stronger than this. 
In addition to what is stated, there is another assumtion being made 
w.r.t. to the site exit router selection. Precisely, i think that the 
solution assumes that a modification in the source and destination 
addresses would result in a change of the site exit path used to route 
both incoming and outgoing packets. This assumption holds true 
trivially for incoming packets since we are assuming provider 
aggregatable addressing, but for the case of outgoing traffic, this is 
not trivial and some mechanisms are needed for this (in particular some 
of the ingress filtering mechanisms also provide such functionality, 
but note that there are some solution for the ingress filtering 
compatibility problem (like address rewriting or simply relaxing 
ingress filters) that solve the ingress filtering problem but don't 
provide this functionality)

> 2.  Terminology

[...]

>       identifier  - an IP layer identifier for an IP layer endpoint
>                     (stack name in [NSRG]).  The transport endpoint is 
> a
                                                                     
^name?

maybe i am not understanding this, but isn't a "name" missing above?

>                     function of the transport protocol and would
>                     typically include the IP identifier plus a port
>                     number.  NOTE: This proposal does not contain any 
> IP
>                     layer identifiers.
>
>       upper-layer identifier (ULID)
>                   - an IP locator which has been selected for

Wouldn't be better to substitute locator for address in this definition?

>                     communication with a peer to be used by the upper
>                     layer protocol.  128 bits.  This is used for
>                     pseudo-header checksum computation and connection
>
>

[...]

>
>
> 4.2.  Renumbering Implications
>
>    As stated above, this approach does not target to not make

remove one of the "not" above

>    communication survive renumbering.  However, the fact that a ULID
>    might be used with a different locator over time open up the
>    possibility that communication between two ULIDs might continue to
>    work after one or both of those ULIDs are no longer reachable as
>    locators, for example due to a renumbering event.  This opens up the
>    possibility that the ULID (or at least the prefix on which it is
>    based) is reassigned to another site while it is still being used
>    (with another locator) for existing communication.
>
>    Worst case we could end up with two separate hosts using the same
>    ULID while both of them are communicating with the same host.
>
>    This potential source for confusion can be avoided if we require 
> that
>    any communication using a ULID must be terminated when the ULID
>    becomes invalid (due to the underlying prefix becoming invalid).
>

I think this is an overkill.
Which is the probability of this event? i mean, the event is that the 
prefix is renumbered and assigned to another site within the lifetime 
of an established communication, and then that the same address is 
assigned to a host (only this is 2^(-64)) and then that this host 
establishes a communication with the same host that the initial one is 
communicating...
I wouldn't worry about this case.

[...]

> 5.4.  MTU Implications
>
>    Depending on how demultiplexing is handled at the receiver (see
>    subsequent sections) there may or may not be a need for the shim to
>    add an extension header to the packets.  In some cases such an
>    extension header would only need to be added to some and not all 
> data
>    packets.
>
>    This has implications on the MTU that is available to the upper 
> layer
>    protocols hence will require some extra handling in the host
>    implementation.  At some level this is similar to the MTU
>    implementations of IPsec, in that the IP layer would add bytes to
>    some ULP packets and not others, but in the case of IPsec one would
>    expect all or no packets in a particular ULP connection to be
>    affected, whereas in multi6 one some packets, such as those sent
>    after a locator failure, would be subject to a reduction in the
>    available MTU.
>

But, presumably, the MTU change would occur, as you mention, after a 
locator failure. This means that a new path will be used after this, 
and this, by itself, may imply a change in the available MTU. So, my 
point is that the change on the MTU is inherent of the fact that we are 
changing the path used for an established communication and not only 
due to the addition of an additional extension header.

[...]
> 7.  Assumptions about the DNS
>
>    This approach assumes that hosts in multihomed sites have multiple
>    AAAA records under a single name, in order to allow initial
>    communication to try all the locators.  For multi6 capable hosts, 
> the
>    content of those records are the locators (which also serve as
>    ULIDs).
>
>    However, the approach does not assume that all the AAAA records for 
> a
>    given name refer to the same host.  Instead the context 
> establishment
>    allows each host to pass its locators to the peer.  This set could 
> be
>    either smaller or larger (or neither) than the AAAA record set.
>
>    The approach makes no assumption about the reverse tree since the
>    approach does not use it.  However, applications might rely on the
>    reverse tree whether multi6 is used or not.
>
> 7.1.  DNS and Centrally Assigned Unique-local Addresses
>
>    Earlier we've mentioned that the protocol might provide the basic
>    mechanism to use Unique-local addresses as ULIDs.
>
>    In the cases where hosts have been assigned centrally assigned ULAs
>    [ULA-CENTRAL], one can potentially take advantage of this to provide
>    better support for applications.  With centrally assigned ULAs it is
>    possible to register them in the reverse DNS tree.  As a result, one
>    could use the DNS not only for applications which care about reverse
>    and forward tree being consistent, but also to find the full set of
>    locators from the ULID.
>
>

But this is the case not only for Centrally assigned ULAs, but for also 
for all routable addresses, right?
So i would suggest to move this (very valuable) comment to the previous 
section, that makes general observations about the DNS.

>
> 8.  Protocol Walkthrough
> 8.1.  Initial Context Establishment
>
>
>    Here is the sequence of events when A starts talking to B:
>
>     1.  A looks up FQDN(B) in the DNS which returns a locator set which
>         includes some locators for B.  (The set could include locators
>         for other hosts since e.g., www.example.com might include AAAA
>         records for multiple hosts.)  The application would typically
>         try to connect using the first locator in the set i.e., ULID(B)
>         = L1(B).  The application is prepared to try the other locators
>         should the first one fail.
>
>     2.  The ULP creates "connection" state between ULID(A)=L1(A) and
>         ULID(B) and sends the first packet down to the IP/multi6 shim
>         layer on A.  L1(A) was picked using regular source address
>         selection mechanisms.
>
>     3.  The packet passes through the multi6 layer, which has no state
>         for ULID(B).  A local policy will be used to determine when, if
>         at all, to attempt to setup multi6 state with the peer.  Until
>         this state triggers packets pass back and forth between A and B
>         as they do in unmodified IPv6 today.
>
>         When the policy is triggered, which could be on either A or B,
>         an initial context establishment takes place.  This exchange
>         might fail should the peer not support the multi6 protocol.  If

I don't understand the usage of the "should" of the last sentence (but 
this is probably me)

>         it succeeds it results in both ends receiving the locator sets
>         from their respective peer, and the security mechanism provides
>         some way to verify these sets.
>
>         At this point in time it is possible for the hosts to change to
>         a different locator in the set.  But until they have exchanged
>         the locator sets, and probably until they rehome the context to

i would remove the "probably" in the previous sentence ( i mean, only 
after a rehoming they will start using a new locator, right?)
>

[...]

> 9.2.1.  Flow-label
>
>

[...]

>
>    Note that we do not yet understand how beneficial it would be to be
>    able to accept packets from unknown source locators (the rules for
>    packet injection can probably be more relaxed than for where packets

i don't understand this sentence... wouldn't it be "reception" rather 
than "injection"?
>

[...]

> 10.  IPSEC INTERACTIONS
>
>    As specified, all of ESP, AH, and key management is layered above 
> the
>    multi6 layer.  Thus they benefit from the stable ULIDs provided 
> above
>    the multi6 layer.  This means the IPsec security associations are
>    unaffected by switching locators.
>
>    The alternative would be to layer multi6 above IPsec, but that
>    doesn't seem to provide any benefits and it would add the need to
>    create different IPsec SAs when the locators change due to rehoming.
>

wouldn't be good to refer to the mobike work at this point?

Delivery-date: Wed, 26 Jan 2005 16:34:31 +0000
Cc: Kurt Erik Lindqvist <[email-masked]>, [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: New version of charter text
Date: Wed, 26 Jan 2005 17:34:33 +0100
To: Brian E Carpenter <[email-masked]>

El 26/01/2005, a las 17:26, Brian E Carpenter escribió:

> Kurt Erik Lindqvist wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> On 2005-01-26, at 16.28, marcelo bagnulo braun wrote:
>>> El 26/01/2005, a las 13:20, Kurt Erik Lindqvist escribió:
>>>
>>>>  draft-ietf-multi6-l3shim-00.txt [to be published shortly]
>>>>
>>>
>>> FWIW this one is already available FWIK
>> Oops. I missed to remove that. Thanks!
>>>> [What other topics are explicitly in/out of scope?]
>>>
>>> what about a new shim API? I mean a new API that allows the apps to 
>>> communicate with the shim and inform about failures or other stuff, 
>>> would this be within scope?
>> Well, I added the transport layer "hints" as proposed by Erik, 
>> perhaps we should rewrite this into simply "shim layer API" ?
>
> I'm not sure we should commit to an API. We might well want to
> specify it conceptually, i.e. a bit more than hints, but
> not really get into the API deinition game, which the IETF
> usually leaves to others.
>

i don't have a strong opinion about this point, it was just a naif 
question :-)
so, i am fine with this.

>>> Don't we need to include the additional items that are mentioned 
>>> above as milestones also, such as: ingress filtering solution, 
>>> mechanism for establishing new communications with legacy hosts, TE 
>>> capabilities description?
>> TE, and perhaps ingress filtering I envisioned in the applicability 
>> document. The new communication establishment I envisioned to be 
>> addressed in the multihoming event trigger document (but come to 
>> think about it, this perhaps should be somewhere else).
>
> It might be separate. But we could decide that later.
>

ok, we can leave it open for now.

Regards, marcelo

>    Brian
>

Delivery-date: Wed, 26 Jan 2005 16:27:03 +0000
Date: Wed, 26 Jan 2005 17:26:51 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Kurt Erik Lindqvist <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, [email-masked]
Subject: Re: New version of charter text

Kurt Erik Lindqvist wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On 2005-01-26, at 16.28, marcelo bagnulo braun wrote:
> 
>>El 26/01/2005, a las 13:20, Kurt Erik Lindqvist escribiÃ³:
>>
>>>  draft-ietf-multi6-l3shim-00.txt [to be published shortly]
>>>
>>
>>FWIW this one is already available FWIK
> 
> 
> Oops. I missed to remove that. Thanks!
> 
> 
>>>[What other topics are explicitly in/out of scope?]
>>
>>what about a new shim API? I mean a new API that allows the apps to 
>>communicate with the shim and inform about failures or other stuff, 
>>would this be within scope?
> 
> 
> Well, I added the transport layer "hints" as proposed by Erik, perhaps 
> we should rewrite this into simply "shim layer API" ?

I'm not sure we should commit to an API. We might well want to
specify it conceptually, i.e. a bit more than hints, but
not really get into the API deinition game, which the IETF
usually leaves to others.

> 
>>Don't we need to include the additional items that are mentioned above 
>>as milestones also, such as: ingress filtering solution, mechanism for 
>>establishing new communications with legacy hosts, TE capabilities 
>>description?
> 
> 
> TE, and perhaps ingress filtering I envisioned in the applicability 
> document. The new communication establishment I envisioned to be 
> addressed in the multihoming event trigger document (but come to think 
> about it, this perhaps should be somewhere else).

It might be separate. But we could decide that later.

    Brian

Delivery-date: Wed, 26 Jan 2005 16:17:55 +0000
Date: Wed, 26 Jan 2005 11:17:34 -0500
From: Scott W Brim <[email-masked]>
To: Kurt Erik Lindqvist <[email-masked]>
CC: [email-masked]
Subject: Re: New version of charter text

On 1/26/2005 10:49, Kurt Erik Lindqvist allegedly wrote:
> On 2005-01-26, at 16.28, marcelo bagnulo braun wrote:
>>> what about a new shim API? I mean a new API that allows the apps to 
>>> communicate with the shim and inform about failures or other stuff, 
>>> would this be within scope?
> 
> Well, I added the transport layer "hints" as proposed by Erik, perhaps 
> we should rewrite this into simply "shim layer API" ?

Greetings.  A good API will be OS-specific.  The best we could do 
would be at the semantic level.  You could, possibly, write something 
about requirements on an API, but I don't think it should be in the 
charter at this time.  Generally I think APIs, having nothing to do 
with what goes on the wire, are out of scope for the IETF.

On 1/26/2005 10:50, Kurt Erik Lindqvist allegedly wrote:
>> The new draft charter needs an editorial pass to clean out a number of 
>> typos, but it should be roughly OK.
> 
> Uhm, send text? :-)

I'll send some little things ... unicast.

Scott

Delivery-date: Wed, 26 Jan 2005 15:49:14 +0000
Cc: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: New version of charter text
Date: Wed, 26 Jan 2005 16:50:42 +0100
To: Pekka Savola <[email-masked]>

On 2005-01-26, at 16.35, Pekka Savola wrote:

> On Wed, 26 Jan 2005, Kurt Erik Lindqvist wrote:
>> - - I tried to address Pekka's concerns with TE, and someone in a mail
>> proposed an applicability document. I can't find that mail now so I am
>> not sure they referred to the same issue, but I would think that
>> documenting what uses you get from shim6 under what conditions would
>> address Pekka's comment. There is probably more that needs to be
>> documented in the same way.
>
> Yes, thanks.  (This could be either part of the protocol spec, or a 
> separate document, but I guess it's easier to document separately at 
> least at first.)

Agreedd.

> The new draft charter needs an editorial pass to clean out a number of 
> typos, but it should be roughly OK.

Uhm, send text? :-)

- - kurtis -

Delivery-date: Wed, 26 Jan 2005 15:48:25 +0000
Cc: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: New version of charter text
Date: Wed, 26 Jan 2005 16:49:45 +0100
To: marcelo bagnulo braun <[email-masked]>

On 2005-01-26, at 16.28, marcelo bagnulo braun wrote:
> El 26/01/2005, a las 13:20, Kurt Erik Lindqvist escribiÃ³:
>>   draft-ietf-multi6-l3shim-00.txt [to be published shortly]
>>
>
> FWIW this one is already available FWIK

Oops. I missed to remove that. Thanks!

>> [What other topics are explicitly in/out of scope?]
>
> what about a new shim API? I mean a new API that allows the apps to 
> communicate with the shim and inform about failures or other stuff, 
> would this be within scope?

Well, I added the transport layer "hints" as proposed by Erik, perhaps 
we should rewrite this into simply "shim layer API" ?

> Don't we need to include the additional items that are mentioned above 
> as milestones also, such as: ingress filtering solution, mechanism for 
> establishing new communications with legacy hosts, TE capabilities 
> description?

TE, and perhaps ingress filtering I envisioned in the applicability 
document. The new communication establishment I envisioned to be 
addressed in the multihoming event trigger document (but come to think 
about it, this perhaps should be somewhere else).

- - kurtis -

Delivery-date: Wed, 26 Jan 2005 15:35:40 +0000
Date: Wed, 26 Jan 2005 17:35:25 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: Kurt Erik Lindqvist <[email-masked]>
cc: [email-masked]
Subject: Re: New version of charter text

On Wed, 26 Jan 2005, Kurt Erik Lindqvist wrote:
> - - I tried to address Pekka's concerns with TE, and someone in a mail
> proposed an applicability document. I can't find that mail now so I am
> not sure they referred to the same issue, but I would think that
> documenting what uses you get from shim6 under what conditions would
> address Pekka's comment. There is probably more that needs to be
> documented in the same way.

Yes, thanks.  (This could be either part of the protocol spec, or a 
separate document, but I guess it's easier to document separately at 
least at first.)

The new draft charter needs an editorial pass to clean out a number of 
typos, but it should be roughly OK.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Wed, 26 Jan 2005 15:28:55 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: New version of charter text
Date: Wed, 26 Jan 2005 16:28:45 +0100
To: Kurt Erik Lindqvist <[email-masked]>

Hi Kurtis,

imho this is very good.
just a few nits, questions below...

El 26/01/2005, a las 13:20, Kurt Erik Lindqvist escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> 	All,
>
> please find below a new version of the charter text. And my apologies
> for this taking some time.
>
> Some notes,
>
> - - I tried to address Pekka's concerns with TE, and someone in a mail
> proposed an applicability document. I can't find that mail now so I am
> not sure they referred to the same issue, but I would think that
> documenting what uses you get from shim6 under what conditions would
> address Pekka's comment. There is probably more that needs to be
> documented in the same way.
>
> - - I included Marcelo's proposed work item on communication
> establishment.
>
> - - I changed the reference to a state machine to John's proposed text 
> on
> "multihoming triggers" that better referred to what I had originally
> through. I read Brian as still disagreeing (and I think I do to) on
> separating the statemachine from the protocol spec, but we seem to be
> the only two arguing for that :-)
>
> - - I moved the timeline for the protocol document a bit further away 
> as
> per Erik's comment.
>
> I hope that should cover most of what has been discussed.
>
> - - kurtis -
>
> - ----
>
>
>
> Site multiHoming by IPv6 interMediation (shim6)
>
> Description of Working Group:
>
> The shim6 WG is to produce specfifications for a complete IPv6 site
> multihoming solution based on the architecture developed by the IETF
> multi6 WG. The multi6 WG was tasked with investigating solutions to
> the site multihoming problem that will allow the global routing system
> to
> scale. The outcome of the multi6 WG is a specific network layer shim
> architecture for addressing and address handling of sites and nodes.
> This
> includes switching to different locator addresses when connectivity
> changes,
> but without the changes of address being visible to upper layers, which
> see
> a fixed Upper Layer Identifier address (ULID).
>
> The shim6 WG is to complete this work with the required protocol
> developments
> and complete the architecture and security analysis of the required
> protocols.
>
> The background documents to be considered by the WG include:
>
>   RFC 3582
>   draft-ietf-multi6-things-to-think-about-01.txt
>   draft-ietf-multi6-multihoming-threats-03.txt
>
> The input documents that the WG will use as the basis for its design
> are:
>
>   draft-huston-solution-stilltobewritten
>   draft-ietf-multi6-functional-dec-00.txt
>   draft-ietf-multi6-l3shim-00.txt [to be published shortly]
>

FWIW this one is already available FWIK

>   draft-ietf-multi6-failure-detection-00.txt [to be published shortly]
>   draft-ietf-multi6-hba-00.txt
>   draft-ietf-multi6-app-refer-00.txt
>
> The shim6 WG is to submit, as standards track RFCs, specifications with
> enough details to allow full interoperable implementations of the shim
> layer appproach to multihoming as agreed on by the multi6 WG. These
> implementations should have the ability to take advantage of
> multihoming without adding to the growth of the global routing table,
> by using the aggregates already announced by their upstream providers.
>
> Since the solution requires state to be maintained at both ends of a
> communication, the protocol specification docuement needs to contain a
> state machine description.
>
> Some state transitions may result from external events however, such
> as failure detection rather than from protocol events. These should be
> documented in a seperate draft.
>
> Multihoming is today also often used to achieve various other
> features, such as traffic-engineering. The Shim6 WG should document
> the use of the shim6 solution in these cases in an applicability
> document.
>
> More work items and milestones might need to be added at a later date 
> to
> complete all implementation details needed.
>
> In addition to the basic network layer shim solution, the shim6 WG
> is specifically chartered to do work on
>
>       o Solutions for site exit router selection that works when each 
> ISP
>         uses ingress filtering, i.e. when the chosen site exit needs to
> be
>         related to the source address chosen by the host. This solution
>         should work whether or not the peer site supports the shim6
> protocol.
>
>       o Solutions to establish new communications after an outage has
>         occurred that does not requires shim support from the
>         non-multihomed end of the communication. The wg will explore
>         if such solutions are also useful when both ends support the
> shim.
>
>       o Explore how congestion control and other QoS and traffic
> engineering
>         issues may interact with the use of multiple locators at both
> ends.
>
>       o Investigate relationship between Upper Layer Identifiers 
> (ULIDs)
>         and Unique Local Addresses.
>
>       o ICMP error demuxing for locator failure discovery.
>
>       o If necessary, develop and specify formats and structure for
>
>         - Cryptographically protected locators
>
>         - Carrying the flow label across the shim layer
>           defined in the multi6 architecture.
>
> The WG will consider whether the proposed model is exposed to
> any security threats in addition to those documented in
> draft-ietf-multi6-multihoming-threats-03.txt. In any case,
> the specifications must specifically refer to all applicable threats
> and describe how they are handled,  with the requirement being that
> the resulting solution not introduce any threats that make the
> security any less than in today's Internet.
>
> The WG will not consider items outside the above scope, such as
> interaction with mobility, transport level solutions, or alternative
> identifier formats. However, the WG will consider developing methods
> for the shim6 level to handle transport layer signalling to the shim6
> layer as in scope.
>
> [What other topics are explicitly in/out of scope?]

what about a new shim API? I mean a new API that allows the apps to 
communicate with the shim and inform about failures or other stuff, 
would this be within scope?

>
> Milestones
>
> MAY 05    First draft of architectural document
> MAY 05 	  First draft of protocol document
> MAY 05    First draft on cryptographic locators, if required
> MAY 05    First draft on multihoimg triggers description
> MAY 05 	  First draft on applicability statement document
>
> SEP 05    WG last-call on architectural document
> SEP 05	  WG last-call on applicability statement document
>
> NOV 05 	  WG last-call on protocol document
> NOV 05    WG last-call on cryptographic locators, if required
> NOV 05    Submit completed architectural document to IESG
> NOV 05	  Submit applicability statement document to IESG
>
> JAN 06    WG last-call on multihoming triggers description
> JAN 06    Submit document on cryptographic locators to the IESG, if
>      	  required
> JAN 06	  Submit protocol document to the IESG
>
> MAR 06    Submit draft on multihoming triggers description to the IESG
>

Don't we need to include the additional items that are mentioned above 
as milestones also, such as: ingress filtering solution, mechanism for 
establishing new communications with legacy hosts, TE capabilities 
description?

Regards, marcelo

> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBQfeLAaarNKXTPFCVEQK8agCgl5mYm6RZ7wensMPMjXXhY3uQx0AAoOJe
> eNPFzAkch34CwHSYK3TlvNsx
> =4QmB
> -----END PGP SIGNATURE-----
>
>

Delivery-date: Wed, 26 Jan 2005 12:18:54 +0000
To: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: New version of charter text
Date: Wed, 26 Jan 2005 13:20:10 +0100

	All,

please find below a new version of the charter text. And my apologies 
for this taking some time.

Some notes,

- - I tried to address Pekka's concerns with TE, and someone in a mail 
proposed an applicability document. I can't find that mail now so I am 
not sure they referred to the same issue, but I would think that 
documenting what uses you get from shim6 under what conditions would 
address Pekka's comment. There is probably more that needs to be 
documented in the same way.

- - I included Marcelo's proposed work item on communication 
establishment.

- - I changed the reference to a state machine to John's proposed text on 
"multihoming triggers" that better referred to what I had originally 
through. I read Brian as still disagreeing (and I think I do to) on 
separating the statemachine from the protocol spec, but we seem to be 
the only two arguing for that :-)

- - I moved the timeline for the protocol document a bit further away as 
per Erik's comment.

I hope that should cover most of what has been discussed.

- - kurtis -

- ----

Site multiHoming by IPv6 interMediation (shim6)

Description of Working Group:

The shim6 WG is to produce specfifications for a complete IPv6 site
multihoming solution based on the architecture developed by the IETF
multi6 WG. The multi6 WG was tasked with investigating solutions to
the site multihoming problem that will allow the global routing system 
to
scale. The outcome of the multi6 WG is a specific network layer shim
architecture for addressing and address handling of sites and nodes. 
This
includes switching to different locator addresses when connectivity 
changes,
but without the changes of address being visible to upper layers, which 
see
a fixed Upper Layer Identifier address (ULID).

The shim6 WG is to complete this work with the required protocol 
developments
and complete the architecture and security analysis of the required 
protocols.

The background documents to be considered by the WG include:

  RFC 3582
  draft-ietf-multi6-things-to-think-about-01.txt
  draft-ietf-multi6-multihoming-threats-03.txt

The input documents that the WG will use as the basis for its design 
are:

  draft-huston-solution-stilltobewritten
  draft-ietf-multi6-functional-dec-00.txt
  draft-ietf-multi6-l3shim-00.txt [to be published shortly]
  draft-ietf-multi6-failure-detection-00.txt [to be published shortly]
  draft-ietf-multi6-hba-00.txt
  draft-ietf-multi6-app-refer-00.txt

The shim6 WG is to submit, as standards track RFCs, specifications with
enough details to allow full interoperable implementations of the shim
layer appproach to multihoming as agreed on by the multi6 WG. These
implementations should have the ability to take advantage of
multihoming without adding to the growth of the global routing table,
by using the aggregates already announced by their upstream providers.

Since the solution requires state to be maintained at both ends of a
communication, the protocol specification docuement needs to contain a
state machine description.

Some state transitions may result from external events however, such
as failure detection rather than from protocol events. These should be
documented in a seperate draft.

Multihoming is today also often used to achieve various other
features, such as traffic-engineering. The Shim6 WG should document
the use of the shim6 solution in these cases in an applicability
document.

More work items and milestones might need to be added at a later date to
complete all implementation details needed.

In addition to the basic network layer shim solution, the shim6 WG
is specifically chartered to do work on

      o Solutions for site exit router selection that works when each ISP
        uses ingress filtering, i.e. when the chosen site exit needs to 
be
        related to the source address chosen by the host. This solution
        should work whether or not the peer site supports the shim6 
protocol.

      o Solutions to establish new communications after an outage has
        occurred that does not requires shim support from the
        non-multihomed end of the communication. The wg will explore
        if such solutions are also useful when both ends support the 
shim.

      o Explore how congestion control and other QoS and traffic 
engineering
        issues may interact with the use of multiple locators at both 
ends.

      o Investigate relationship between Upper Layer Identifiers (ULIDs)
        and Unique Local Addresses.

      o ICMP error demuxing for locator failure discovery.

      o If necessary, develop and specify formats and structure for

        - Cryptographically protected locators

        - Carrying the flow label across the shim layer
          defined in the multi6 architecture.

The WG will consider whether the proposed model is exposed to
any security threats in addition to those documented in
draft-ietf-multi6-multihoming-threats-03.txt. In any case,
the specifications must specifically refer to all applicable threats
and describe how they are handled,  with the requirement being that
the resulting solution not introduce any threats that make the
security any less than in today's Internet.

The WG will not consider items outside the above scope, such as
interaction with mobility, transport level solutions, or alternative
identifier formats. However, the WG will consider developing methods
for the shim6 level to handle transport layer signalling to the shim6
layer as in scope.

[What other topics are explicitly in/out of scope?]

Milestones

MAY 05    First draft of architectural document
MAY 05 	  First draft of protocol document
MAY 05    First draft on cryptographic locators, if required
MAY 05    First draft on multihoimg triggers description
MAY 05 	  First draft on applicability statement document

SEP 05    WG last-call on architectural document
SEP 05	  WG last-call on applicability statement document

NOV 05 	  WG last-call on protocol document
NOV 05    WG last-call on cryptographic locators, if required
NOV 05    Submit completed architectural document to IESG
NOV 05	  Submit applicability statement document to IESG

JAN 06    WG last-call on multihoming triggers description
JAN 06    Submit document on cryptographic locators to the IESG, if
     	  required
JAN 06	  Submit protocol document to the IESG

MAR 06    Submit draft on multihoming triggers description to the IESG

Delivery-date: Tue, 25 Jan 2005 14:33:52 +0000
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Tue, 25 Jan 2005 15:35:10 +0100
To: <[email-masked]>

On 2005-01-24, at 12.05, <[email-masked]> wrote:

> Brian,
>
>> Also, don't forget that our job right now is to agree on a
>> precise charter for shim6, and that will include ruling some
>> items out of scope, even if they are needed for the IPv6 Internet
>> as a whole. Let's focus on having a finite menu of precise objectives
>> that can be turned into standards track RFCs...
>
> I agree - I think I sent some suggestions in on what I thought would
> be reasonable charter items; I could try to reformulate them based upon
> the discussion, unless Kurtis is already reving the charter.

I am, and I included your comments. I just wanted to wait a bit and see 
where the discussion lead. Not sure I got much out of it though :-) I 
will post what I got so far later tonight, and what I think was the 
agreement. Then you can all correct me :-)

- - kurtis -

Delivery-date: Mon, 24 Jan 2005 17:21:24 +0000
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Mon, 24 Jan 2005 18:20:41 +0100
To: <[email-masked]>

El 24/01/2005, a las 7:11, <[email-masked]> escribió:

> Marcelo,
>
>> I think that we have a terminology issue here, and i guess that we can
>> benefit from the distinction made by Jari.
>> One thing is the shim protocol, that as you mentioned is only needed 
>> to
>> preserve the established communications and another thing is the 
>> output
>> of the shim wg, which can be broader than just the protocol for
>> preserving establishing communications. What i am arguing for is that
>> the shim wg should also provide the mechanisms to establish new
>> communications after an outage in the case that only one of the hosts
>> is upgraded and the other one is just an legacy ipv6 node (i.e. at
>> least point 3 below)
>
> I agree; I think there may be some debate about how generic the
> mechanism for re-establishing communication should be.  In my opinion,
> such a model is needed for the shim6 protocol to work properly; 
> however,
> I think we should work on a mechanism that is more optimized for use
> with shim6 than a completely generic mechanism, or at least that is
> what our target should be.  If we do develope a mechanism that works
> with or without shim6, than that is a good thing, but I don't think
> we should have a requirement that this mechanism should work without
> shim6.
>

my concern is about deployment
The deployment model for the shim protocol requires de support from 
both ends of the communication
i am worried about some signs that are starting to appear, like the 
policy proposal for PI assignment for multihomed sites in the ARIN 
region. I read this as a sign that the community is requiring a 
multihoming solution asap.
So my point is that we need to provide some tools that provide 
immediate benefits to the multihomed sites.
A mechanism for establishing new communication after outages, that does 
not impose support from the other party of the communication, would 
provide immediate benefit to the multihomed site.
Only providing a shim protocol that requires support from both ends, is 
a great tool, but its deployment time seems way too long compared to 
the aforementioned initiatives.

But, i guess that i have already made my point clear too many times by 
now.
Sorry for repeating myself, but i think this is an important point.

Regards, marcelo

>> Otoh, even the shim layer will need to establish new communications
>> after an outage, so this mechanism is also needed for the shim to work
>> properly (however, we could envision different mechanisms in the case
>> that both ends support the shim and in the case when one legacy host 
>> is
>> involved). also, the ingress filtering compatibility mechanisms are
>> needed for the shim to work.
>
> I agree with this.
>
> John
>
>> Regards, marcelo
>>
>> El 21/01/2005, a las 23:24, Christian Huitema escribió:
>>
>>>> I agree that a single host that has SHIM components cannot preserve
>>>> established communications (since for this support from
>> both ends of
>>>> the communication is needed).
>>>> However, if one of the nodes has SHIM components, it may be able to
>>>> establish new communications after an outage, something that a non
>>> SHIM
>>>> host cannot. and this is a great benefit imho
>>>
>>> When I look at the components of multi-homing support, I find the
>>> following:
>>>
>>> 1) Support of multiple IPv6 interfaces & corresponding IPv6
>> addresses
>>> 	This is standard in most IPv6 stacks.
>>> 	By itself, it allows servers to accept connections over multiple
>>> nets.
>>> 	Programming interface is well known (bind to "any", then
>>> listen).
>>> 	Can break if egress filtering interferes, but only in some weird
>>> cases.
>>>
>>> 2) Choice of the appropriate address pair when many are available
>>> 	There is a standard spec for "source and dest address
>>> selection".
>>> 	It should allow clients to establish connections.
>>> 	However, it relies on "static analysis" of the prefixes, and
>>> does
>>> 	not work well if one of the paths is unreliable.
>>> 	Can break if egress-filtering interferes.
>>>
>>> 3) Better algorithm for address pair selection
>>> 	Essentially, try multiple choices instead of just one.
>>> 	Present in some stacks and some applications.
>>> 	We could do better.
>>> 	Does not necessarily require Shim6.
>>> 	Only a partial solution to egress-filtering.
>>>
>>> 4) Egress-filtering solution
>>> 	Resolve interaction between "destination based routing" and
>>> 	egress filtering.
>>> 	Different solutions for different types of networks.
>>>
>>> 5) Detection of rehoming events
>>> 	Quickly detect that connectivity has changed,
>>> 	Could use information from multiple layers
>>> 	Adequate response can be performed at many layers
>>>
>>> 6) Connection maintenance after rehoming & other event
>>> 	The solution that shim6 addresses...
>>>
>>> -- Christian Huitema 
>>>
>>
>>
>

Delivery-date: Mon, 24 Jan 2005 12:03:40 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Mon, 24 Jan 2005 13:05:05 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Brian,

> Also, don't forget that our job right now is to agree on a
> precise charter for shim6, and that will include ruling some
> items out of scope, even if they are needed for the IPv6 Internet
> as a whole. Let's focus on having a finite menu of precise objectives
> that can be turned into standards track RFCs...

I agree - I think I sent some suggestions in on what I thought would
be reasonable charter items; I could try to reformulate them based upon
the discussion, unless Kurtis is already reving the charter.

John

Delivery-date: Mon, 24 Jan 2005 10:30:18 +0000
Date: Mon, 24 Jan 2005 11:29:53 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

Also, don't forget that our job right now is to agree on a
precise charter for shim6, and that will include ruling some
items out of scope, even if they are needed for the IPv6 Internet
as a whole. Let's focus on having a finite menu of precise objectives
that can be turned into standards track RFCs...

      Brian

[email-masked] wrote:
> Marcelo,
> 
> 
>>I think that we have a terminology issue here, and i guess that we can 
>>benefit from the distinction made by Jari.
>>One thing is the shim protocol, that as you mentioned is only needed to 
>>preserve the established communications and another thing is the output 
>>of the shim wg, which can be broader than just the protocol for 
>>preserving establishing communications. What i am arguing for is that 
>>the shim wg should also provide the mechanisms to establish new 
>>communications after an outage in the case that only one of the hosts 
>>is upgraded and the other one is just an legacy ipv6 node (i.e. at 
>>least point 3 below)
> 
> 
> I agree; I think there may be some debate about how generic the
> mechanism for re-establishing communication should be.  In my opinion,
> such a model is needed for the shim6 protocol to work properly; however,
> I think we should work on a mechanism that is more optimized for use
> with shim6 than a completely generic mechanism, or at least that is
> what our target should be.  If we do develope a mechanism that works
> with or without shim6, than that is a good thing, but I don't think
> we should have a requirement that this mechanism should work without
> shim6.
> 
> 
>>Otoh, even the shim layer will need to establish new communications 
>>after an outage, so this mechanism is also needed for the shim to work 
>>properly (however, we could envision different mechanisms in the case 
>>that both ends support the shim and in the case when one legacy host is 
>>involved). also, the ingress filtering compatibility mechanisms are 
>>needed for the shim to work.
> 
> 
> I agree with this.
> 
> John
>  
> 
>>Regards, marcelo
>>
>>El 21/01/2005, a las 23:24, Christian Huitema escribió:
>>
>>
>>>>I agree that a single host that has SHIM components cannot preserve
>>>>established communications (since for this support from 
>>
>>both ends of
>>
>>>>the communication is needed).
>>>>However, if one of the nodes has SHIM components, it may be able to
>>>>establish new communications after an outage, something that a non
>>>
>>>SHIM
>>>
>>>>host cannot. and this is a great benefit imho
>>>
>>>When I look at the components of multi-homing support, I find the
>>>following:
>>>
>>>1) Support of multiple IPv6 interfaces & corresponding IPv6 
>>
>>addresses
>>
>>>	This is standard in most IPv6 stacks.
>>>	By itself, it allows servers to accept connections over multiple
>>>nets.
>>>	Programming interface is well known (bind to "any", then
>>>listen).
>>>	Can break if egress filtering interferes, but only in some weird
>>>cases.
>>>
>>>2) Choice of the appropriate address pair when many are available
>>>	There is a standard spec for "source and dest address
>>>selection".
>>>	It should allow clients to establish connections.
>>>	However, it relies on "static analysis" of the prefixes, and
>>>does
>>>	not work well if one of the paths is unreliable.
>>>	Can break if egress-filtering interferes.
>>>
>>>3) Better algorithm for address pair selection
>>>	Essentially, try multiple choices instead of just one.
>>>	Present in some stacks and some applications.
>>>	We could do better.
>>>	Does not necessarily require Shim6.
>>>	Only a partial solution to egress-filtering.
>>>
>>>4) Egress-filtering solution
>>>	Resolve interaction between "destination based routing" and
>>>	egress filtering.
>>>	Different solutions for different types of networks.
>>>
>>>5) Detection of rehoming events
>>>	Quickly detect that connectivity has changed,
>>>	Could use information from multiple layers
>>>	Adequate response can be performed at many layers
>>>
>>>6) Connection maintenance after rehoming & other event
>>>	The solution that shim6 addresses...
>>>
>>>-- Christian Huitema 
>>>
>>
>>
> 

Delivery-date: Mon, 24 Jan 2005 06:20:40 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Mon, 24 Jan 2005 08:11:56 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Marcelo,

> I think that we have a terminology issue here, and i guess that we can 
> benefit from the distinction made by Jari.
> One thing is the shim protocol, that as you mentioned is only needed to 
> preserve the established communications and another thing is the output 
> of the shim wg, which can be broader than just the protocol for 
> preserving establishing communications. What i am arguing for is that 
> the shim wg should also provide the mechanisms to establish new 
> communications after an outage in the case that only one of the hosts 
> is upgraded and the other one is just an legacy ipv6 node (i.e. at 
> least point 3 below)

I agree; I think there may be some debate about how generic the
mechanism for re-establishing communication should be.  In my opinion,
such a model is needed for the shim6 protocol to work properly; however,
I think we should work on a mechanism that is more optimized for use
with shim6 than a completely generic mechanism, or at least that is
what our target should be.  If we do develope a mechanism that works
with or without shim6, than that is a good thing, but I don't think
we should have a requirement that this mechanism should work without
shim6.

> Otoh, even the shim layer will need to establish new communications 
> after an outage, so this mechanism is also needed for the shim to work 
> properly (however, we could envision different mechanisms in the case 
> that both ends support the shim and in the case when one legacy host is 
> involved). also, the ingress filtering compatibility mechanisms are 
> needed for the shim to work.

I agree with this.

John
 
> Regards, marcelo
> 
> El 21/01/2005, a las 23:24, Christian Huitema escribió:
> 
> >> I agree that a single host that has SHIM components cannot preserve
> >> established communications (since for this support from 
> both ends of
> >> the communication is needed).
> >> However, if one of the nodes has SHIM components, it may be able to
> >> establish new communications after an outage, something that a non
> > SHIM
> >> host cannot. and this is a great benefit imho
> >
> > When I look at the components of multi-homing support, I find the
> > following:
> >
> > 1) Support of multiple IPv6 interfaces & corresponding IPv6 
> addresses
> > 	This is standard in most IPv6 stacks.
> > 	By itself, it allows servers to accept connections over multiple
> > nets.
> > 	Programming interface is well known (bind to "any", then
> > listen).
> > 	Can break if egress filtering interferes, but only in some weird
> > cases.
> >
> > 2) Choice of the appropriate address pair when many are available
> > 	There is a standard spec for "source and dest address
> > selection".
> > 	It should allow clients to establish connections.
> > 	However, it relies on "static analysis" of the prefixes, and
> > does
> > 	not work well if one of the paths is unreliable.
> > 	Can break if egress-filtering interferes.
> >
> > 3) Better algorithm for address pair selection
> > 	Essentially, try multiple choices instead of just one.
> > 	Present in some stacks and some applications.
> > 	We could do better.
> > 	Does not necessarily require Shim6.
> > 	Only a partial solution to egress-filtering.
> >
> > 4) Egress-filtering solution
> > 	Resolve interaction between "destination based routing" and
> > 	egress filtering.
> > 	Different solutions for different types of networks.
> >
> > 5) Detection of rehoming events
> > 	Quickly detect that connectivity has changed,
> > 	Could use information from multiple layers
> > 	Adequate response can be performed at many layers
> >
> > 6) Connection maintenance after rehoming & other event
> > 	The solution that shim6 addresses...
> >
> > -- Christian Huitema 
> >
> 
> 

Delivery-date: Mon, 24 Jan 2005 04:44:00 +0000
Date: Mon, 24 Jan 2005 06:44:30 +0200 (EET)
From: John Loughney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

------=_Part_131_10317890.1106541870319
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thierry,

In multi6, we were discussing site multihoming, so most of the
discussions assumed, but did not require, single interface at a time. 
For the current discussion, I'm not sure how multiple interfaces being
active in the same time would affect anything.  In fact, I think that a
shim6 solution should work in either case.

I think some of us have deployment models where multiple interfaces may
be active at the same time; however I think the failure detection /
rehoming selection should be applied to single interface at time,
otherwise the detection algoritms will be fart too complicated.

John

--- Original Message ---
From: ext Thierry Ernst <[email-masked]>
To: [email-masked]
Date: Mon Jan 24  04:02:30 EET 2005
Subject: Re: multi6-functional-dec and re-homing

> When I look at the components of multi-homing support, I find the
> following:
> 
> 1) Support of multiple IPv6 interfaces & corresponding IPv6 addresses
> 	This is standard in most IPv6 stacks.
> 	By itself, it allows servers to accept connections over multiple
> nets.
> 	Programming interface is well known (bind to "any", then
> listen).
> 	Can break if egress filtering interferes, but only in some weird
> cases.

Speaking about multiple IPv6 interefaces, do we mean "multiple
interfaces active (i.e usable) simultaneously", or "one at a time" ?

Sorry if this is obvious for people participating to this discussion.

Thierry.

       
------=_Part_131_10317890.1106541870319--

Delivery-date: Mon, 24 Jan 2005 01:59:03 +0000
Date: Mon, 24 Jan 2005 11:02:30 +0900
From: Thierry Ernst <[email-masked]>
To: [email-masked]
Subject: Re: multi6-functional-dec and re-homing
Organization: Keio University

> When I look at the components of multi-homing support, I find the
> following:
> 
> 1) Support of multiple IPv6 interfaces & corresponding IPv6 addresses
> 	This is standard in most IPv6 stacks.
> 	By itself, it allows servers to accept connections over multiple
> nets.
> 	Programming interface is well known (bind to "any", then
> listen).
> 	Can break if egress filtering interferes, but only in some weird
> cases.

Speaking about multiple IPv6 interefaces, do we mean "multiple
interfaces active (i.e usable) simultaneously", or "one at a time" ?

Sorry if this is obvious for people participating to this discussion.

Thierry.

Delivery-date: Sat, 22 Jan 2005 11:03:05 +0000
Cc: "Brian E Carpenter" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Sat, 22 Jan 2005 11:41:11 +0100
To: "Christian Huitema" <[email-masked]>

Hi Christian,

I think that we have a terminology issue here, and i guess that we can 
benefit from the distinction made by Jari.
One thing is the shim protocol, that as you mentioned is only needed to 
preserve the established communications and another thing is the output 
of the shim wg, which can be broader than just the protocol for 
preserving establishing communications. What i am arguing for is that 
the shim wg should also provide the mechanisms to establish new 
communications after an outage in the case that only one of the hosts 
is upgraded and the other one is just an legacy ipv6 node (i.e. at 
least point 3 below)

Otoh, even the shim layer will need to establish new communications 
after an outage, so this mechanism is also needed for the shim to work 
properly (however, we could envision different mechanisms in the case 
that both ends support the shim and in the case when one legacy host is 
involved). also, the ingress filtering compatibility mechanisms are 
needed for the shim to work.

Regards, marcelo

El 21/01/2005, a las 23:24, Christian Huitema escribió:

>> I agree that a single host that has SHIM components cannot preserve
>> established communications (since for this support from both ends of
>> the communication is needed).
>> However, if one of the nodes has SHIM components, it may be able to
>> establish new communications after an outage, something that a non
> SHIM
>> host cannot. and this is a great benefit imho
>
> When I look at the components of multi-homing support, I find the
> following:
>
> 1) Support of multiple IPv6 interfaces & corresponding IPv6 addresses
> 	This is standard in most IPv6 stacks.
> 	By itself, it allows servers to accept connections over multiple
> nets.
> 	Programming interface is well known (bind to "any", then
> listen).
> 	Can break if egress filtering interferes, but only in some weird
> cases.
>
> 2) Choice of the appropriate address pair when many are available
> 	There is a standard spec for "source and dest address
> selection".
> 	It should allow clients to establish connections.
> 	However, it relies on "static analysis" of the prefixes, and
> does
> 	not work well if one of the paths is unreliable.
> 	Can break if egress-filtering interferes.
>
> 3) Better algorithm for address pair selection
> 	Essentially, try multiple choices instead of just one.
> 	Present in some stacks and some applications.
> 	We could do better.
> 	Does not necessarily require Shim6.
> 	Only a partial solution to egress-filtering.
>
> 4) Egress-filtering solution
> 	Resolve interaction between "destination based routing" and
> 	egress filtering.
> 	Different solutions for different types of networks.
>
> 5) Detection of rehoming events
> 	Quickly detect that connectivity has changed,
> 	Could use information from multiple layers
> 	Adequate response can be performed at many layers
>
> 6) Connection maintenance after rehoming & other event
> 	The solution that shim6 addresses...
>
> -- Christian Huitema 
>

Delivery-date: Fri, 21 Jan 2005 22:25:00 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Fri, 21 Jan 2005 14:24:46 -0800
From: "Christian Huitema" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>, "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

> I agree that a single host that has SHIM components cannot preserve
> established communications (since for this support from both ends of
> the communication is needed).
> However, if one of the nodes has SHIM components, it may be able to
> establish new communications after an outage, something that a non
SHIM
> host cannot. and this is a great benefit imho

When I look at the components of multi-homing support, I find the
following:

1) Support of multiple IPv6 interfaces & corresponding IPv6 addresses
	This is standard in most IPv6 stacks.
	By itself, it allows servers to accept connections over multiple
nets.
	Programming interface is well known (bind to "any", then
listen).
	Can break if egress filtering interferes, but only in some weird
cases.

2) Choice of the appropriate address pair when many are available
	There is a standard spec for "source and dest address
selection".
	It should allow clients to establish connections.
	However, it relies on "static analysis" of the prefixes, and
does
	not work well if one of the paths is unreliable.
	Can break if egress-filtering interferes.

3) Better algorithm for address pair selection
	Essentially, try multiple choices instead of just one.
	Present in some stacks and some applications.
	We could do better.
	Does not necessarily require Shim6.
	Only a partial solution to egress-filtering.

4) Egress-filtering solution
	Resolve interaction between "destination based routing" and
	egress filtering. 
	Different solutions for different types of networks.

5) Detection of rehoming events
	Quickly detect that connectivity has changed,
	Could use information from multiple layers
	Adequate response can be performed at many layers

6) Connection maintenance after rehoming & other event
	The solution that shim6 addresses...

-- Christian Huitema 

Delivery-date: Thu, 20 Jan 2005 17:05:53 +0000
Date: Thu, 20 Jan 2005 09:05:11 -0800
From: Erik Nordmark <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

Brian E Carpenter wrote:

> Well, I find it hard to see how a single-ended shim can help, unless
> it actually turns out to be an in-host NAT, and I don't think we want
> to go there, do we?

I'm not sure that this is the only possible result.

Even in the two-shim case, we need a function which will trying 
different ULIDs pair if there is a failure during initial contact.
One way to do this is to place that module above the transport 
protocols. If we have such a module, it could be used in the 
single-ended shim case as well.

    Erik

Delivery-date: Thu, 20 Jan 2005 16:12:47 +0000
Cc: [email-masked], [email-masked], [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Thu, 20 Jan 2005 17:12:56 +0100
To: Brian E Carpenter <[email-masked]>

El 20/01/2005, a las 10:16, Brian E Carpenter escribió:

> [email-masked] wrote:
>> Brian,
>>> Focussing:
>>>
>>>
>>>> In particular, the benefits would be the capability of establishing
>>>> new communications through the alternative paths.
>>>
>>> Well, that is an intrinsic property of IPv6 surely - if a host has
>>> two addresses, and one fails, you can try the other.
>> Yes, but the TCP session running will be torn down.  This implies the
>> need for a shim layer, but I'm guessing Marcelo was suggesting that
>> there may still mechanisms help with this case.  Am I correct in
>> assuming that you think this is out of scope?
>
> Well, I find it hard to see how a single-ended shim can help, unless
> it actually turns out to be an in-host NAT, and I don't think we want
> to go there, do we?
>

I agree that a single host that has SHIM components cannot preserve 
established communications (since for this support from both ends of 
the communication is needed).
However, if one of the nodes has SHIM components, it may be able to 
establish new communications after an outage, something that a non SHIM 
host cannot. and this is a great benefit imho

Reagrds, marcelo

>    Brian
>
>

Delivery-date: Thu, 20 Jan 2005 15:59:35 +0000
Cc: [email-masked], [email-masked], Brian E Carpenter <[email-masked]>, [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Thu, 20 Jan 2005 16:59:38 +0100
To: [email-masked]

El 20/01/2005, a las 12:32, Jari Arkko escribió:

> marcelo bagnulo braun wrote:
>
>> I mean, this means that the resulting solution will only provide any 
>> kind of benefits when the two hosts involved in the communications 
>> implement the shim.
>> this would be ok if there were not possible to do better, but this is 
>> not the case.
>> We can design a solution that provide some of the fault tolerance 
>> capabilities when just one of the endpoints support the solution. In 
>> particular, the benefits would be the capability of establishing new 
>> communications through the alternative paths.
>
> Yes, but I think its the "source address selection" module
> rather than the shim6 protocol proper that helps here. Both
> are components of the "SHIM6 system", but nevertheless...
>
>> this would provide some fault tolerance benefits to the multihomed 
>> site independently of whether the external hosts support the shim or 
>> not.
>> imho this would render the multihoming solution much more attractive
>> so i would argue that we should explicitly include an item in the 
>> charter to do this
>
> Right. Do you want a separate document, or just that the
> specific case is described in the shim6 documents?
>

well i would like a separate document at least for the case when one of 
the nodes is not shim capable.

I mean, if one of the nodes is a legacy node, then the options are more 
limited, since we cannot expect any additional functionality from it. 
In this case, the only option is to retry the establish a new 
communication with a different address (i.e. different identifier and 
different locator)

In the case when the two nodes are shim capable, then we could expect 
the shim protocol to be of use here, and for instance we could try to 
use a different locator but preserving the identifier, This approach 
probably will make life of the apps easier.

So i guess that it may make sense to use different approaches for 
establishing new communications when the initial address has failed 
depending on whether the two hosts are shim capable or not.

So, i would suggest to have al least one separate document for the case 
where one of the nodes is not shim capable, if needed the other case, 
where the two nodes are shim capable can be covered in the shim 
protocol document.

Thanks, marcelo

> --Jari
>

Delivery-date: Thu, 20 Jan 2005 12:05:20 +0000
Date: Thu, 20 Jan 2005 14:04:20 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

[email-masked] wrote:

>>So, the question we have now is whether the SHIM6 WG's RFCs
>>should specifically deal with the source address selection
>>problem when the other end is plain old IPv6 node. Or not.
> 
> I might be confused here, but I think Brian was suggesting that
> to use shim6, both ends need to have shim6, otherwise both ends
> use 'normal' mechansims.  Do you see a case where one end would use
> shim6 and the other would not?

We need to separate the technical and the administrative
parts of the question. I _think_ we agree on what can be
done technically; the SHIM6 WG solution consists of a number
of 'pieces', and we could certainly improve the source
address selection rules without requiring the shim6 protocol
from either end. The question here is whether to bother
about it or not.

The administrative parts are (a) whether such rules
are within the shim6 protocol document or in a separate
RFC, and (b) whether such work would be within SHIM6 WG's
scope or a part of "normal" IPv6. I think Marcelo argued
well that the technical solution as such is necessary for
the SHIM6 solution to work, so unless we are going to rely
on some other WG to provide us some basic building blocks,
we're going to have to do it ourselves. So I think its
in scope. But maybe the remaining question is whether
we bother to document the case where the stuff is
used when shim6 protocol is not present.

--Jari

Delivery-date: Thu, 20 Jan 2005 11:58:53 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Thu, 20 Jan 2005 13:52:24 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Jari,
> 
> >  >  In particular, the benefits would be the capability of establishing
> >  >  new communications through the alternative paths.
> > 
> > Well, that is an intrinsic property of IPv6 surely - if a host has
> > two addresses, and one fails, you can try the other. But since we
> > can only get ULID to locator translation with a shim at both ends,
> > I just don't see what is brought to this property by the shim;
> > both ends will have to use the new locators at the ULP interface,
> > so the shim has no work to do.
> 
> I guess Marcelo is talking about the logic to try another source
> address. The actual shim6 protocol would not be of use here.

I agree that this is something that would be good to do; however, my
question is - is this a shim6 specific task?
 
> So, the question we have now is whether the SHIM6 WG's RFCs
> should specifically deal with the source address selection
> problem when the other end is plain old IPv6 node. Or not.

I might be confused here, but I think Brian was suggesting that
to use shim6, both ends need to have shim6, otherwise both ends
use 'normal' mechansims.  Do you see a case where one end would use
shim6 and the other would not?

John

Delivery-date: Thu, 20 Jan 2005 11:44:53 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Thu, 20 Jan 2005 13:36:44 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Brian,

> > Yes, but the TCP session running will be torn down.  This implies the
> > need for a shim layer, but I'm guessing Marcelo was suggesting that
> > there may still mechanisms help with this case.  Am I correct in
> > assuming that you think this is out of scope?
> 
> Well, I find it hard to see how a single-ended shim can help, unless
> it actually turns out to be an in-host NAT, and I don't think we want
> to go there, do we?

Probably not.

John

Delivery-date: Thu, 20 Jan 2005 11:35:26 +0000
Date: Thu, 20 Jan 2005 13:34:29 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Brian E Carpenter <[email-masked]>
Cc: marcelo bagnulo braun <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

Brian E Carpenter wrote:
> Focussing:
> 
>  >  In particular, the benefits would be the capability of establishing
>  >  new communications through the alternative paths.
> 
> Well, that is an intrinsic property of IPv6 surely - if a host has
> two addresses, and one fails, you can try the other. But since we
> can only get ULID to locator translation with a shim at both ends,
> I just don't see what is brought to this property by the shim;
> both ends will have to use the new locators at the ULP interface,
> so the shim has no work to do.

I guess Marcelo is talking about the logic to try another source
address. The actual shim6 protocol would not be of use here.

So, the question we have now is whether the SHIM6 WG's RFCs
should specifically deal with the source address selection
problem when the other end is plain old IPv6 node. Or not.

--Jari

Delivery-date: Thu, 20 Jan 2005 11:33:54 +0000
Date: Thu, 20 Jan 2005 13:32:57 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: marcelo bagnulo braun <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

marcelo bagnulo braun wrote:

> I mean, this means that the resulting solution will only provide any 
> kind of benefits when the two hosts involved in the communications 
> implement the shim.
> this would be ok if there were not possible to do better, but this is 
> not the case.
> We can design a solution that provide some of the fault tolerance 
> capabilities when just one of the endpoints support the solution. In 
> particular, the benefits would be the capability of establishing new 
> communications through the alternative paths.

Yes, but I think its the "source address selection" module
rather than the shim6 protocol proper that helps here. Both
are components of the "SHIM6 system", but nevertheless...

> this would provide some fault tolerance benefits to the multihomed site 
> independently of whether the external hosts support the shim or not.
> 
> imho this would render the multihoming solution much more attractive
> 
> so i would argue that we should explicitly include an item in the 
> charter to do this

Right. Do you want a separate document, or just that the
specific case is described in the shim6 documents?

--Jari

Delivery-date: Thu, 20 Jan 2005 11:33:31 +0000
Date: Thu, 20 Jan 2005 13:32:35 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

Brian E Carpenter wrote:
> John, I don't understand.
> 
> If neither end is shim6-capable, it is resoundingly out
> of scope.
> 
> If only one end is shim6-capable, we can't run shim6, so
> we have to revert to mono-homing.

I guess Marcelo's point is that there a number
of different "modules" that we need for the
SHIM6 to work. One of those modules is relatively
simple, and deploying just it without anything
else would also bring benefits.

--Jari

Delivery-date: Thu, 20 Jan 2005 11:33:22 +0000
Date: Thu, 20 Jan 2005 13:32:21 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: marcelo bagnulo braun <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

marcelo bagnulo braun wrote:

> So, i guess that my point is that when a non shim node is involved in a 
> communication, it would be good if we did more that just  detecting that 
> the shim is not supported, but we could deploy mechanisms to provide 
> enhanced fault tolerance in this scenario.
> 
> (It could also be noted that such mechanism is likely to be much simpler 
> than the whole shim and that it will, by itself, provide some degree of 
> fault tolerance, so it may make sense to deploy it even without the shim)
> 
> Makes sense?

It makes sense to me.

--Jari

Delivery-date: Thu, 20 Jan 2005 09:16:26 +0000
Date: Thu, 20 Jan 2005 10:16:11 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

[email-masked] wrote:
> Brian,
> 
> 
>>Focussing:
>>
>>
>>> In particular, the benefits would be the capability of establishing
>>> new communications through the alternative paths.
>>
>>Well, that is an intrinsic property of IPv6 surely - if a host has
>>two addresses, and one fails, you can try the other.
> 
> 
> Yes, but the TCP session running will be torn down.  This implies the
> need for a shim layer, but I'm guessing Marcelo was suggesting that
> there may still mechanisms help with this case.  Am I correct in
> assuming that you think this is out of scope?

Well, I find it hard to see how a single-ended shim can help, unless
it actually turns out to be an in-host NAT, and I don't think we want
to go there, do we?

    Brian

Delivery-date: Thu, 20 Jan 2005 08:13:19 +0000
Cc: [email-masked], "Joel M. Halpern" <[email-masked]>
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: State machine / failure detection / rehoming support
Date: Wed, 19 Jan 2005 12:46:05 +0100
To: Brian E Carpenter <[email-masked]>

On 2005-01-18, at 18.00, Brian E Carpenter wrote:

> Joel M. Halpern wrote:
>
> (much good sense deleted)
>
>> At the same time, I have real trouble separating the finite state
> > machine of the protocol (as opposed to the states seen by the shim6
> > user) from the definition of the protocol.
>
> Yes, I certainly don't mean it's easy to do. And maybe what needs
> to be separate is that external view of the states, rather than
> the fully specified FSM, which I agree is tightly bound to the
> protocol.

 From what I am reading most people seem to agree with the above (or 
variations of it) and that we try and split that into a separate 
document. I will try and get that into the charter then. If I have 
misunderstood the views, please let me know...

- - kurtis -

Delivery-date: Thu, 20 Jan 2005 04:28:40 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Thu, 20 Jan 2005 06:21:18 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Brian,

> Focussing:
>
> >  In particular, the benefits would be the capability of establishing
> >  new communications through the alternative paths.
>
> Well, that is an intrinsic property of IPv6 surely - if a host has
> two addresses, and one fails, you can try the other.

Yes, but the TCP session running will be torn down.  This implies the
need for a shim layer, but I'm guessing Marcelo was suggesting that
there may still mechanisms help with this case.  Am I correct in
assuming that you think this is out of scope?

John

Delivery-date: Wed, 19 Jan 2005 16:17:16 +0000
Cc: [email-masked], [email-masked], [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Wed, 19 Jan 2005 17:17:24 +0100
To: Brian E Carpenter <[email-masked]>

El 19/01/2005, a las 17:14, Brian E Carpenter escribió:

> Marcelo,
>
> You're correct of course that source address selection is a blank.
> There was some discussion around this point years ago, but it
> went nowhere. I agree that one of the *support* modules
> for shim6 will have to solve the source address selection problem,
> but that is clearly separable in my mind from the shim itself
> and the shim's state machine.

agree.
i see it as a separate module of the solution that needs to retry with 
different source address
(but imho we need it as part of the solution)

regards, marcelo

>
> Well, Kurtis foolishly said he'd draft the next version of
> the charter. I'm curious to see what he thinks the consensus
> is...
>
>    Brian
>
> marcelo bagnulo braun wrote:
>> El 19/01/2005, a las 15:53, Brian E Carpenter escribió:
>>> Focussing:
>>>
>>> >  In particular, the benefits would be the capability of 
>>> establishing
>>> >  new communications through the alternative paths.
>>>
>>> Well, that is an intrinsic property of IPv6 surely - if a host has
>>> two addresses, and one fails, you can try the other.
>> Yes, but in this particular case, the multihomed host will have to 
>> retry with an alternative _source_ address.
>> RFC3484 states that hosts should retry with alternative destiantion 
>> address if they are available for the destiantion, but it is silent 
>> w.r.t. source address retrial.
>> In the case that a multihomed host with multiple address need to 
>> establish a new communication after an outage, it is likely that it 
>> will have to retry using a different source address. currently this 
>> is not specified anywhere.
>>> But since we
>>> can only get ULID to locator translation with a shim at both ends,
>>> I just don't see what is brought to this property by the shim;
>>> both ends will have to use the new locators at the ULP interface,
>>> so the shim has no work to do.
>> W.r.t what is the relation between this point and the shim wg i would 
>> say that:
>> - as i understand, the shim wg is about developing a multihoming 
>> solution. a key part of the solution is the shim layer to preserve 
>> establsihed communications through outages. however, there some other 
>> parts of a multihoming solutions that are important as well, and i 
>> think they need to be developed as part of the work of the shim wg. 
>> One of such pieces is the mechanisms to provide compatibility with 
>> ingress filtering. These are clearly not part of the shim layer but 
>> they are clearly needed to make a multihoming solution work. the 
>> capability of establishing new communications with non shim capable 
>> hosts can be seen imho as another one of such features. (the other 
>> one is the TE capability that was pointed out by Pekka S. that imho 
>> need some rewriting in the draft)
>> - otoh, even in communications between 2 shim capable nodes, the 
>> capability of establishing new communications after an outage is 
>> required. the point here is that, if both ends support the shim, then 
>> the used mechanisms can be different. However, the mechanisms for the 
>> case when one of the nodes in non shim capable could still be used in 
>> the case when the two nodes are shim capable. The tradeoff here is 
>> w.r.t. the additional benefits that can be achieved when both 
>> endpoints support the shim. But in any case, a mechanism for 
>> establsihing new communications after an outage is also needed for 
>> the shim. this mechanism can be designed in a way that it works with 
>> non shim capable hosts or not. My point is that in any case we need a 
>> mechanism to deal with non shim capable hosts. then we can explore if 
>> we will use the same one when the two nodes support the shim or if it 
>> worthy to design a new mechanism for this case.
>> Regards, marcelo
>>>
>>>    Brian
>>>
>

Delivery-date: Wed, 19 Jan 2005 16:14:17 +0000
Date: Wed, 19 Jan 2005 17:14:03 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

Marcelo,

You're correct of course that source address selection is a blank.
There was some discussion around this point years ago, but it
went nowhere. I agree that one of the *support* modules
for shim6 will have to solve the source address selection problem,
but that is clearly separable in my mind from the shim itself
and the shim's state machine.

Well, Kurtis foolishly said he'd draft the next version of
the charter. I'm curious to see what he thinks the consensus
is...

    Brian

marcelo bagnulo braun wrote:
> 
> El 19/01/2005, a las 15:53, Brian E Carpenter escribió:
> 
>> Focussing:
>>
>> >  In particular, the benefits would be the capability of establishing
>> >  new communications through the alternative paths.
>>
>> Well, that is an intrinsic property of IPv6 surely - if a host has
>> two addresses, and one fails, you can try the other.
> 
> 
> Yes, but in this particular case, the multihomed host will have to retry 
> with an alternative _source_ address.
> RFC3484 states that hosts should retry with alternative destiantion 
> address if they are available for the destiantion, but it is silent 
> w.r.t. source address retrial.
> 
> In the case that a multihomed host with multiple address need to 
> establish a new communication after an outage, it is likely that it will 
> have to retry using a different source address. currently this is not 
> specified anywhere.
> 
> 
>> But since we
>> can only get ULID to locator translation with a shim at both ends,
>> I just don't see what is brought to this property by the shim;
>> both ends will have to use the new locators at the ULP interface,
>> so the shim has no work to do.
> 
> 
> 
> W.r.t what is the relation between this point and the shim wg i would 
> say that:
> 
> - as i understand, the shim wg is about developing a multihoming 
> solution. a key part of the solution is the shim layer to preserve 
> establsihed communications through outages. however, there some other 
> parts of a multihoming solutions that are important as well, and i think 
> they need to be developed as part of the work of the shim wg. One of 
> such pieces is the mechanisms to provide compatibility with ingress 
> filtering. These are clearly not part of the shim layer but they are 
> clearly needed to make a multihoming solution work. the capability of 
> establishing new communications with non shim capable hosts can be seen 
> imho as another one of such features. (the other one is the TE 
> capability that was pointed out by Pekka S. that imho need some 
> rewriting in the draft)
> 
> - otoh, even in communications between 2 shim capable nodes, the 
> capability of establishing new communications after an outage is 
> required. the point here is that, if both ends support the shim, then 
> the used mechanisms can be different. However, the mechanisms for the 
> case when one of the nodes in non shim capable could still be used in 
> the case when the two nodes are shim capable. The tradeoff here is 
> w.r.t. the additional benefits that can be achieved when both endpoints 
> support the shim. But in any case, a mechanism for establsihing new 
> communications after an outage is also needed for the shim. this 
> mechanism can be designed in a way that it works with non shim capable 
> hosts or not. My point is that in any case we need a mechanism to deal 
> with non shim capable hosts. then we can explore if we will use the same 
> one when the two nodes support the shim or if it worthy to design a new 
> mechanism for this case.
> 
> Regards, marcelo
> 
>>
>>    Brian
>>
> 
> 
> 

Delivery-date: Wed, 19 Jan 2005 15:09:48 +0000
Cc: [email-masked], [email-masked], [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Wed, 19 Jan 2005 16:09:53 +0100
To: Brian E Carpenter <[email-masked]>

El 19/01/2005, a las 15:53, Brian E Carpenter escribió:

> Focussing:
>
> >  In particular, the benefits would be the capability of establishing
> >  new communications through the alternative paths.
>
> Well, that is an intrinsic property of IPv6 surely - if a host has
> two addresses, and one fails, you can try the other.

Yes, but in this particular case, the multihomed host will have to 
retry with an alternative _source_ address.
RFC3484 states that hosts should retry with alternative destiantion 
address if they are available for the destiantion, but it is silent 
w.r.t. source address retrial.

In the case that a multihomed host with multiple address need to 
establish a new communication after an outage, it is likely that it 
will have to retry using a different source address. currently this is 
not specified anywhere.

> But since we
> can only get ULID to locator translation with a shim at both ends,
> I just don't see what is brought to this property by the shim;
> both ends will have to use the new locators at the ULP interface,
> so the shim has no work to do.

W.r.t what is the relation between this point and the shim wg i would 
say that:

- as i understand, the shim wg is about developing a multihoming 
solution. a key part of the solution is the shim layer to preserve 
establsihed communications through outages. however, there some other 
parts of a multihoming solutions that are important as well, and i 
think they need to be developed as part of the work of the shim wg. One 
of such pieces is the mechanisms to provide compatibility with ingress 
filtering. These are clearly not part of the shim layer but they are 
clearly needed to make a multihoming solution work. the capability of 
establishing new communications with non shim capable hosts can be seen 
imho as another one of such features. (the other one is the TE 
capability that was pointed out by Pekka S. that imho need some 
rewriting in the draft)

- otoh, even in communications between 2 shim capable nodes, the 
capability of establishing new communications after an outage is 
required. the point here is that, if both ends support the shim, then 
the used mechanisms can be different. However, the mechanisms for the 
case when one of the nodes in non shim capable could still be used in 
the case when the two nodes are shim capable. The tradeoff here is 
w.r.t. the additional benefits that can be achieved when both endpoints 
support the shim. But in any case, a mechanism for establsihing new 
communications after an outage is also needed for the shim. this 
mechanism can be designed in a way that it works with non shim capable 
hosts or not. My point is that in any case we need a mechanism to deal 
with non shim capable hosts. then we can explore if we will use the 
same one when the two nodes support the shim or if it worthy to design 
a new mechanism for this case.

Regards, marcelo

>
>    Brian
>

Delivery-date: Wed, 19 Jan 2005 14:53:50 +0000
Date: Wed, 19 Jan 2005 15:53:37 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

Focussing:

 >  In particular, the benefits would be the capability of establishing
 >  new communications through the alternative paths.

Well, that is an intrinsic property of IPv6 surely - if a host has
two addresses, and one fails, you can try the other. But since we
can only get ULID to locator translation with a shim at both ends,
I just don't see what is brought to this property by the shim;
both ends will have to use the new locators at the ULP interface,
so the shim has no work to do.

    Brian

Delivery-date: Wed, 19 Jan 2005 14:34:58 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Wed, 19 Jan 2005 16:23:44 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Brian,

> John, I don't understand.
> 
> If neither end is shim6-capable, it is resoundingly out
> of scope.

I think it would be out of scope as well, but I wanted to understand
what Marcelo was suggesting.
 
> If only one end is shim6-capable, we can't run shim6, so
> we have to revert to mono-homing.

For work group purposes, I agree - but in terms of solutions, I think
(after we do the shim6 protocol) finding a solution for it could be
possible, but that is not something that needs discussing now.

John
 
>     Brian
> 
> [email-masked] wrote:
> > Marcelo,
> > 
> > Are you speaking generally when we have 2 non-shim6 endpoints? If
> > so, we need a BCP on this, outside of the shim6 protocol.  This
> > seems much more like an operational issue.
> > 
> > If you are discussing how to do this when only 1 of the endpoints 
> > is shim6 aware, then I think this should be addressed in the shim6
> > protocol document.  
> > 
> > Or am I missing something?
> > 
> > John
> > 
> > 
> > 
> >>I don't know...
> >>I mean, on one hand, you are right, the shim protocol must 
> >>specify how 
> >>to deal with non-shim hosts. this means essentially the capability 
> >>detection functions of the functional dec draft.
> >>However, there is more that can be done in this context i 
> suppose. I 
> >>mean there are some fault tolerance capabilities that can 
> be provided 
> >>even though the communication is established with a non 
> shim host. In 
> >>particular, it is possible to establish new communications after an 
> >>outage if the host withn the multihomed site is able to 
> smartly select 
> >>the source address to be used for that communication. In 
> order to do 
> >>this, the multihomed host needs modifications in the source address 
> >>selection mechanism.
> >>Such mechanism could also be used when establishing 
> communications with 
> >>a shim node, but perhaps in this scenario superior solutions can be 
> >>obtained since both nodes implement the mechanism.
> >>So, i guess that my point is that when a non shim node is 
> >>involved in a 
> >>communication, it would be good if we did more that just  detecting 
> >>that the shim is not supported, but we could deploy mechanisms to 
> >>provide enhanced fault tolerance in this scenario.
> >>
> >>(It could also be noted that such mechanism is likely to be much 
> >>simpler than the whole shim and that it will, by itself, 
> provide some 
> >>degree of fault tolerance, so it may make sense to deploy it even 
> >>without the shim)
> >>
> >>Makes sense?
> >>
> >>regards, marcelo
> >>
> >>
> >>
> >>
> >>
> >>>John
> >>>
> >>
> >>
> >>
> > 
> > 
> 
> 
> 

Delivery-date: Wed, 19 Jan 2005 14:19:16 +0000
Cc: <[email-masked]>, <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Wed, 19 Jan 2005 15:19:24 +0100
To: <[email-masked]>

Hi John,

El 19/01/2005, a las 13:40, <[email-masked]> escribió:

> Marcelo,
>
> Are you speaking generally when we have 2 non-shim6 endpoints?

ok, let's focus on the case that one is shim and the other one is not.
sorry for introducing the other case.

Regards, marcelo

>  If
> so, we need a BCP on this, outside of the shim6 protocol.  This
> seems much more like an operational issue.
>
> If you are discussing how to do this when only 1 of the endpoints
> is shim6 aware, then I think this should be addressed in the shim6
> protocol document.
>
> Or am I missing something?
>
> John
>
>
>> I don't know...
>> I mean, on one hand, you are right, the shim protocol must
>> specify how
>> to deal with non-shim hosts. this means essentially the capability
>> detection functions of the functional dec draft.
>> However, there is more that can be done in this context i suppose. I
>> mean there are some fault tolerance capabilities that can be provided
>> even though the communication is established with a non shim host. In
>> particular, it is possible to establish new communications after an
>> outage if the host withn the multihomed site is able to smartly select
>> the source address to be used for that communication. In order to do
>> this, the multihomed host needs modifications in the source address
>> selection mechanism.
>> Such mechanism could also be used when establishing communications 
>> with
>> a shim node, but perhaps in this scenario superior solutions can be
>> obtained since both nodes implement the mechanism.
>> So, i guess that my point is that when a non shim node is
>> involved in a
>> communication, it would be good if we did more that just  detecting
>> that the shim is not supported, but we could deploy mechanisms to
>> provide enhanced fault tolerance in this scenario.
>>
>> (It could also be noted that such mechanism is likely to be much
>> simpler than the whole shim and that it will, by itself, provide some
>> degree of fault tolerance, so it may make sense to deploy it even
>> without the shim)
>>
>> Makes sense?
>>
>> regards, marcelo
>>
>>
>>
>>
>>> John
>>>
>>
>>
>>
>

Delivery-date: Wed, 19 Jan 2005 14:17:05 +0000
Cc: [email-masked], [email-masked], [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Wed, 19 Jan 2005 15:17:13 +0100
To: Brian E Carpenter <[email-masked]>

El 19/01/2005, a las 13:50, Brian E Carpenter escribió:

> marcelo bagnulo braun wrote:
>> El 19/01/2005, a las 13:04, <[email-masked]> escribió:
>>> Marcelo,
>>>
>>>> well, i am not sure about this...
>>>> My point was about establishing new communication after an outage 
>>>> with
>>>> external hosts that don't implement the shim.
>>>> This is important becuase at least in the early days, most of nodes
>>>> won't implement shim.
>>>> Explicitly taking this point into consideration would allow to 
>>>> provide
>>>> some degree of fault tolerance (i.e. the capability of establishing 
>>>> new
>>>> communications after an outage) even in communications with nodes 
>>>> that
>>>> don't implement the shim.
>>>
>>>
>>> This is a general transition issue; I guess the protocol should 
>>> specify how
>>> an shim6 endpoint works with a non-shim6 endpoint.
>>>
>> I don't know...
>> I mean, on one hand, you are right, the shim protocol must specify 
>> how to deal with non-shim hosts. this means essentially the 
>> capability detection functions of the functional dec draft.
>> However, there is more that can be done in this context i suppose. I 
>> mean there are some fault tolerance capabilities that can be provided 
>> even though the communication is established with a non shim host. In 
>> particular, it is possible to establish new communications after an 
>> outage if the host withn the multihomed site is able to smartly 
>> select the source address to be used for that communication. In order 
>> to do this, the multihomed host needs modifications in the source 
>> address selection mechanism.
>> Such mechanism could also be used when establishing communications 
>> with a shim node, but perhaps in this scenario superior solutions can 
>> be obtained since both nodes implement the mechanism.
>> So, i guess that my point is that when a non shim node is involved in 
>> a communication, it would be good if we did more that just  detecting 
>> that the shim is not supported, but we could deploy mechanisms to 
>> provide enhanced fault tolerance in this scenario.
>> (It could also be noted that such mechanism is likely to be much 
>> simpler than the whole shim and that it will, by itself, provide some 
>> degree of fault tolerance, so it may make sense to deploy it even 
>> without the shim)
>> Makes sense?
>
> Well, yes, but also no. RFC 1958 says "keep it simple" so (see previous
> message) my instinct is to forget about shim6 when the other end isn't
> shim6-capable.
>

But, imho, this would greatly reduce the benefits of the resulting 
solution....

I mean, this means that the resulting solution will only provide any 
kind of benefits when the two hosts involved in the communications 
implement the shim.
this would be ok if there were not possible to do better, but this is 
not the case.
We can design a solution that provide some of the fault tolerance 
capabilities when just one of the endpoints support the solution. In 
particular, the benefits would be the capability of establishing new 
communications through the alternative paths.

this would provide some fault tolerance benefits to the multihomed site 
independently of whether the external hosts support the shim or not.

imho this would render the multihoming solution much more attractive

so i would argue that we should explicitly include an item in the 
charter to do this

(i agree that not doing this would be simpler of course, but i think 
that establishing new communication after an outage is at least as 
important as preserving established ones for a lot of users and if we 
can provide this capability without requiring support of the external 
host it would be good, but i guess i am repeating myself)

(please note that during the presentation of the multi6 status on the 
ipv6, there was an explicit question on whether it was required to 
support both ends to obtain any multihoming benefit, as i recall, and 
this was seen as an issue)

Regards, marcelo

>    Brian
>
>

Delivery-date: Wed, 19 Jan 2005 14:14:13 +0000
Date: Wed, 19 Jan 2005 15:13:32 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

John, I don't understand.

If neither end is shim6-capable, it is resoundingly out
of scope.

If only one end is shim6-capable, we can't run shim6, so
we have to revert to mono-homing.

    Brian

[email-masked] wrote:
> Marcelo,
> 
> Are you speaking generally when we have 2 non-shim6 endpoints? If
> so, we need a BCP on this, outside of the shim6 protocol.  This
> seems much more like an operational issue.
> 
> If you are discussing how to do this when only 1 of the endpoints 
> is shim6 aware, then I think this should be addressed in the shim6
> protocol document.  
> 
> Or am I missing something?
> 
> John
> 
> 
> 
>>I don't know...
>>I mean, on one hand, you are right, the shim protocol must 
>>specify how 
>>to deal with non-shim hosts. this means essentially the capability 
>>detection functions of the functional dec draft.
>>However, there is more that can be done in this context i suppose. I 
>>mean there are some fault tolerance capabilities that can be provided 
>>even though the communication is established with a non shim host. In 
>>particular, it is possible to establish new communications after an 
>>outage if the host withn the multihomed site is able to smartly select 
>>the source address to be used for that communication. In order to do 
>>this, the multihomed host needs modifications in the source address 
>>selection mechanism.
>>Such mechanism could also be used when establishing communications with 
>>a shim node, but perhaps in this scenario superior solutions can be 
>>obtained since both nodes implement the mechanism.
>>So, i guess that my point is that when a non shim node is 
>>involved in a 
>>communication, it would be good if we did more that just  detecting 
>>that the shim is not supported, but we could deploy mechanisms to 
>>provide enhanced fault tolerance in this scenario.
>>
>>(It could also be noted that such mechanism is likely to be much 
>>simpler than the whole shim and that it will, by itself, provide some 
>>degree of fault tolerance, so it may make sense to deploy it even 
>>without the shim)
>>
>>Makes sense?
>>
>>regards, marcelo
>>
>>
>>
>>
>>
>>>John
>>>
>>
>>
>>
> 
> 

Delivery-date: Wed, 19 Jan 2005 12:51:35 +0000
Date: Wed, 19 Jan 2005 13:50:51 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

marcelo bagnulo braun wrote:
> 
> El 19/01/2005, a las 13:04, <[email-masked]> escribió:
> 
>> Marcelo,
>>
>>> well, i am not sure about this...
>>> My point was about establishing new communication after an outage with
>>> external hosts that don't implement the shim.
>>> This is important becuase at least in the early days, most of nodes
>>> won't implement shim.
>>> Explicitly taking this point into consideration would allow to provide
>>> some degree of fault tolerance (i.e. the capability of establishing new
>>> communications after an outage) even in communications with nodes that
>>> don't implement the shim.
>>
>>
>> This is a general transition issue; I guess the protocol should 
>> specify how
>> an shim6 endpoint works with a non-shim6 endpoint.
>>
> 
> I don't know...
> I mean, on one hand, you are right, the shim protocol must specify how 
> to deal with non-shim hosts. this means essentially the capability 
> detection functions of the functional dec draft.
> However, there is more that can be done in this context i suppose. I 
> mean there are some fault tolerance capabilities that can be provided 
> even though the communication is established with a non shim host. In 
> particular, it is possible to establish new communications after an 
> outage if the host withn the multihomed site is able to smartly select 
> the source address to be used for that communication. In order to do 
> this, the multihomed host needs modifications in the source address 
> selection mechanism.
> Such mechanism could also be used when establishing communications with 
> a shim node, but perhaps in this scenario superior solutions can be 
> obtained since both nodes implement the mechanism.
> So, i guess that my point is that when a non shim node is involved in a 
> communication, it would be good if we did more that just  detecting that 
> the shim is not supported, but we could deploy mechanisms to provide 
> enhanced fault tolerance in this scenario.
> 
> (It could also be noted that such mechanism is likely to be much simpler 
> than the whole shim and that it will, by itself, provide some degree of 
> fault tolerance, so it may make sense to deploy it even without the shim)
> 
> Makes sense?
> 

Well, yes, but also no. RFC 1958 says "keep it simple" so (see previous
message) my instinct is to forget about shim6 when the other end isn't
shim6-capable.

    Brian

Delivery-date: Wed, 19 Jan 2005 12:48:46 +0000
Date: Wed, 19 Jan 2005 13:48:37 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

[email-masked] wrote:
> Marcelo,
> 
> 
>>well, i am not sure about this...
>>My point was about establishing new communication after an outage with 
>>external hosts that don't implement the shim.
>>This is important becuase at least in the early days, most of nodes 
>>won't implement shim.
>>Explicitly taking this point into consideration would allow to provide 
>>some degree of fault tolerance (i.e. the capability of establishing new 
>>communications after an outage) even in communications with nodes that 
>>don't implement the shim.
> 
> 
> This is a general transition issue; I guess the protocol should specify how
> an shim6 endpoint works with a non-shim6 endpoint.

The simple answer is that it then works like a non-shim endpoint.
The goals in RFC 3582 don't include any benefits for non-multi6-aware
hosts.

     Brian

Delivery-date: Wed, 19 Jan 2005 12:46:34 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Wed, 19 Jan 2005 14:40:16 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Marcelo,

Are you speaking generally when we have 2 non-shim6 endpoints? If
so, we need a BCP on this, outside of the shim6 protocol.  This
seems much more like an operational issue.

If you are discussing how to do this when only 1 of the endpoints 
is shim6 aware, then I think this should be addressed in the shim6
protocol document.  

Or am I missing something?

John

> I don't know...
> I mean, on one hand, you are right, the shim protocol must 
> specify how 
> to deal with non-shim hosts. this means essentially the capability 
> detection functions of the functional dec draft.
> However, there is more that can be done in this context i suppose. I 
> mean there are some fault tolerance capabilities that can be provided 
> even though the communication is established with a non shim host. In 
> particular, it is possible to establish new communications after an 
> outage if the host withn the multihomed site is able to smartly select 
> the source address to be used for that communication. In order to do 
> this, the multihomed host needs modifications in the source address 
> selection mechanism.
> Such mechanism could also be used when establishing communications with 
> a shim node, but perhaps in this scenario superior solutions can be 
> obtained since both nodes implement the mechanism.
> So, i guess that my point is that when a non shim node is 
> involved in a 
> communication, it would be good if we did more that just  detecting 
> that the shim is not supported, but we could deploy mechanisms to 
> provide enhanced fault tolerance in this scenario.
> 
> (It could also be noted that such mechanism is likely to be much 
> simpler than the whole shim and that it will, by itself, provide some 
> degree of fault tolerance, so it may make sense to deploy it even 
> without the shim)
> 
> Makes sense?
> 
> regards, marcelo
> 
> 
> 
> 
> > John
> >
> 
> 
> 

Delivery-date: Wed, 19 Jan 2005 12:31:26 +0000
Cc: <[email-masked]>, <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Wed, 19 Jan 2005 13:31:30 +0100
To: <[email-masked]>

El 19/01/2005, a las 13:04, <[email-masked]> escribió:

> Marcelo,
>
>> well, i am not sure about this...
>> My point was about establishing new communication after an outage with
>> external hosts that don't implement the shim.
>> This is important becuase at least in the early days, most of nodes
>> won't implement shim.
>> Explicitly taking this point into consideration would allow to provide
>> some degree of fault tolerance (i.e. the capability of establishing 
>> new
>> communications after an outage) even in communications with nodes that
>> don't implement the shim.
>
> This is a general transition issue; I guess the protocol should 
> specify how
> an shim6 endpoint works with a non-shim6 endpoint.
>

I don't know...
I mean, on one hand, you are right, the shim protocol must specify how 
to deal with non-shim hosts. this means essentially the capability 
detection functions of the functional dec draft.
However, there is more that can be done in this context i suppose. I 
mean there are some fault tolerance capabilities that can be provided 
even though the communication is established with a non shim host. In 
particular, it is possible to establish new communications after an 
outage if the host withn the multihomed site is able to smartly select 
the source address to be used for that communication. In order to do 
this, the multihomed host needs modifications in the source address 
selection mechanism.
Such mechanism could also be used when establishing communications with 
a shim node, but perhaps in this scenario superior solutions can be 
obtained since both nodes implement the mechanism.
So, i guess that my point is that when a non shim node is involved in a 
communication, it would be good if we did more that just  detecting 
that the shim is not supported, but we could deploy mechanisms to 
provide enhanced fault tolerance in this scenario.

(It could also be noted that such mechanism is likely to be much 
simpler than the whole shim and that it will, by itself, provide some 
degree of fault tolerance, so it may make sense to deploy it even 
without the shim)

Makes sense?

regards, marcelo

> John
>

Delivery-date: Wed, 19 Jan 2005 12:15:51 +0000
Cc: <[email-masked]>
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Wed, 19 Jan 2005 12:42:26 +0100
To: <[email-masked]>

On 2005-01-18, at 11.45, <[email-masked]> wrote:

> I cannot think of a good term - in the initial charter, I interpreted
> state to be internal protocol state; but there are a lot of other 
> related
> types of state that the seperate document should cover, in my opinion.

Agreed, and the various "types" of state or linked, and perhaps should 
be described together.

- - kurtis -

Delivery-date: Wed, 19 Jan 2005 12:07:10 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Wed, 19 Jan 2005 14:04:18 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Marcelo,

> well, i am not sure about this...
> My point was about establishing new communication after an outage with 
> external hosts that don't implement the shim.
> This is important becuase at least in the early days, most of nodes 
> won't implement shim.
> Explicitly taking this point into consideration would allow to provide 
> some degree of fault tolerance (i.e. the capability of establishing new 
> communications after an outage) even in communications with nodes that 
> don't implement the shim.

This is a general transition issue; I guess the protocol should specify how
an shim6 endpoint works with a non-shim6 endpoint.

John

Delivery-date: Wed, 19 Jan 2005 11:50:07 +0000
Content-class: urn:content-classes:message
Subject: RE: State machine / failure detection / rehoming support
Date: Wed, 19 Jan 2005 13:42:51 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Joel,

> I am wondering if the split being discussed is actually different from a 
> protocol / FSM split.

I am as well.
 
> What is described seems very close to produce "service definitions".
> We could write a document which described the exxternal behavior that shim6 
> provides, and a separate document describing the protocol that meets taht 
> "service definition".  This is the normal practice in other standards bodies.
> It is sometimes useful for IETF protocols.  (The Forces transport mapping 
> layer will probably be defined this way, with luck.)
> 
> However, this often introduces a degree of complexity, and an extended 
> argument about whether a given behavior is necessary, or must be visible, 
> etc...
> 
> The issue probably turns on two aspects:
> 1) The degree of complexity of the service specification.  If it is easy, 
> then it often is helpful and sufficient to carry it in the protocol 
> document, but in a clearly separated early portion.  On the other hand, if 
> the service description and the interactions of the aspects of the service 
> behavior are complex, then there may be good reasons for a separate service 
> document.
> 2) There is also the dimension of the degree of variation in supporting 
> protocols we anticipate / desire / ...  If the variation is very small, 
> then there is not much point in worrying about it.  If the variation is 
> extremely large, then even a separate service document won't help.  In the 
> middle range, the separation can be helpful.

One could imagine writing an applicability statement for different services
or uses for shim6 - applicability for realtime services, tcp services, udp services
and so on.  Is this similar to your 'service definitions'?
 
> At the same time, I have real trouble separating the finite state machine 
> of the protocol (as opposed to the states seen by the shim6 user) from the 
> definition of the protocol.

Agreed.

John

Delivery-date: Wed, 19 Jan 2005 11:45:03 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Wed, 19 Jan 2005 13:40:06 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Marcelo,

> i am not sure that the wording is appropriate here...
> I mean failure detection and rehoming involves at least the following 
> items:
> - Detecting the failure, which involves different heuristics that 
> depnds on the apps, and other external triggers like ICMP error 
> messages, and then probably some attempt to perform an explict 
> reachability test, which would fail
> - then exploring alternative paths and identifying one that is working
> - and finally moving the communication to the new path, which 
> probably 
> requires a reachability test to the new locator pair (in order to 
> prevent flooding) and perhaps a signaling message to inform about the 
> locator change (something like a BU in mip)
> 
> Now, even though all this is involved in the failure and rehoming 
> event, some parts of this fall within the protocol, (in particular, the 
> messages to verify reachability, and the messages to change the locator 
> being used), while otoh some other items belong to the state management 
> part, like when to determine that a failuer is occurring and launch the 
> rehoming process
> 
> I guess that we have on one hand the protocol that is needed to do this 
> (reachanility test, alternative path exploration messages and rehoming 
> signaling) and on the other hand we have some heuristics that will be 
> used to determine failures and rehoming events.

My proposal was for something a lot simple.  I think we need:

a) General architecture for shim6;
b) General protocol mechanism for shim6 (stressing general);
c) document on multihoming triggers - basically figuring out when to
   invoke the shim6 protocol mechanism.

For c) there are some no brainers like starting up an interface or removing
an interface; slightly more tricky might be some mobility related events
or layer 2 indicators; more tricky still are failure detection.  Failure
detection is tricky because what constitutes failure - 4 TCP retransmissions?
And so on.  This includes different heuristics, etc.

I think that a general protocol could take the multihoming trigger document
and then do the things you list above - reachability tests, path exploration,
new locator pair selection ...

Am I making sense here?

John

Delivery-date: Wed, 19 Jan 2005 06:26:34 +0000
Date: Tue, 18 Jan 2005 18:00:54 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "Joel M. Halpern" <[email-masked]>
CC: [email-masked]
Subject: Re: State machine / failure detection / rehoming support

Joel M. Halpern wrote:

(much good sense deleted)

> At the same time, I have real trouble separating the finite state 
 > machine of the protocol (as opposed to the states seen by the shim6
 > user) from the definition of the protocol.

Yes, I certainly don't mean it's easy to do. And maybe what needs
to be separate is that external view of the states, rather than
the fully specified FSM, which I agree is tightly bound to the
protocol.

    Brian

Delivery-date: Tue, 18 Jan 2005 15:34:37 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Tue, 18 Jan 2005 16:34:43 +0100
To: Kurt Erik Lindqvist <[email-masked]>

Hi Kurtis,

El 18/01/2005, a las 10:52, Kurt Erik Lindqvist escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> I managed to screw up the To address on this mail...
>
> Begin forwarded message:
>
>> From: Kurt Erik Lindqvist <[email-masked]>
>> Date: den 18 januari 2005 09.58.52 MET
>> To: <[email-masked]> <[email-masked]> <[email-masked]>
>> Subject: Re: multi6-functional-dec and re-homing
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On 2005-01-17, at 13.52, <[email-masked]> wrote:
>>> Could I suggest a change to the current charter:
>>>
>>> From:
>>>
>>> 	MAY 05    First draft of architectural and protocol document
>>> 	MAY 05    First draft on cryptographic locators, if required
>>> 	MAY 05    First draft on state managment
>>>
>>> To:
>>>
>>> 	MAY 05    First draft of architectural and protocol document
>>> 	MAY 05    First draft on cryptographic locators, if required
>>> 	MAY 05    First draft on failure & rehoming event description
>>>
>>> This is, of course, not considering the discussion we have had about
>>> the
>>> potential need for a seperate architecture draft.
>>>
>>> Anyhow, State management to me, means the internal protocol state, 
>>> and
>>> message processing rules, etc.  For example, I think
>>> draft-arkko-multi6dt-failure-detection-00.txt might cover some of 
>>> what
>>> I'm thinking about. I also wonder if any of the work in DNA could
>>> also be referenced here.  I'm definately interested in contributing
>>> on this topic.
>>
>> so having thought a bit on this, and started working on an updated
>> version of the charter. I originally put in the state machine document
>> to have the entire document set somewhat more "modular", but also
>> because I thought that making an conscious effort to try and develop
>> the statemachine. After reading the mails here, Johns mail on the
>> "interaction" with transport made me think that having these as to
>> separate documents probably is a good idea - as we might want to 
>> change
>> state interaction with transport without changing protocol elements.
>>
>> As for the proposal above to change the name, isn't failure and
>> rehoming also somewhat misleading as sate is also establishment and
>> disconnect (I guess also somewhat along what Marcelo pointed to)?
>>

well, i am not sure about this...
My point was about establishing new communication after an outage with 
external hosts that don't implement the shim.
This is important becuase at least in the early days, most of nodes 
won't implement shim.
Explicitly taking this point into consideration would allow to provide 
some degree of fault tolerance (i.e. the capability of establishing new 
communications after an outage) even in communications with nodes that 
don't implement the shim.

Regards, marcelo

>> I am for keeping this as a separate document, but I am open for
>> suggestions on names. I will try and write some more text explaining
>> the context/content of the document....
>>
>> - - kurtis -
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: PGP 8.1
>>
>> iQA/AwUBQezP06arNKXTPFCVEQKxugCggpVDuhlCkIi5Ab2gaQDBm10FGdEAn0/S
>> SlN5Z65lV7Vo/eK2+J2+lz/Q
>> =R2HV
>> -----END PGP SIGNATURE-----
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBQezcZqarNKXTPFCVEQJRKwCg6B1J5ky/bwsq83HHSnSTha/p9LUAoMGw
> HtF6bs1kpYcg1VFXeo29G2fe
> =sRlp
> -----END PGP SIGNATURE-----
>
>

Delivery-date: Tue, 18 Jan 2005 15:32:08 +0000
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Tue, 18 Jan 2005 16:32:10 +0100
To: <[email-masked]>

Hi,
a comment about the proposed draft...

El 17/01/2005, a las 13:52, <[email-masked]> escribió:

> Hi Brian,
>
>> The charter does need to be clarified... that's one reason we've
>> asked for a BOF. You're correct of course, the state machine doesn't
>> have to define the triggers, but it certainly defines the points at
>> which they will be applied.
>
> Could I suggest a change to the current charter:
>
> From:
>
> 	MAY 05    First draft of architectural and protocol document
> 	MAY 05    First draft on cryptographic locators, if required
> 	MAY 05    First draft on state managment
>
> To:
>
> 	MAY 05    First draft of architectural and protocol document
> 	MAY 05    First draft on cryptographic locators, if required
> 	MAY 05    First draft on failure & rehoming event description
>

i am not sure that the wording is appropriate here...
I mean failure detection and rehoming involves at least the following 
items:
- Detecting the failure, which involves different heuristics that 
depnds on the apps, and other external triggers like ICMP error 
messages, and then probably some attempt to perform an explict 
reachability test, which would fail
- then exploring alternative paths and identifying one that is working
- and finally moving the communication to the new path, which probably 
requires a reachability test to the new locator pair (in order to 
prevent flooding) and perhaps a signaling message to inform about the 
locator change (something like a BU in mip)

Now, even though all this is involved in the failure and rehoming 
event, some parts of this fall within the protocol, (in particular, the 
messages to verify reachability, and the messages to change the locator 
being used), while otoh some other items belong to the state management 
part, like when to determine that a failuer is occurring and launch the 
rehoming process

I guess that we have on one hand the protocol that is needed to do this 
(reachanility test, alternative path exploration messages and rehoming 
signaling) and on the other hand we have some heuristics that will be 
used to determine failures and rehoming events.

Regards, marcelo

> This is, of course, not considering the discussion we have had about 
> the
> potential need for a seperate architecture draft.
>
> Anyhow, State management to me, means the internal protocol state, and
> message processing rules, etc.  For example, I think
> draft-arkko-multi6dt-failure-detection-00.txt might cover some of what
> I'm thinking about. I also wonder if any of the work in DNA could
> also be referenced here.  I'm definately interested in contributing
> on this topic.
>
> John
>
>

Delivery-date: Tue, 18 Jan 2005 14:57:26 +0000
Date: Tue, 18 Jan 2005 09:56:43 -0500
To: [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: State machine / failure detection / rehoming support

I am wondering if the split being discussed is actually different from a 
protocol / FSM split.

What is described seems very close to produce "service definitions".
We could write a document which described the exxternal behavior that shim6 
provides, and a separate document describing the protocol that meets taht 
"service definition".  This is the normal practice in other standards bodies.
It is sometimes useful for IETF protocols.  (The Forces transport mapping 
layer will probably be defined this way, with luck.)

However, this often introduces a degree of complexity, and an extended 
argument about whether a given behavior is necessary, or must be visible, 
etc...

The issue probably turns on two aspects:
1) The degree of complexity of the service specification.  If it is easy, 
then it often is helpful and sufficient to carry it in the protocol 
document, but in a clearly separated early portion.  On the other hand, if 
the service description and the interactions of the aspects of the service 
behavior are complex, then there may be good reasons for a separate service 
document.
2) There is also the dimension of the degree of variation in supporting 
protocols we anticipate / desire / ...  If the variation is very small, 
then there is not much point in worrying about it.  If the variation is 
extremely large, then even a separate service document won't help.  In the 
middle range, the separation can be helpful.

At the same time, I have real trouble separating the finite state machine 
of the protocol (as opposed to the states seen by the shim6 user) from the 
definition of the protocol.

Yours,
Joel

At 02:28 AM 1/18/2005, Brian E Carpenter wrote:
><hat chair=off>
>
>I still disagree. As I said before, I am very concerned that we shouldn't
>preclude later changes/enhancements (imagine introducing HIP identifiers,
>for example) and that means the shim6 protocol needs to be clearly
>separable from the shim6 state machine. So without disagreeing at all with
>John's comments on state machines, triggers, etc - I'd like RFC-statemachine
>to be separate from RFC-protocol.
>
>     Brian
></hat>
>

Delivery-date: Tue, 18 Jan 2005 10:47:40 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Tue, 18 Jan 2005 12:45:04 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Kurtis,

> On 2005-01-17, at 13.52, <[email-masked]> wrote:
>> Could I suggest a change to the current charter:
>>
>> From:
>>
>> 	MAY 05    First draft of architectural and protocol document
>> 	MAY 05    First draft on cryptographic locators, if required
>> 	MAY 05    First draft on state managment
>>
>> To:
>>
>> 	MAY 05    First draft of architectural and protocol document
>> 	MAY 05    First draft on cryptographic locators, if required
>> 	MAY 05    First draft on failure & rehoming event description
>>
>> This is, of course, not considering the discussion we have had about
>> the
>> potential need for a seperate architecture draft.
>>
>> Anyhow, State management to me, means the internal protocol state, and
>> message processing rules, etc.  For example, I think
>> draft-arkko-multi6dt-failure-detection-00.txt might cover some of what
>> I'm thinking about. I also wonder if any of the work in DNA could
>> also be referenced here.  I'm definately interested in contributing
>> on this topic.
>
> so having thought a bit on this, and started working on an updated
> version of the charter. I originally put in the state machine document
> to have the entire document set somewhat more "modular", but also
> because I thought that making an conscious effort to try and develop
> the statemachine. After reading the mails here, Johns mail on the
> "interaction" with transport made me think that having these as to
> separate documents probably is a good idea - as we might want to change
> state interaction with transport without changing protocol elements.
>
> As for the proposal above to change the name, isn't failure and
> rehoming also somewhat misleading as sate is also establishment and
> disconnect (I guess also somewhat along what Marcelo pointed to)?
>
> I am for keeping this as a separate document, but I am open for
> suggestions on names. I will try and write some more text explaining
> the context/content of the document....

I cannot think of a good term - in the initial charter, I interpreted
state to be internal protocol state; but there are a lot of other related
types of state that the seperate document should cover, in my opinion.

John

Delivery-date: Tue, 18 Jan 2005 10:31:58 +0000
Content-class: urn:content-classes:message
Subject: RE: State machine / failure detection / rehoming support
Date: Tue, 18 Jan 2005 12:29:14 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Brian,

I'm not wedded to my position, so if the bof feels strongly about this, we can
keep these as seperate deliverables, as long as the protocol RFC is a rather
complete specification.

John

> > I'd suggest considering some of the material in the "Multi6 Failure Detection" draft,
> > 
> http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-00.txt	
> be taken as a base for the deliverable: "failure & rehoming event description" / 
> "state machine."  However, I'd suggest that Section 5 which actually defines a
> state machine is would better fit a protocol state machine discription and be
> in the main protocol document.  Additionally, I'd much rather have the draft
> generalized into a failure & rehoming detection draft.  
> 
> Its reasonable to think that a host might have some watchdog associated with a 
> particular path, and when the path is available, the shim6 protocol might want
> to rehome to that particular path. A scenario is that there can be a failure
> on a particular path, so when the failure is detected, the shim6 switches to
> another path.  After the original path is repaired, the host might like to rehome
> to it.  This is something that SCTP does, for example.
> 
> Comments?

<hat chair=off>

I still disagree. As I said before, I am very concerned that we shouldn't
preclude later changes/enhancements (imagine introducing HIP identifiers,
for example) and that means the shim6 protocol needs to be clearly
separable from the shim6 state machine. So without disagreeing at all with
John's comments on state machines, triggers, etc - I'd like RFC-statemachine
to be separate from RFC-protocol.

     Brian
</hat>

Delivery-date: Tue, 18 Jan 2005 09:51:22 +0000
To: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: multi6-functional-dec and re-homing
Date: Tue, 18 Jan 2005 10:52:32 +0100

I managed to screw up the To address on this mail...

Begin forwarded message:

> From: Kurt Erik Lindqvist <[email-masked]>
> Date: den 18 januari 2005 09.58.52 MET
> To: <[email-masked]> <[email-masked]> <[email-masked]>
> Subject: Re: multi6-functional-dec and re-homing
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 2005-01-17, at 13.52, <[email-masked]> wrote:
>> Could I suggest a change to the current charter:
>>
>> From:
>>
>> 	MAY 05    First draft of architectural and protocol document
>> 	MAY 05    First draft on cryptographic locators, if required
>> 	MAY 05    First draft on state managment
>>
>> To:
>>
>> 	MAY 05    First draft of architectural and protocol document
>> 	MAY 05    First draft on cryptographic locators, if required
>> 	MAY 05    First draft on failure & rehoming event description
>>
>> This is, of course, not considering the discussion we have had about
>> the
>> potential need for a seperate architecture draft.
>>
>> Anyhow, State management to me, means the internal protocol state, and
>> message processing rules, etc.  For example, I think
>> draft-arkko-multi6dt-failure-detection-00.txt might cover some of what
>> I'm thinking about. I also wonder if any of the work in DNA could
>> also be referenced here.  I'm definately interested in contributing
>> on this topic.
>
> so having thought a bit on this, and started working on an updated
> version of the charter. I originally put in the state machine document
> to have the entire document set somewhat more "modular", but also
> because I thought that making an conscious effort to try and develop
> the statemachine. After reading the mails here, Johns mail on the
> "interaction" with transport made me think that having these as to
> separate documents probably is a good idea - as we might want to change
> state interaction with transport without changing protocol elements.
>
> As for the proposal above to change the name, isn't failure and
> rehoming also somewhat misleading as sate is also establishment and
> disconnect (I guess also somewhat along what Marcelo pointed to)?
>
> I am for keeping this as a separate document, but I am open for
> suggestions on names. I will try and write some more text explaining
> the context/content of the document....
>
> - - kurtis -
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBQezP06arNKXTPFCVEQKxugCggpVDuhlCkIi5Ab2gaQDBm10FGdEAn0/S
> SlN5Z65lV7Vo/eK2+J2+lz/Q
> =R2HV
> -----END PGP SIGNATURE-----
>

Delivery-date: Tue, 18 Jan 2005 09:24:48 +0000
Date: Tue, 18 Jan 2005 08:28:16 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
CC: [email-masked]
Subject: Re: State machine / failure detection / rehoming support

[email-masked] wrote:
> Following on my previous mail,
> 
> I'd suggest considering some of the material in the "Multi6 Failure Detection" draft,
> http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-00.txt	
> be taken as a base for the deliverable: "failure & rehoming event description" / 
> "state machine."  However, I'd suggest that Section 5 which actually defines a
> state machine is would better fit a protocol state machine discription and be
> in the main protocol document.  Additionally, I'd much rather have the draft
> generalized into a failure & rehoming detection draft.  
> 
> Its reasonable to think that a host might have some watchdog associated with a 
> particular path, and when the path is available, the shim6 protocol might want
> to rehome to that particular path. A scenario is that there can be a failure
> on a particular path, so when the failure is detected, the shim6 switches to
> another path.  After the original path is repaired, the host might like to rehome
> to it.  This is something that SCTP does, for example.
> 
> Comments?

<hat chair=off>

I still disagree. As I said before, I am very concerned that we shouldn't
preclude later changes/enhancements (imagine introducing HIP identifiers,
for example) and that means the shim6 protocol needs to be clearly
separable from the shim6 state machine. So without disagreeing at all with
John's comments on state machines, triggers, etc - I'd like RFC-statemachine
to be separate from RFC-protocol.

     Brian
</hat>

Delivery-date: Mon, 17 Jan 2005 13:16:25 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Mon, 17 Jan 2005 14:52:57 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Brian,

> The charter does need to be clarified... that's one reason we've
> asked for a BOF. You're correct of course, the state machine doesn't
> have to define the triggers, but it certainly defines the points at
> which they will be applied.

Could I suggest a change to the current charter:

From:

	MAY 05    First draft of architectural and protocol document
	MAY 05    First draft on cryptographic locators, if required
	MAY 05    First draft on state managment

To:

	MAY 05    First draft of architectural and protocol document
	MAY 05    First draft on cryptographic locators, if required
	MAY 05    First draft on failure & rehoming event description

This is, of course, not considering the discussion we have had about the
potential need for a seperate architecture draft.

Anyhow, State management to me, means the internal protocol state, and
message processing rules, etc.  For example, I think 
draft-arkko-multi6dt-failure-detection-00.txt might cover some of what
I'm thinking about. I also wonder if any of the work in DNA could
also be referenced here.  I'm definately interested in contributing
on this topic.

John

Delivery-date: Mon, 17 Jan 2005 13:05:56 +0000
Content-class: urn:content-classes:message
Subject: State machine / failure detection / rehoming support
Date: Mon, 17 Jan 2005 15:02:51 +0200
From: <[email-masked]>
To: <[email-masked]>

Following on my previous mail,

I'd suggest considering some of the material in the "Multi6 Failure Detection" draft,
http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-00.txt	
be taken as a base for the deliverable: "failure & rehoming event description" / 
"state machine."  However, I'd suggest that Section 5 which actually defines a
state machine is would better fit a protocol state machine discription and be
in the main protocol document.  Additionally, I'd much rather have the draft
generalized into a failure & rehoming detection draft.  

Its reasonable to think that a host might have some watchdog associated with a 
particular path, and when the path is available, the shim6 protocol might want
to rehome to that particular path. A scenario is that there can be a failure
on a particular path, so when the failure is detected, the shim6 switches to
another path.  After the original path is repaired, the host might like to rehome
to it.  This is something that SCTP does, for example.

Comments?
John

Delivery-date: Mon, 17 Jan 2005 12:10:55 +0000
Date: Mon, 17 Jan 2005 13:10:41 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: multi6-functional-dec and re-homing

(cross-posting removed...)

[email-masked] wrote:
> Brian,
> 
> A short comment:
> 
> 
>>>>This would support a larger set of possible re-homing scenarios, and I
>>>>think it is compatible with the wordings of re-homing definition in
>>>>draft-ietf-multi6-architecture-03.txt.
>>>>
>>>>I had a short off-list mail exchange with Marcelo and Jari and they
>>>>agreed, but recommended to solicit the list opinion as well.
>>>
>>>
>>>I have no objections to the text leaving this possibility open,
>>
>>ditto
>>
>>
>>>but I 
>>>have some more concerns about actually implementing this.
>>
>>In a sense, it's to leave this door open that I've been arguing
>>over on shim6 that we should separate the state machine (and by
>>implication, its APIs) from the shim6 protocol.
> 
> 
> This is really a shim6 discussion, but if that is what you mean by 
> the charter text, then I think the charter needs to be clarified.
> It sounds like you are talking about the re-homing events or triggers
> where, which I think should be documented seperate.  However, in
> a classical state machine, you don't need to detail the events or
> triggers which cause the state change, but just the transitions
> between the states.
> 
> I would support a document (in shim6) that covers the different
> re-homing events, etc.

The charter does need to be clarified... that's one reason we've
asked for a BOF. You're correct of course, the state machine doesn't
have to define the triggers, but it certainly defines the points at
which they will be applied.

    Brian

Delivery-date: Mon, 17 Jan 2005 11:19:42 +0000
Content-class: urn:content-classes:message
Subject: RE: multi6-functional-dec and re-homing
Date: Mon, 17 Jan 2005 13:17:28 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Brian,

A short comment:

> >>This would support a larger set of possible re-homing scenarios, and I
> >>think it is compatible with the wordings of re-homing definition in
> >>draft-ietf-multi6-architecture-03.txt.
> >>
> >>I had a short off-list mail exchange with Marcelo and Jari and they
> >>agreed, but recommended to solicit the list opinion as well.
> > 
> > 
> > I have no objections to the text leaving this possibility open,
> 
> ditto
> 
> > but I 
> > have some more concerns about actually implementing this.
> 
> In a sense, it's to leave this door open that I've been arguing
> over on shim6 that we should separate the state machine (and by
> implication, its APIs) from the shim6 protocol.

This is really a shim6 discussion, but if that is what you mean by 
the charter text, then I think the charter needs to be clarified.
It sounds like you are talking about the re-homing events or triggers
where, which I think should be documented seperate.  However, in
a classical state machine, you don't need to detail the events or
triggers which cause the state change, but just the transitions
between the states.

I would support a document (in shim6) that covers the different
re-homing events, etc.

John

Delivery-date: Fri, 14 Jan 2005 14:01:04 +0000
Content-class: urn:content-classes:message
Subject: RE: Mailing list and draft charter for new multihoming BOF/WG
Date: Fri, 14 Jan 2005 15:56:30 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Jari,

> (By the way, I think that we in the IETF have not
> used state machines quite as much as we perhaps
> could have. They do look boring, but they also
> help people ensure that all special conditions
> have been well defined.)

There is a pretty good tradition of state machines in 
the Transport Area; my assumption is (since Margaret was 
CC:ed on the charter announcement) that this BoF is
planned in the Internet Area.  My guess is that we should
have some Transport minders/advisor just as this
is a shim layer between IP & transport protocols.

John

Delivery-date: Fri, 14 Jan 2005 12:50:49 +0000
Date: Fri, 14 Jan 2005 14:49:53 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Mailing list and draft charter for new multihoming BOF/WG

Brian E Carpenter wrote:

> Now about separating state management. Firstly I wrote the
> text to retrospectively justify Kurtis's suggestion to have
> a separate document, and I don't know if I correctly read his
> mind.
> 
> Secondly, when I began to think about it, I really did see an
> argument for *consciously* designing the state machine separately
> (and logically, it should be designed first, not second).
> 
> Who's to say that we'll get the protocol right first time? It acts
> in support of the state machine, not the other way round, so the
> state machine is actually fundamental. Going to a v2 of the protocol
> probably shouldn't change the state machine, at the macro level.
> 
> Also, the state machine will not only respond to shim6 protocol events.
> It will also have to respond to unreachability signals, transport
> disconnect signals, etc.

This is all true, but past experience suggests
that state machines tend to be necessary for
the definition of the semantics of protocol
events, and that protocol messages tend to be
necessary for the development of state machines.
This speaks for the treatment of the two as a
whole. Different sides of the same coin. Whether
those are in the same or different document is
another matter perhaps.

(By the way, I think that we in the IETF have not
used state machines quite as much as we perhaps
could have. They do look boring, but they also
help people ensure that all special conditions
have been well defined.)

--Jari

Delivery-date: Fri, 14 Jan 2005 12:40:22 +0000
Cc: [email-masked], [email-masked], [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Mailing list and draft charter for new multihoming BOF/WG
Date: Fri, 14 Jan 2005 13:40:11 +0100
To: Brian E Carpenter <[email-masked]>

Hi,

El 14/01/2005, a las 12:09, Brian E Carpenter escribió:

> First, yes, an architecture document would be no bad thing
> (and in fact I think Geoff agreed to write one at the last IETF).
>
> <no chair hat on... this is a pre-BOF discussion>
>
> Now about separating state management. Firstly I wrote the
> text to retrospectively justify Kurtis's suggestion to have
> a separate document, and I don't know if I correctly read his
> mind.
>
> Secondly, when I began to think about it, I really did see an
> argument for *consciously* designing the state machine separately
> (and logically, it should be designed first, not second).
>
> Who's to say that we'll get the protocol right first time? It acts
> in support of the state machine, not the other way round, so the
> state machine is actually fundamental. Going to a v2 of the protocol
> probably shouldn't change the state machine, at the macro level.
>
> Also, the state machine will not only respond to shim6 protocol events.
> It will also have to respond to unreachability signals, transport
> disconnect signals, etc.
>

yes, this was my interpretation of the text of the draft.
i mean, i agree with Erik that the protocol spec should define how 
packets exchanges affect the state machine.
However, there are plenty of other events that will affect the event 
machine, like triggering alternative path exploration upon reception of 
icmp messages or interaction with apps and transport that i can see in 
a separate state management document. (perhaps the name of the doc is 
not very accurate...)

Regards, marcelo

> To me this *does* tend to argue for a separate document. But I 
> certainly
> agree it can't be developed sequentially.
>
>    Brian
>
> [email-masked] wrote:
>> Hi Erik,
>>> Perhaps I don't understand how state management is separable from 
>>> the behavior description of the protocol, but isn't the basic state 
>>> management (when/how state is created, maintained, and destroyed) 
>>> something which needs to be in the behavioral description of the 
>>> protocol?
>>> Thus I don't understand how state management can be a piece which 
>>> can be done later.
>> I agree. I think the state management document should be included in 
>> the
>> Architecture and Protocol document.  If there needs to be a document
>> split, I'd suggest having the architecture document seperate, which
>> would look more like a framework type of document - so informational
>> in nature. Then there could be a Protocol document.
>>
>>>> The WG will not consider items outside the above scope, such as
>>>> interaction with mobility, transport level solutions, or
>>>
>>> alternative
>>>> identifier formats.
>>>> [What other topics are explicitly out of scope?]
>>>
>>> Perhaps we should add that taking transport level hints ("things are 
>>> ok") into account is explicitly in scope.
>>>
>>>
>>>> Milestones
>>>>
>>>>
>>>> MAY 05    First draft of architectural and protocol document
>>>> MAY 05    First draft on cryptographic locators, if required
>>>> MAY 05    First draft on state managment
>>>
>>> This might be nit-picking on the set of documents, but I think it 
>>> makes sense to have a separate architectural document shows the 
>>> high-level aspects of the shim and the functional pieces, and this 
>>> is something that the WG can piece together from the input 
>>> documents.
>>>
>>> But the protocol document (packet formats, behavior including state 
>>> management) is something that needs to be created from the 
>>> functional decomposition and the outline in the failure detection 
>>> draft.
>>>
>>> So I think it makes sense to list those as separate deliverables
>>> (and not have a separate deliverable on state management.)
>> Agree, see above suggestion.
>>>> SEP 05    WG last-call on architectural/protocol document
>>>
>>> Should be ok for the arch document, but the protocol document  might 
>>> take longer time.
>> I agree. Noting the pace at which the IETF moves, I think 2006 is 
>> more reasonable,
>> unless we have a game-plan on how to move it that quickly.
>> John
>

Delivery-date: Fri, 14 Jan 2005 11:31:17 +0000
Content-class: urn:content-classes:message
Subject: RE: Mailing list and draft charter for new multihoming BOF/WG
Date: Fri, 14 Jan 2005 13:29:39 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Brian,

> Now about separating state management. Firstly I wrote the
> text to retrospectively justify Kurtis's suggestion to have
> a separate document, and I don't know if I correctly read his
> mind.
> 
> Secondly, when I began to think about it, I really did see an
> argument for *consciously* designing the state machine separately
> (and logically, it should be designed first, not second).
> 
> Who's to say that we'll get the protocol right first time? It acts
> in support of the state machine, not the other way round, so the
> state machine is actually fundamental. Going to a v2 of the protocol
> probably shouldn't change the state machine, at the macro level.
> 
> Also, the state machine will not only respond to shim6 protocol events.
> It will also have to respond to unreachability signals, transport
> disconnect signals, etc.
> 
> To me this *does* tend to argue for a separate document. But I certainly
> agree it can't be developed sequentially.

It might make sense to maintain it as a seperate document, but a protocol
document usually contains things like state diagrams, state transitions, etc.  
But going into more details, there is always an argument about having a clean
protocol definition, then having a document (not unlike an applicability
statement) that goes into how the protocol is used and in what circumstances.

However, I favor having a rather spartan charter at first, to ensure that
the bof is focused and clear, rather than overloading potential charter
items that we aren't completely sure of yet.

Just my 2 cents.
John

Delivery-date: Fri, 14 Jan 2005 11:09:44 +0000
Date: Fri, 14 Jan 2005 12:09:05 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Mailing list and draft charter for new multihoming BOF/WG

First, yes, an architecture document would be no bad thing
(and in fact I think Geoff agreed to write one at the last IETF).

<no chair hat on... this is a pre-BOF discussion>

Now about separating state management. Firstly I wrote the
text to retrospectively justify Kurtis's suggestion to have
a separate document, and I don't know if I correctly read his
mind.

Secondly, when I began to think about it, I really did see an
argument for *consciously* designing the state machine separately
(and logically, it should be designed first, not second).

Who's to say that we'll get the protocol right first time? It acts
in support of the state machine, not the other way round, so the
state machine is actually fundamental. Going to a v2 of the protocol
probably shouldn't change the state machine, at the macro level.

Also, the state machine will not only respond to shim6 protocol events.
It will also have to respond to unreachability signals, transport
disconnect signals, etc.

To me this *does* tend to argue for a separate document. But I certainly
agree it can't be developed sequentially.

    Brian

[email-masked] wrote:
> Hi Erik,
> 
> 
>>Perhaps I don't understand how state management is separable from the 
>>behavior description of the protocol, but isn't the basic state 
>>management (when/how state is created, maintained, and destroyed) 
>>something which needs to be in the behavioral description of the protocol?
>>Thus I don't understand how state management can be a piece which can be 
>>done later.
> 
> 
> I agree. I think the state management document should be included in the
> Architecture and Protocol document.  If there needs to be a document
> split, I'd suggest having the architecture document seperate, which
> would look more like a framework type of document - so informational
> in nature. Then there could be a Protocol document.
>  
> 
>>>The WG will not consider items outside the above scope, such as
>>>interaction with mobility, transport level solutions, or 
>>
>>alternative 
>>
>>>identifier formats.
>>>[What other topics are explicitly out of scope?]
>>
>>Perhaps we should add that taking transport level hints ("things are 
>>ok") into account is explicitly in scope.
>>
>>
>>>Milestones
>>>
>>>
>>>MAY 05    First draft of architectural and protocol document
>>>MAY 05    First draft on cryptographic locators, if required
>>>MAY 05    First draft on state managment
>>
>>This might be nit-picking on the set of documents, but I think it makes 
>>sense to have a separate architectural document shows the high-level 
>>aspects of the shim and the functional pieces, and this is something 
>>that the WG can piece together from the input documents.
>>
>>But the protocol document (packet formats, behavior including state 
>>management) is something that needs to be created from the functional 
>>decomposition and the outline in the failure detection draft.
>>
>>So I think it makes sense to list those as separate deliverables
>>(and not have a separate deliverable on state management.)
> 
> 
> Agree, see above suggestion.
> 
> 
>>>SEP 05    WG last-call on architectural/protocol document
>>
>>Should be ok for the arch document, but the protocol document  might take 
>>longer time.
> 
> 
> I agree. Noting the pace at which the IETF moves, I think 2006 is more reasonable,
> unless we have a game-plan on how to move it that quickly.
> 
> John
> 
> 

Delivery-date: Fri, 14 Jan 2005 09:43:31 +0000
Date: Fri, 14 Jan 2005 11:42:23 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Mailing list and draft charter for new multihoming BOF/WG

[email-masked] wrote:
> Hi Erik,
> 
> 
>>Perhaps I don't understand how state management is separable from the 
>>behavior description of the protocol, but isn't the basic state 
>>management (when/how state is created, maintained, and destroyed) 
>>something which needs to be in the behavioral description of the protocol?
>>Thus I don't understand how state management can be a piece which can be 
>>done later.
> 
> 
> I agree. I think the state management document should be included in the
> Architecture and Protocol document.  If there needs to be a document
> split, I'd suggest having the architecture document seperate, which
> would look more like a framework type of document - so informational
> in nature. Then there could be a Protocol document.

I agree with this as well.

--Jari

Delivery-date: Fri, 14 Jan 2005 07:19:41 +0000
Content-class: urn:content-classes:message
Subject: RE: Mailing list and draft charter for new multihoming BOF/WG
Date: Fri, 14 Jan 2005 09:10:41 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Erik,

> Perhaps I don't understand how state management is separable from the 
> behavior description of the protocol, but isn't the basic state 
> management (when/how state is created, maintained, and destroyed) 
> something which needs to be in the behavioral description of the protocol?
> Thus I don't understand how state management can be a piece which can be 
> done later.

I agree. I think the state management document should be included in the
Architecture and Protocol document.  If there needs to be a document
split, I'd suggest having the architecture document seperate, which
would look more like a framework type of document - so informational
in nature. Then there could be a Protocol document.
 
> > The WG will not consider items outside the above scope, such as
> > interaction with mobility, transport level solutions, or 
> alternative 
> > identifier formats.
> > [What other topics are explicitly out of scope?]
> 
> Perhaps we should add that taking transport level hints ("things are 
> ok") into account is explicitly in scope.
> 
> > Milestones
> > 
> > 
> > MAY 05    First draft of architectural and protocol document
> > MAY 05    First draft on cryptographic locators, if required
> > MAY 05    First draft on state managment
> 
> This might be nit-picking on the set of documents, but I think it makes 
> sense to have a separate architectural document shows the high-level 
> aspects of the shim and the functional pieces, and this is something 
> that the WG can piece together from the input documents.
> 
> But the protocol document (packet formats, behavior including state 
> management) is something that needs to be created from the functional 
> decomposition and the outline in the failure detection draft.
>
> So I think it makes sense to list those as separate deliverables
> (and not have a separate deliverable on state management.)

Agree, see above suggestion.

> > SEP 05    WG last-call on architectural/protocol document
> 
> Should be ok for the arch document, but the protocol document  might take 
> longer time.

I agree. Noting the pace at which the IETF moves, I think 2006 is more reasonable,
unless we have a game-plan on how to move it that quickly.

John

Delivery-date: Thu, 13 Jan 2005 19:27:43 +0000
Date: Thu, 13 Jan 2005 11:27:12 -0800
From: Erik Nordmark <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: [email-masked]
Subject: Re: Mailing list and draft charter for new multihoming BOF/WG

> Since the solution requires state to be maintained at both ends of a 
> communication, the protocol specification and the state machine will be designed
> somewhat independently. Some state transitions may result from external
> events such as failure detection rather than from protocol events. More work
> items and milestones might need to be added at a later date to
> complete all implementation details needed.

Perhaps I don't understand how state management is separable from the 
behavior description of the protocol, but isn't the basic state 
management (when/how state is created, maintained, and destroyed) 
something which needs to be in the behavioral description of the protocol?
Thus I don't understand how state management can be a piece which can be 
done later.

> The WG will not consider items outside the above scope, such as
> interaction with mobility, transport level solutions, or alternative 
> identifier formats.
> [What other topics are explicitly out of scope?]

Perhaps we should add that taking transport level hints ("things are 
ok") into account is explicitly in scope.

> Milestones
> 
> 
> MAY 05    First draft of architectural and protocol document
> MAY 05    First draft on cryptographic locators, if required
> MAY 05    First draft on state managment

This might be nit-picking on the set of documents, but I think it makes 
sense to have a separate architectural document shows the high-level 
aspects of the shim and the functional pieces, and this is something 
that the WG can piece together from the input documents.

But the protocol document (packet formats, behavior including state 
management) is something that needs to be created from the functional 
decomposition and the outline in the failure detection draft.

So I think it makes sense to list those as separate deliverables
(and not have a separate deliverable on state management.)

> SEP 05    WG last-call on architectural/protocol document

Should be ok for the arch document, but the protocol document might take 
longer time.

    Erik

Delivery-date: Thu, 13 Jan 2005 15:22:58 +0000
Date: Thu, 13 Jan 2005 16:22:49 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
Subject: Mailing list and draft charter for new multihoming BOF/WG

This is a multi-part message in MIME format.
--------------040500070103000307000802
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[Message replayed to the list to get it in the archive]

Hi,

As promised, Kurtis and I have drafted a charter for the proposed
WG to standardize the IPv6 multihoming shim layer.

The (perhaps temporary) mailing list is [email-masked]

Join by sending a message to [email-masked] containing
one line:
   subscribe shim6
and respond as necessary to the confirmation message.

The draft charter is attached. Please DO NOT discuss it on this
(multi6) list - if you want to discuss it, please join the shim6
list and discuss it there.

Be aware that if you reply to this message, your reply will be sent
to the shim6 list. It would be a good idea to subscribe first!

We will request a shim6 BOF at the next IETF, and also start the
process of forming at WG. But first, we need your comments on
the draft charter.

Regards

      Brian and Kurtis

P.S.

The final three multi6 deliverables were submitted to the IESG today.
That's
   draft-ietf-multi6-v4-multihoming-03
   draft-ietf-multi6-architecture-03.txt
   draft-ietf-multi6-things-to-think-about-01.txt

--------------040500070103000307000802
Content-Type: unknown/exe;
 name="draft-shim6-charter-20050111.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-shim6-charter-20050111.txt"

Site multiHoming by IPv6 interMediation (shim6)

Description of Working Group:

The shim6 WG is to produce specfifications for a complete IPv6 site
multihoming solutions based on the architecture developed by the IETF
multi6 WG. The multi6 WG was tasked with investigating solutions to
the site multihoming problem that will allow the global routing system to
scale. The outcome of the multi6 WG is a specific network layer shim
architecture for addressing and address handling of sites and nodes. This
includes switching to different locator addresses when connectivity changes,
but without the changes of address being visible to upper layers, which see
a fixed Upper Layer Identifier address (ULID).

The shim6 WG is to complete this work with the required protocol developments 
and complete the architecture and security analysis of the required protocols.

The background documents to be considered by the WG include:

 RFC 3582
 draft-ietf-multi6-things-to-think-about-01.txt
 draft-ietf-multi6-multihoming-threats-03.txt

The input documents that the WG will use as the basis for its design are:

 draft-huston-solution-stilltobewritten
 draft-ietf-multi6-functional-dec-00.txt
 draft-ietf-multi6-l3shim-00.txt [to be published shortly]
 draft-ietf-multi6-failure-detection-00.txt [to be published shortly]
 draft-ietf-multi6-hba-00.txt
 draft-ietf-multi6-app-refer-00.txt

[Comment - We specifically omitted the IPv4 document and Geoff's
architecture analysis - we're assuming that will be replaced for
the new WG by his solution architecture.]

The shim6 WG is to submit, as standards track RFCs, specifications with
enough details to allow full interoperable implementations of the shim
layer appproach to multihoming as agreed on by the multi6 WG. These
implementations should have the ability to take advantage of
multihoming without adding to the growth of the global routing table,
by using the aggregates already announced by their upstream providers. 

Since the solution requires state to be maintained at both ends of a 
communication, the protocol specification and the state machine will be designed
somewhat independently. Some state transitions may result from external
events such as failure detection rather than from protocol events. More work
items and milestones might need to be added at a later date to
complete all implementation details needed.

In addition to the basic network layer shim solution, the shim6 WG 
is specifically chartered to do work on

     o A solution for site exit router selection that works when each ISP 
       uses ingress filtering, i.e. when the chosen site exit needs to be 
       related to the source address chosen by the host. This solution 
       should work whether or not the peer site supports the shim6 protocol.

     o Explore how congestion control and other QoS and traffic engineering
       issues may interact with the use of multiple locators at both ends.

     o Investigate relationship between Upper Layer Identifiers (ULIDs)
       and Unique Local Addresses.

     o ICMP error demuxing for locator failure discovery.

     o If necessary, develop and specify formats and structure for

       - Cryptographically protected locators

       - Carrying the flow label across the shim layer 
         defined in the multi6 architecture.

The WG will consider whether the proposed model is exposed to
any security threats in addition to those documented in
draft-ietf-multi6-multihoming-threats-03.txt. In any case,
the specifications must specifically refer to all applicable threats
and describe how they are handled,  with the requirement being that 
the resulting solution not introduce any threats that make the 
security any less than in today's Internet.

The WG will not consider items outside the above scope, such as
interaction with mobility, transport level solutions, or alternative 
identifier formats.
[What other topics are explicitly out of scope?]

Milestones

MAY 05    First draft of architectural and protocol document
MAY 05    First draft on cryptographic locators, if required
MAY 05    First draft on state managment

SEP 05    WG last-call on architectural/protocol document

NOV 05    Submit complete architectural/protocol document to IESG
NOV 05    WG last-call on cryptographic locators, if required

JAN 06    WG last-call on state management
JAN 06    Submit draft on cryptographic locators to the IESG, if required

MAR 06    Submit draft on state management to the IESG

--------------040500070103000307000802--

Delivery-date: Thu, 13 Jan 2005 15:20:48 +0000
Date: Thu, 13 Jan 2005 16:20:33 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
Subject: List archive

There are probably enough people here now to mention
that the list archive is at http://psg.com/lists/shim6/threads.html

    Brian

Delivery-date: Thu, 13 Jan 2005 12:15:11 +0000
Content-class: urn:content-classes:message
Subject: RE: comments about the draft charter
Date: Thu, 13 Jan 2005 14:07:50 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Marcelo,

> i may agree that different solutions may be required for different scenarios.
> Would be good enough to rephrase it as the following?
> 
> - Solutions to establish new communications after an outage has
> occurred that does not requires shim support from the non-multihomed
> end of the communication. The wg will explore if such solutions are also
> useful when both ends support the shim.
> 
> I guess that the same rewording is needed in the previous item which 
> states that:
> 
>   o A solution for site exit router selection that works when each ISP
>         uses ingress filtering, i.e. when the chosen site exit needs to be
>         related to the source address chosen by the host. This solution
>         should work whether or not the peer site supports the shim6 protocol.
> 
> (i guess that in the case of ingress filtering more than one solutions 
> are likely)

I think that text is better

John

Delivery-date: Wed, 12 Jan 2005 16:29:07 +0000
Cc: Pekka Savola <[email-masked]>, [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Mailing list and draft charter for new multihoming BOF/WG
Date: Wed, 12 Jan 2005 17:29:03 +0100
To: Brian E Carpenter <[email-masked]>

Hi Brian, Pekka,

[I miss the initial message by Pekka, so i comment on this one]

El 12/01/2005, a las 14:31, Brian E Carpenter escribió:

> Pekka Savola wrote:
>> On Tue, 11 Jan 2005, Brian E Carpenter wrote:
>>> We will request a shim6 BOF at the next IETF, and also start the
>>> process of forming at WG. But first, we need your comments on
>>> the draft charter.
>> Two typos:
>> -The shim6 WG is to produce specfifications for a complete IPv6 site
>> -multihoming solutions based on the architecture developed by the IETF
>> +The shim6 WG is to produce specifications for a complete IPv6 site
>> +multihoming solution based on the architecture developed by the IETF
>> Major comment:
>> The text, again, makes a huge presumption that just by solving the 
>> connection survivability problems, we have a complete IPv6 site 
>> multihoming solution.

I agree that the proposed draft charter may read a bit connection 
survivability centric (especially if we look a the proposed title of 
the wg :-) but i would argue that the actual tasks contained in the 
draft cover most aspects of the multihoming problem.
As i see it, there are essentially the following issues to address in a 
multihoming solution:
- ingress filtering
- fault tolerance that includes the establishment of new communications 
and the preservation of established ones
- traffic engineering

the charter contains most of these points (the only one that is not 
explicetly stated is the establishment of new communications which is 
why i suggested to include it).

I may agree that TE may need a bit rephrasing so to make it clearer

But in general i would say that this charter with the inclusion of the 
item about establishemnt of new communications would allow to develop 
solutions to all the aspects of the multihoming problem that i can 
identify.

Regards, marcelo

>>   That may be true for certain kinds of sites, but this seems like a 
>> far fetch in general.
>

> Well, Geoff owes us the general solution architecture document. When we
> test that against RFC3582, we can address your question...
>
>    Brian
>

Delivery-date: Wed, 12 Jan 2005 13:32:02 +0000
Date: Wed, 12 Jan 2005 14:31:56 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Pekka Savola <[email-masked]>
CC: [email-masked]
Subject: Re: Mailing list and draft charter for new multihoming BOF/WG

Pekka Savola wrote:
> On Tue, 11 Jan 2005, Brian E Carpenter wrote:
> 
>> We will request a shim6 BOF at the next IETF, and also start the
>> process of forming at WG. But first, we need your comments on
>> the draft charter.
> 
> 
> Two typos:
> 
> -The shim6 WG is to produce specfifications for a complete IPv6 site
> -multihoming solutions based on the architecture developed by the IETF
> +The shim6 WG is to produce specifications for a complete IPv6 site
> +multihoming solution based on the architecture developed by the IETF
> 
> Major comment:
> 
> The text, again, makes a huge presumption that just by solving the 
> connection survivability problems, we have a complete IPv6 site 
> multihoming solution.  That may be true for certain kinds of sites, but 
> this seems like a far fetch in general.
> 

Well, Geoff owes us the general solution architecture document. When we
test that against RFC3582, we can address your question...

    Brian

Delivery-date: Wed, 12 Jan 2005 12:41:53 +0000
Cc: <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments about the draft charter
Date: Wed, 12 Jan 2005 13:41:32 +0100
To: <[email-masked]>

Hi John,

i may agree that different solutions may be required for different 
scenarios.
Would be good enough to rephrase it as the following?

- Solutions to establish new communications after an outage has
occurred that does not requires shim support from the non-multihomed
end of the communication. The wg will explore if such solutions are also
useful when both ends support the shim.

I guess that the same rewording is needed in the previous item which 
states that:

  o A solution for site exit router selection that works when each ISP
        uses ingress filtering, i.e. when the chosen site exit needs to 
be
        related to the source address chosen by the host. This solution
        should work whether or not the peer site supports the shim6 
protocol.

(i guess that in the case of ingress filtering more than one solutions 
are likely)

Regards, marcelo

El 12/01/2005, a las 8:02, <[email-masked]> escribió:

> Marcelo,
>
>> i would add an additional item here:
>>
>> - A solution to establish new communications after an outage has
>> occurred that does not requires shim support from the non-multihomed
>> end of the communication. The wg will explore if such solution is also
>> useful when both ends support the shim.
>>
>> imho this is relevant becuase it would provide an incremental
>> deployment model to the solution. If this is not provided, it is all 
>> or
>> nothing approach w.r.t. to fault tolerance i.e. if the other end
>> support the shim, then you get all the benefits but if the other end
>> does not supports the shim then no additional fault tolerance is
>> achieved.
>
> Do you think that there is 'a' solution?  I have a feeling that there
> are multiple solutions, at least for different scenarios.  I feel 
> somewhat
> uncomfortable about adding an item for working on a solution; if people
> feel strongly about this, then maybe it would be reasonable to create 
> an
> information / BCP about mechansims to provide recovery after an outage.
>
> John
>

Delivery-date: Wed, 12 Jan 2005 07:05:50 +0000
Content-class: urn:content-classes:message
Subject: RE: comments about the draft charter
Date: Wed, 12 Jan 2005 09:02:43 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Marcelo,

> i would add an additional item here:
> 
> - A solution to establish new communications after an outage has 
> occurred that does not requires shim support from the non-multihomed 
> end of the communication. The wg will explore if such solution is also 
> useful when both ends support the shim.
> 
> imho this is relevant becuase it would provide an incremental 
> deployment model to the solution. If this is not provided, it is all or 
> nothing approach w.r.t. to fault tolerance i.e. if the other end 
> support the shim, then you get all the benefits but if the other end 
> does not supports the shim then no additional fault tolerance is 
> achieved.

Do you think that there is 'a' solution?  I have a feeling that there
are multiple solutions, at least for different scenarios.  I feel somewhat
uncomfortable about adding an item for working on a solution; if people
feel strongly about this, then maybe it would be reasonable to create an
information / BCP about mechansims to provide recovery after an outage.

John

Delivery-date: Tue, 11 Jan 2005 17:17:34 +0000
To: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: comments about the draft charter
Date: Tue, 11 Jan 2005 18:17:28 +0100

Hi all,

imho the draft looks good,
just some comments below...
>
> Site multiHoming by IPv6 interMediation (shim6)
>
> Description of Working Group:
>
> The shim6 WG is to produce specfifications for a complete IPv6 site
> multihoming solutions based on the architecture developed by the IETF
> multi6 WG. The multi6 WG was tasked with investigating solutions to
> the site multihoming problem that will allow the global routing system 
> to
> scale. The outcome of the multi6 WG is a specific network layer shim
> architecture for addressing and address handling of sites and nodes. 
> This
> includes switching to different locator addresses when connectivity 
> changes,
> but without the changes of address being visible to upper layers, 
> which see
> a fixed Upper Layer Identifier address (ULID).
>
> The shim6 WG is to complete this work with the required protocol 
> developments
> and complete the architecture and security analysis of the required 
> protocols.
>
> The background documents to be considered by the WG include:
>
>  RFC 3582
>  draft-ietf-multi6-things-to-think-about-01.txt
>  draft-ietf-multi6-multihoming-threats-03.txt
>
> The input documents that the WG will use as the basis for its design 
> are:
>
>  draft-huston-solution-stilltobewritten
>  draft-ietf-multi6-functional-dec-00.txt
>  draft-ietf-multi6-l3shim-00.txt [to be published shortly]
>  draft-ietf-multi6-failure-detection-00.txt [to be published shortly]
>  draft-ietf-multi6-hba-00.txt
>  draft-ietf-multi6-app-refer-00.txt
>
> [Comment - We specifically omitted the IPv4 document and Geoff's
> architecture analysis - we're assuming that will be replaced for
> the new WG by his solution architecture.]
>
> The shim6 WG is to submit, as standards track RFCs, specifications with
> enough details to allow full interoperable implementations of the shim
> layer appproach to multihoming as agreed on by the multi6 WG. These
> implementations should have the ability to take advantage of
> multihoming without adding to the growth of the global routing table,
> by using the aggregates already announced by their upstream providers.
>
> Since the solution requires state to be maintained at both ends of a
> communication, the protocol specification and the state machine will 
> be designed
> somewhat independently. Some state transitions may result from external
> events such as failure detection rather than from protocol events. 
> More work
> items and milestones might need to be added at a later date to
> complete all implementation details needed.
>
> In addition to the basic network layer shim solution, the shim6 WG
> is specifically chartered to do work on
>
>      o A solution for site exit router selection that works when each 
> ISP
>        uses ingress filtering, i.e. when the chosen site exit needs to 
> be
>        related to the source address chosen by the host. This solution
>        should work whether or not the peer site supports the shim6 
> protocol.
>

i would add an additional item here:

- A solution to establish new communications after an outage has 
occurred that does not requires shim support from the non-multihomed 
end of the communication. The wg will explore if such solution is also 
useful when both ends support the shim.

imho this is relevant becuase it would provide an incremental 
deployment model to the solution. If this is not provided, it is all or 
nothing approach w.r.t. to fault tolerance i.e. if the other end 
support the shim, then you get all the benefits but if the other end 
does not supports the shim then no additional fault tolerance is 
achieved.

>      o Explore how congestion control and other QoS and traffic 
> engineering
>        issues may interact with the use of multiple locators at both 
> ends.
>
>      o Investigate relationship between Upper Layer Identifiers (ULIDs)
>        and Unique Local Addresses.
>
>      o ICMP error demuxing for locator failure discovery.
>
>      o If necessary, develop and specify formats and structure for
>
>        - Cryptographically protected locators
>
>        - Carrying the flow label across the shim layer
>          defined in the multi6 architecture.
>
> The WG will consider whether the proposed model is exposed to
> any security threats in addition to those documented in
> draft-ietf-multi6-multihoming-threats-03.txt. In any case,
> the specifications must specifically refer to all applicable threats
> and describe how they are handled,  with the requirement being that
> the resulting solution not introduce any threats that make the
> security any less than in today's Internet.
>
> The WG will not consider items outside the above scope, such as
> interaction with mobility, transport level solutions, or alternative
> identifier formats.
> [What other topics are explicitly out of scope?]
>

enhanced security?
i mean, it is a non goal to provide better security than current 
single-homed ipv6 internet

regards, marcelo

> Milestones
>
>
> MAY 05    First draft of architectural and protocol document
> MAY 05    First draft on cryptographic locators, if required
> MAY 05    First draft on state managment
>
> SEP 05    WG last-call on architectural/protocol document
>
> NOV 05    Submit complete architectural/protocol document to IESG
> NOV 05    WG last-call on cryptographic locators, if required
>
> JAN 06    WG last-call on state management
> JAN 06    Submit draft on cryptographic locators to the IESG, if 
> required
>
> MAR 06    Submit draft on state management to the IESG

Delivery-date: Tue, 11 Jan 2005 15:21:57 +0000
Date: Tue, 11 Jan 2005 17:21:53 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: Re: Mailing list and draft charter for new multihoming BOF/WG

On Tue, 11 Jan 2005, Brian E Carpenter wrote:
> We will request a shim6 BOF at the next IETF, and also start the
> process of forming at WG. But first, we need your comments on
> the draft charter.

Two typos:

-The shim6 WG is to produce specfifications for a complete IPv6 site
-multihoming solutions based on the architecture developed by the IETF
+The shim6 WG is to produce specifications for a complete IPv6 site
+multihoming solution based on the architecture developed by the IETF

Major comment:

The text, again, makes a huge presumption that just by solving the 
connection survivability problems, we have a complete IPv6 site 
multihoming solution.  That may be true for certain kinds of sites, 
but this seems like a far fetch in general.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Mon, 10 Jan 2005 21:08:21 +0000
To: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: test 3
Date: Mon, 10 Jan 2005 22:09:27 +0100

test 3