Re: successful termination?

[Christian Vogt <[e-mail]>]

Dear all -

I apologize for getting involved in this interesting discussion only
now.  A few late comments from my side regarding the potential
continuation of the Shim6 working group:

In my opinion, this discussion has shown that there would be useful work
to do for a continued Shim6 working group.  In particular Marcelo's
proposal to evolve Shim6 as a locator-pair-providing substrate for
multi-path TCP is a very good idea.  One may even go a step further and
provide a similar service also for UDP-based applications.

A second potential future work topic is adding capabilities for network-
controlled traffic engineering to Shim6.  The (host-based) Six/One
protocol [1] could serve as a starting point for this.  Erik Nordmark,
too, had had ideas [2] for network-controlled traffic engineering.

[1] http://tools.ietf.org/html/draft-vogt-rrg-six-one-01
[2] http://tools.ietf.org/html/draft-nordmark-shim6-esd-01

A third potential future work topic is deployment facilitators for
Shim6.  This would include, in particular, a network-based variant of
Shim6, which would have at least the following two benefits:  First, it
could aid Shim6 adoption during the phase when (host-based) Shim6 is not
yet widely deployed.  Second, it would provide an option to keep multi-
homing control in the network, a feature that some network operators
apparently prefer as the discussion in early RRG days had shown.

One approach to design a network-based Shim6 variant would be to build
on Proxy Shim6 [3].  An alternative approach could be to build on
(network-based) Six/One Router [4].  As for the latter, it might be
possible to borrow techniques developed elsewhere in IETF:  As you may
know, the recently discussed NAT66 proposal is identical to Six/One
Router when used on only one side of a connection.  What is missing is
support for reverse translation when Six/One Router is used on both
sides of a connection, plus a distribution system for address mappings.
Support for reverse translation could be specified as an extension to
NAT66. Support for mapping distribution could be done as in Proxy Shim6.

[3] http://tools.ietf.org/html/draft-bagnulo-pshim6-02
[4] http://christianvogt.mailup.net/pub/2008/vogt-2008-six-one-router-design.pdf

- Christian




Envelope-to: [e-mail]
Delivery-date: Thu, 30 Apr 2009 02:42:24 +0000
Cc: Jari Arkko <[e-mail]>
Message-Id: <[e-mail]>
From: Christian Vogt <[e-mail]>
To: shim6 <[e-mail]>, [e-mail]
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: successful termination?
Date: Wed, 29 Apr 2009 19:40:02 -0700

Dear all -

I apologize for getting involved in this interesting discussion only
now.  A few late comments from my side regarding the potential
continuation of the Shim6 working group:

In my opinion, this discussion has shown that there would be useful work
to do for a continued Shim6 working group.  In particular Marcelo's
proposal to evolve Shim6 as a locator-pair-providing substrate for
multi-path TCP is a very good idea.  One may even go a step further and
provide a similar service also for UDP-based applications.

A second potential future work topic is adding capabilities for network-
controlled traffic engineering to Shim6.  The (host-based) Six/One
protocol [1] could serve as a starting point for this.  Erik Nordmark,
too, had had ideas [2] for network-controlled traffic engineering.

[1] http://tools.ietf.org/html/draft-vogt-rrg-six-one-01
[2] http://tools.ietf.org/html/draft-nordmark-shim6-esd-01

A third potential future work topic is deployment facilitators for
Shim6.  This would include, in particular, a network-based variant of
Shim6, which would have at least the following two benefits:  First, it
could aid Shim6 adoption during the phase when (host-based) Shim6 is not
yet widely deployed.  Second, it would provide an option to keep multi-
homing control in the network, a feature that some network operators
apparently prefer as the discussion in early RRG days had shown.

One approach to design a network-based Shim6 variant would be to build
on Proxy Shim6 [3].  An alternative approach could be to build on
(network-based) Six/One Router [4].  As for the latter, it might be
possible to borrow techniques developed elsewhere in IETF:  As you may
know, the recently discussed NAT66 proposal is identical to Six/One
Router when used on only one side of a connection.  What is missing is
support for reverse translation when Six/One Router is used on both
sides of a connection, plus a distribution system for address mappings.
Support for reverse translation could be specified as an extension to
NAT66. Support for mapping distribution could be done as in Proxy Shim6.

[3] http://tools.ietf.org/html/draft-bagnulo-pshim6-02
[4] http://christianvogt.mailup.net/pub/2008/vogt-2008-six-one-router-design.pdf

- Christian





Envelope-to: [e-mail]
Delivery-date: Tue, 21 Apr 2009 04:45:01 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZqaUL5JU14pKMowFDgI5q0b+TjKmghPn088n7yBEDoQ=; b=feMCgIuKN2Sm+SIHUQxfRpagxQBvUUaPTq/i1U5RpS4jPoRCLTr9vzuqHyDAVMtoEq fcHPJnLOb64nu8oXB36/r+M7FQU9ImRZS80dzH6R4EfMoSajEBBbhMsk/dAOc7yydl1A 6XFCBvDxy0bM/YwAdu+yeHtE+sY43tkjsak+Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=cWr3HWgdM2dAnZmJ3d+axBzVsDYgiTSIyUWY045XXn0CLAtSnNYfsOc2VBRKiKX05v p6izkrTUOKrXU3XlJbOb5S+4ge4rSvl8U3/sdcsjpzL2sowNTwkthn2nA5BtvYADhK94 MnaECHhiI11F9B/N/Fg0FjM/1dqPwNGQm9Nx8=
Message-ID: <[e-mail]>
Date: Tue, 21 Apr 2009 16:42:48 +1200
From: Brian E Carpenter <[e-mail]>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: marcelo bagnulo braun <[e-mail]>
CC: Jari Arkko <[e-mail]>, shim6 <[e-mail]>
Subject: Re: successful termination?
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

(catching up)

On 2009-04-08 02:40, marcelo bagnulo braun wrote:
> Hi Brian,
>=20
> a couple of comments.
>=20
> Brian E Carpenter escribi=C3=B3:
>> Jari,
>>
>> If I look at both Geoff's and Olivier's (relayed) comments,
>> it's clear to me that there is work to be done.
>>
>> I agree that the address-pair selection issue is broader
>> than just shim6 (and is related to other things, such as
>> egress router selection).
> note that shim6 need to do both ULID pair selection and locator pair
> selection (after a failure) and maybe the selection is different for
> these cases (the typical example is that when used in conjunction with
> MIPv6, probably the CoA is better as a locator  while the HoA is better=

> as a ULID. OTOH, maybe in general the option is not so different.
>=20
> In the scope of 6man, they select an address pair that will play both
> roles, so the criteria for selection maybe potentially different.
>=20
>>  But there may still be some work
>> do here, on 'SHIM6 Requirements for Address Pair Selection',
>> even if the actual specification belongs in 6MAN.
>>
>> I agree that there is commonality of interest with multipath
>> transport, but it's far from clear to me that there is
>> actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
>> and multipath transport sure seems like a layer 4 shim,
>> which was a direction that MULTI6 explicitly choose not to
>> follow up.
>>  =20
> I think the story here is something like this.
> Suppose we want to do multipath TCP.
> One option is to do it a la SCTP, where the MPTCP exchanges all the
> alternative addresses and includes different source dest address pairs
> to select the different paths.
> Now, the point that can be made is that shim6 already handles the
> locator pair management which is far from trivial, espcially when
> considering the security issues. So, why not let MPTCP to leverage on
> shim6 do do the locator pair management and let the MPTCP to actually
> decide which segments to send through each locator pair?
>=20
> I mean, we can use a comibation of the shim6 API plus the forking
> capabiltiies and maybe some new extension so that the MPTCP is not awar=
e
> of the actual address pairs, but knows that the underlying shim6 layer
> has path diversity. So MPTCP simply will add some tags to state that
> some segments should fly over one path and some other segments though a=
n
> alternative path.
> So, in this case, each layer does what i does best. Shim6 handles the
> multiple locator pairs, while MPTCP distribute the segments through the=

> different pahts based on congestion.
>=20
> Makes sense?
>=20
> If so, then we may need to do some work so that both mechanisms interac=
t
> reasonably.

Yes. It sounds like a more developed API is needed, so that MPTCP can
use what shim6 and LEAP have already discovered. That's different from
SCTP, where we just want to switch shim6 off.

    Brian
>=20
>=20
>> That said, it's clear that the union of Geoff's and Olivier's
>> messages add up to a program of work, basically to find out if
>> SHIM6 is deployable and useful. I think it would be a shame
>> to pause before doing that.
>>
>>  =20
> agree
>=20
> Regards, marcelo
>=20
>=20
>>   Brian




Envelope-to: [e-mail]
Delivery-date: Sun, 12 Apr 2009 21:25:30 +0000
Cc: John Ronan <[e-mail]>
Message-Id: <[e-mail]>
From: Geoff Huston <[e-mail]>
To: shim6 <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Shom6 Implementation report
Date: Mon, 13 Apr 2009 07:23:33 +1000

Due to some strange behaviour of the shim6 mail list manager John =20
Ronan <[e-mail]> was unable to send the following to the shim6 =20=

list


Geoff



Begin forwarded message:

> From: John Ronan <[e-mail]>
> Date: 12 April 2009 7:27:16 PM

> Hi
>
> The text of what I send was as follows
> --
> Hi,
>
> Recently TSSG has been doing some work based around the Shim6 =20
> protocol (in the FP7 Efipsans http://www.efipsans.org/ Project). The =20=

> Shim6 implementation used is S=E9bastien Barr=E9's LinShim6.
> The latest version of which is always available at the LinShim6 =
(http://inl.info.ucl.ac.be/LinShim6=20
> ) home page.
>
> We have taken a bare set-up we have been using in the lab, and made =20=

> a Ubuntu Live CD with it.
>
> It is available at http://scott.tssg.org/shim6/ and I've submitted =20
> it to the Sixxs BitTorrent Tracker.
>
> Also, TSSG has a dual-homed shim6 enabled machine =
(http://shim6.lab.tssg.org=20
> ) out on the Internet for anyone to test against.
>
> Regards
> John






Envelope-to: [e-mail]
Delivery-date: Sun, 12 Apr 2009 03:03:00 +0000
Message-ID: <[e-mail]>
To: Jari Arkko <[e-mail]>
CC: shim6 <[e-mail]>
Subject: Re: successful termination?
Date: Tue, 7 Apr 2009 11:42:27 -0400
From: Thomas Narten <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: None (TK5-EXGWY-E801.partners.extranet.microsoft.com: [e-mail] does not designate permitted sender hosts)

> You've sent a lot of good input. How do the people who have not said 
> anything yet feel? Please speak up!

While there may be work that would be nice to have, is there actual
energy to do that work? I worry about that aspect.

Thomas





Envelope-to: [e-mail]
Delivery-date: Fri, 10 Apr 2009 17:52:54 +0000
Message-ID: <006c01c9b9fc$83e9bb00$0601a8c0@allison>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Jari Arkko" <[e-mail]>, "shim6" <[e-mail]>
Subject: Re: successful termination?
Date: Fri, 10 Apr 2009 18:14:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Tracking the RRG list, shim6 crops up quite often and often seems little
understood, or understood as it was rather than as it is.

So, I think it important that there is an obvious place for queries and issues
to be raised as and when needed, even if there has not been much evidence of
that so far, and this I see as an argument for keeping this list open, and
keeping it alive.

Yes, lack of group energy is a counter-argument.

Tom Petch


----- Original Message -----
From: "Jari Arkko" <[e-mail]>
To: "shim6" <[e-mail]>
Sent: Monday, April 06, 2009 1:30 PM
Subject: Re: successful termination?


> You've sent a lot of good input. How do the people who have not said
> anything yet feel? Please speak up!
>
> Jari
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 08 Apr 2009 12:55:31 +0000
Message-ID: <[e-mail]>
Date: Tue, 07 Apr 2009 16:40:49 +0200
From: marcelo bagnulo braun <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Brian E Carpenter <[e-mail]>
CC: Jari Arkko <[e-mail]>, shim6 <[e-mail]>
Subject: Re: successful termination?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Brian,

a couple of comments.

Brian E Carpenter escribió:
> Jari,
>
> If I look at both Geoff's and Olivier's (relayed) comments,
> it's clear to me that there is work to be done.
>
> I agree that the address-pair selection issue is broader
> than just shim6 (and is related to other things, such as
> egress router selection).
note that shim6 need to do both ULID pair selection and locator pair
selection (after a failure) and maybe the selection is different for
these cases (the typical example is that when used in conjunction with
MIPv6, probably the CoA is better as a locator  while the HoA is better
as a ULID. OTOH, maybe in general the option is not so different.

In the scope of 6man, they select an address pair that will play both
roles, so the criteria for selection maybe potentially different.

>  But there may still be some work
> do here, on 'SHIM6 Requirements for Address Pair Selection',
> even if the actual specification belongs in 6MAN.
>
> I agree that there is commonality of interest with multipath
> transport, but it's far from clear to me that there is
> actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
> and multipath transport sure seems like a layer 4 shim,
> which was a direction that MULTI6 explicitly choose not to
> follow up.
>   
I think the story here is something like this.
Suppose we want to do multipath TCP.
One option is to do it a la SCTP, where the MPTCP exchanges all the
alternative addresses and includes different source dest address pairs
to select the different paths.
Now, the point that can be made is that shim6 already handles the
locator pair management which is far from trivial, espcially when
considering the security issues. So, why not let MPTCP to leverage on
shim6 do do the locator pair management and let the MPTCP to actually
decide which segments to send through each locator pair?

I mean, we can use a comibation of the shim6 API plus the forking
capabiltiies and maybe some new extension so that the MPTCP is not aware
of the actual address pairs, but knows that the underlying shim6 layer
has path diversity. So MPTCP simply will add some tags to state that
some segments should fly over one path and some other segments though an
alternative path.
So, in this case, each layer does what i does best. Shim6 handles the
multiple locator pairs, while MPTCP distribute the segments through the
different pahts based on congestion.

Makes sense?

If so, then we may need to do some work so that both mechanisms interact
reasonably.


> That said, it's clear that the union of Geoff's and Olivier's
> messages add up to a program of work, basically to find out if
> SHIM6 is deployable and useful. I think it would be a shame
> to pause before doing that.
>
>   
agree

Regards, marcelo


>   Brian
>
>
>   







Envelope-to: [e-mail]
Delivery-date: Tue, 07 Apr 2009 15:44:25 +0000
Message-Id: <[e-mail]>
To: Jari Arkko <[e-mail]>
cc: shim6 <[e-mail]>
Subject: Re: successful termination?
Date: Tue, 07 Apr 2009 11:42:27 -0400
From: Thomas Narten <[e-mail]>

> You've sent a lot of good input. How do the people who have not said 
> anything yet feel? Please speak up!

While there may be work that would be nice to have, is there actual
energy to do that work? I worry about that aspect.

Thomas



Envelope-to: [e-mail]
Delivery-date: Tue, 07 Apr 2009 06:06:02 +0000
Cc: shim6 <[e-mail]>
Message-Id: <[e-mail]>
From: Lixia Zhang <[e-mail]>
To: Brian E Carpenter <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: successful termination?
Date: Mon, 6 Apr 2009 23:03:45 -0700

On Apr 5, 2009, at 2:14 PM, Brian E Carpenter wrote:
> Hi Lixia,
>
> On 2009-04-05 16:53, Lixia Zhang wrote:
>>
>> On Apr 4, 2009, at 6:58 PM, Brian E Carpenter wrote:
>>
>>> Jari,
>>>
>>> If I look at both Geoff's and Olivier's (relayed) comments,
>>> it's clear to me that there is work to be done.
>>>
>>> I agree that the address-pair selection issue is broader
>>> than just shim6 (and is related to other things, such as
>>> egress router selection). But there may still be some work
>>> do here, on 'SHIM6 Requirements for Address Pair Selection',
>>> even if the actual specification belongs in 6MAN.
>>>
>>> I agree that there is commonality of interest with multipath
>>> transport, but it's far from clear to me that there is
>>> actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
>>> and multipath transport sure seems like a layer 4 shim,
>>> which was a direction that MULTI6 explicitly choose not to
>>> follow up.
>>
>> I wondered how to interpret the phrase "actual overlap" in the  
>> above...
>> yes one solution works at transport and the other works at layer 3,  
>> so
>> yes in terms of layers they are not at the same place.
>> But in terms of goals, would you agree that their goals overlap?
>
> Sort of. But the shim6 goals were clearly aimed at RFC3582,
> whereas I understand the goals of multipath transport to be
> more aimed at load sharing, with failover as a secondary effect.
> However, the mechanisms are so different that I don't see anything
> to gain by sticking them in the same room at the IETF.

Personally I see both having a goal of utilizing multiple paths,  
whether one at a time or multiple in parallel (isn't the former a  
special case of the later).
I would not make load sharing and failover as two necessarily  
separated issues. I believe the two are closely related to each other.  
For example multipath-TCP detect path failures through its  
simultaneous transmission over multiple paths, and conversely this  
simultaneous transmission over multiple paths makes its performance  
less dependent on prompt detection of the failure of any single path.
(And I have not mentioned the benefit of utilizing TCP's built-in  
feedback look for failure detection instead of pure overhead probing  
packets...)

Lixia



Envelope-to: [e-mail]
Delivery-date: Mon, 06 Apr 2009 12:16:14 +0000
Message-ID: <[e-mail]>
Date: Mon, 06 Apr 2009 14:30:54 +0300
From: Jari Arkko <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: shim6 <[e-mail]>
Subject: Re: successful termination?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

You've sent a lot of good input. How do the people who have not said 
anything yet feel? Please speak up!

Jari




Envelope-to: [e-mail]
Delivery-date: Sun, 05 Apr 2009 22:20:28 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yV4VeJgizuyKLL9oATmkSdlRN0Sx1/A4PWE3tL6NWxU=; b=ecYYdBkA6PHzvXmPb5wRWb6151PHX7w5dq5YMDO/9ti5oSAdCcqN9iywZSxpRexkng xGkCOzcArqzUI9yFqHJ5VU4gn1Pyhw9rCZzmbHgeM8Vro+zf470CElaLBuGT85EVy7EY cbVeIHVx2xlZCUWbhEaGJN2fdQjsP4I2y9xgg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=L9Pc+ywO2su9otMhwNHUw2cW3WUunvPaTaHo90qlaNlA94viKgn8+dVA+B4gn8E56S fNoFib4UOjN9IrWzB3DTh0Xx6Ii6L8+i7+HQUVCb8G8pWI6M9sIiNIICmljMeb2JsZP9 dYBHbFGNofqIAXjeHQbMOIy8IIC2n5vEKjGXs=
Message-ID: <[e-mail]>
Date: Mon, 06 Apr 2009 10:12:10 +1200
From: Brian E Carpenter <[e-mail]>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Joel M. Halpern" <[e-mail]>
CC: shim6-wg <[e-mail]>
Subject: Handling multipath [Re: successful termination?]
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Joel,

I thought about that, but forgot to mention it. Thanks for the
reminder.

The same issue arises for SCTP. That's discussed
in draft-ietf-shim6-applicability section 5.3, which could
be expanded appropriately. And the SHIM_DONTSHIM option
in draft-ietf-shim6-multihome-shim-api probably solves the problem.

Of course, a more intimate blending of layers 3 and 4 might
be more optimal, but that seems like a research issue at the
moment.

   Brian

On 2009-04-06 09:50, Joel M. Halpern wrote:
> Actually, there is one reason for possibly sticking shim6 and
> multi-pathing in the same room for a little while.  (Not for making them
> the same working group.)
> As currently defined, shim6 will hide from multi-pathing the very
> information and control it wants.  This seems counter-productive.  A bit
> of cooperation ought to allow us to find a way to have the two bettter
> co-exist.
> 
> Yours,
> Joel
> 
> Brian E Carpenter wrote:
>> Hi Lixia,
>>
>> On 2009-04-05 16:53, Lixia Zhang wrote:
>>> On Apr 4, 2009, at 6:58 PM, Brian E Carpenter wrote:
>>>
>>>> Jari,
>>>>
>>>> If I look at both Geoff's and Olivier's (relayed) comments,
>>>> it's clear to me that there is work to be done.
>>>>
>>>> I agree that the address-pair selection issue is broader
>>>> than just shim6 (and is related to other things, such as
>>>> egress router selection). But there may still be some work
>>>> do here, on 'SHIM6 Requirements for Address Pair Selection',
>>>> even if the actual specification belongs in 6MAN.
>>>>
>>>> I agree that there is commonality of interest with multipath
>>>> transport, but it's far from clear to me that there is
>>>> actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
>>>> and multipath transport sure seems like a layer 4 shim,
>>>> which was a direction that MULTI6 explicitly choose not to
>>>> follow up.
>>> I wondered how to interpret the phrase "actual overlap" in the above...
>>> yes one solution works at transport and the other works at layer 3, so
>>> yes in terms of layers they are not at the same place.
>>> But in terms of goals, would you agree that their goals overlap?
>>
>> Sort of. But the shim6 goals were clearly aimed at RFC3582,
>> whereas I understand the goals of multipath transport to be
>> more aimed at load sharing, with failover as a secondary effect.
>> However, the mechanisms are so different that I don't see anything
>> to gain by sticking them in the same room at the IETF.
>>
>>>> That said, it's clear that the union of Geoff's and Olivier's
>>>> messages add up to a program of work, basically to find out if
>>>> SHIM6 is deployable and useful. I think it would be a shame
>>>> to pause before doing that.
>>> to see if I got it right: are you suggesting that we should first "find
>>> out if SHIM6 is deployable and useful", before making the decision on
>>> whether the WG should go dormant?
>>
>> No, I'm suggesting we should recharter the WG now, with the items
>> that Geoff and Olivier describe, most of which speak to making
>> shim6 (more) useful. Actual deployment work items would fall
>> under v6ops, I suppose.
>>
>>    Brian
>>
>>> if so, how does one go about to find that out?
>>> no matter how, I suppose this could be done quick?
>>>
>>> Lixia
>>>
>>
>>
> 



Envelope-to: [e-mail]
Delivery-date: Sun, 05 Apr 2009 21:59:07 +0000
Message-ID: <[e-mail]>
Date: Sun, 05 Apr 2009 17:50:07 -0400
From: "Joel M. Halpern" <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Brian E Carpenter <[e-mail]>
CC: Lixia Zhang <[e-mail]>, shim6 <[e-mail]>
Subject: Re: successful termination?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Actually, there is one reason for possibly sticking shim6 and 
multi-pathing in the same room for a little while.  (Not for making them 
the same working group.)
As currently defined, shim6 will hide from multi-pathing the very 
information and control it wants.  This seems counter-productive.  A bit 
of cooperation ought to allow us to find a way to have the two bettter 
co-exist.

Yours,
Joel

Brian E Carpenter wrote:
> Hi Lixia,
> 
> On 2009-04-05 16:53, Lixia Zhang wrote:
>> On Apr 4, 2009, at 6:58 PM, Brian E Carpenter wrote:
>>
>>> Jari,
>>>
>>> If I look at both Geoff's and Olivier's (relayed) comments,
>>> it's clear to me that there is work to be done.
>>>
>>> I agree that the address-pair selection issue is broader
>>> than just shim6 (and is related to other things, such as
>>> egress router selection). But there may still be some work
>>> do here, on 'SHIM6 Requirements for Address Pair Selection',
>>> even if the actual specification belongs in 6MAN.
>>>
>>> I agree that there is commonality of interest with multipath
>>> transport, but it's far from clear to me that there is
>>> actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
>>> and multipath transport sure seems like a layer 4 shim,
>>> which was a direction that MULTI6 explicitly choose not to
>>> follow up.
>> I wondered how to interpret the phrase "actual overlap" in the above...
>> yes one solution works at transport and the other works at layer 3, so
>> yes in terms of layers they are not at the same place.
>> But in terms of goals, would you agree that their goals overlap?
> 
> Sort of. But the shim6 goals were clearly aimed at RFC3582,
> whereas I understand the goals of multipath transport to be
> more aimed at load sharing, with failover as a secondary effect.
> However, the mechanisms are so different that I don't see anything
> to gain by sticking them in the same room at the IETF.
> 
>>> That said, it's clear that the union of Geoff's and Olivier's
>>> messages add up to a program of work, basically to find out if
>>> SHIM6 is deployable and useful. I think it would be a shame
>>> to pause before doing that.
>> to see if I got it right: are you suggesting that we should first "find
>> out if SHIM6 is deployable and useful", before making the decision on
>> whether the WG should go dormant?
> 
> No, I'm suggesting we should recharter the WG now, with the items
> that Geoff and Olivier describe, most of which speak to making
> shim6 (more) useful. Actual deployment work items would fall
> under v6ops, I suppose.
> 
>    Brian
> 
>> if so, how does one go about to find that out?
>> no matter how, I suppose this could be done quick?
>>
>> Lixia
>>
> 
> 



Envelope-to: [e-mail]
Delivery-date: Sun, 05 Apr 2009 21:34:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1yfr7qcfyD2s4uhj1MYucPyoExNTSuOaK7FJ30Z8KbU=; b=I9rTjCUpPRQIEUmrdVq6iOlVvGNHMKf5eyM31HCt3L43rC3BO0uro8TK3Y7/BP4oGP DBU/pgwcZd0WLSw7REZCZL4uk06Trgxwnnd1fpgRdwS7SM66NkrQa2c3TeKQxMfUtOhW SP96CVHWkAJix/0bdkQQsui7azsNoHa+UPvHM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=xRiewjx9FNh3Xr7aPC5K3vpEWg54cV7G4BlFMU42d8bqPnAGJ/Rfn0QeK8beFjmvAu GuOWosBJt4r5HIs4hV9X/TKgfEmRhQIIQOY3sjmiZK2YdCh1Qx8MGhXs7MoJK2tDYeyb /s20Hh6YN9q51jaVyyDrIHvBrkNdfVFiyjuXk=
Message-ID: <[e-mail]>
Date: Mon, 06 Apr 2009 09:14:26 +1200
From: Brian E Carpenter <[e-mail]>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Lixia Zhang <[e-mail]>
CC: shim6 <[e-mail]>
Subject: Re: successful termination?
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Lixia,

On 2009-04-05 16:53, Lixia Zhang wrote:
> 
> On Apr 4, 2009, at 6:58 PM, Brian E Carpenter wrote:
> 
>> Jari,
>>
>> If I look at both Geoff's and Olivier's (relayed) comments,
>> it's clear to me that there is work to be done.
>>
>> I agree that the address-pair selection issue is broader
>> than just shim6 (and is related to other things, such as
>> egress router selection). But there may still be some work
>> do here, on 'SHIM6 Requirements for Address Pair Selection',
>> even if the actual specification belongs in 6MAN.
>>
>> I agree that there is commonality of interest with multipath
>> transport, but it's far from clear to me that there is
>> actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
>> and multipath transport sure seems like a layer 4 shim,
>> which was a direction that MULTI6 explicitly choose not to
>> follow up.
> 
> I wondered how to interpret the phrase "actual overlap" in the above...
> yes one solution works at transport and the other works at layer 3, so
> yes in terms of layers they are not at the same place.
> But in terms of goals, would you agree that their goals overlap?

Sort of. But the shim6 goals were clearly aimed at RFC3582,
whereas I understand the goals of multipath transport to be
more aimed at load sharing, with failover as a secondary effect.
However, the mechanisms are so different that I don't see anything
to gain by sticking them in the same room at the IETF.

>> That said, it's clear that the union of Geoff's and Olivier's
>> messages add up to a program of work, basically to find out if
>> SHIM6 is deployable and useful. I think it would be a shame
>> to pause before doing that.
> 
> to see if I got it right: are you suggesting that we should first "find
> out if SHIM6 is deployable and useful", before making the decision on
> whether the WG should go dormant?

No, I'm suggesting we should recharter the WG now, with the items
that Geoff and Olivier describe, most of which speak to making
shim6 (more) useful. Actual deployment work items would fall
under v6ops, I suppose.

   Brian

> 
> if so, how does one go about to find that out?
> no matter how, I suppose this could be done quick?
> 
> Lixia
> 



Envelope-to: [e-mail]
Delivery-date: Sun, 05 Apr 2009 05:03:07 +0000
Cc: shim6 <[e-mail]>
Message-Id: <[e-mail]>
From: Lixia Zhang <[e-mail]>
To: Brian E Carpenter <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: successful termination?
Date: Sat, 4 Apr 2009 21:53:24 -0700

On Apr 4, 2009, at 6:58 PM, Brian E Carpenter wrote:

> Jari,
>
> If I look at both Geoff's and Olivier's (relayed) comments,
> it's clear to me that there is work to be done.
>
> I agree that the address-pair selection issue is broader
> than just shim6 (and is related to other things, such as
> egress router selection). But there may still be some work
> do here, on 'SHIM6 Requirements for Address Pair Selection',
> even if the actual specification belongs in 6MAN.
>
> I agree that there is commonality of interest with multipath
> transport, but it's far from clear to me that there is
> actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
> and multipath transport sure seems like a layer 4 shim,
> which was a direction that MULTI6 explicitly choose not to
> follow up.

I wondered how to interpret the phrase "actual overlap" in the above...
yes one solution works at transport and the other works at layer 3, so  
yes in terms of layers they are not at the same place.
But in terms of goals, would you agree that their goals overlap?

> That said, it's clear that the union of Geoff's and Olivier's
> messages add up to a program of work, basically to find out if
> SHIM6 is deployable and useful. I think it would be a shame
> to pause before doing that.

to see if I got it right: are you suggesting that we should first  
"find out if SHIM6 is deployable and useful", before making the  
decision on whether the WG should go dormant?

if so, how does one go about to find that out?
no matter how, I suppose this could be done quick?

Lixia



Envelope-to: [e-mail]
Delivery-date: Sun, 05 Apr 2009 02:09:32 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=sY+c/P0ce1/HP7vjHVJluvSM4/pfNgG+zroWk49DTmo=; b=wwhdUg+x2XxyRqFBYFeLRAqGDOJgqVpnjABZpRFKJoGfA5/WwSjHTPbIUuuRp8Fc5P JLKlasxzZmLB4Yz32si+gLkJNPyr9zlNkrjEqv9hMsCf9WuIUiAxFu+jP9WxqqSBEUmy 2wrWPqGwR64jbSHPpAEedVsfEoDUhn9+6WcMo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=QBq3SeikqNrq3gVf9ujOUJ7k2cIc+iQzlddipxhUtAexVgxpG3HDK1AqAHpOtojd1P qFeEkPC5uTcBkF0puhcYfNrnpMy8x1bYnV8sHyZxU5uDshchiskt6rntQMq3kpn5We9U 6W5G7QTQXlc//zjcbYQWmB5caevonWWGgkdow=
Message-ID: <[e-mail]>
Date: Sun, 05 Apr 2009 13:58:33 +1200
From: Brian E Carpenter <[e-mail]>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Jari Arkko <[e-mail]>
CC: shim6 <[e-mail]>
Subject: Re: successful termination?
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Jari,

If I look at both Geoff's and Olivier's (relayed) comments,
it's clear to me that there is work to be done.

I agree that the address-pair selection issue is broader
than just shim6 (and is related to other things, such as
egress router selection). But there may still be some work
do here, on 'SHIM6 Requirements for Address Pair Selection',
even if the actual specification belongs in 6MAN.

I agree that there is commonality of interest with multipath
transport, but it's far from clear to me that there is
actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
and multipath transport sure seems like a layer 4 shim,
which was a direction that MULTI6 explicitly choose not to
follow up.

That said, it's clear that the union of Geoff's and Olivier's
messages add up to a program of work, basically to find out if
SHIM6 is deployable and useful. I think it would be a shame
to pause before doing that.

  Brian



Envelope-to: [e-mail]
Delivery-date: Fri, 03 Apr 2009 22:08:01 +0000
Cc: Jari Arkko <[e-mail]>, shim6 <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Fred Baker <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: successful termination?
Date: Fri, 3 Apr 2009 15:06:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2639; t=1238796420; x=1239660420; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Fred=20Baker=20<[e-mail]> |Subject:=20Re=3A=20successful=20termination? |Sender:=20; bh=rhFMVW7DMLQxGtVSAeNtEk0aLlA1cpoblZtUWgQkMAk=; b=bfET4A3h9VCD+5Txu3vOUyEVesF4s3RqvxZxRxlj4cVZlsSYtD8Hhlk/vY XVAyyERYzjaCQNPWBn4UF5jwfU+HFZmHp123PzK1eeLNNgxgGjC/3HoAwYXD hbnMIktuxI;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );

On Apr 3, 2009, at 12:42 PM, Olivier Bonaventure wrote:

> Fred,
>
>> In my opinion, there are two rational outcomes. One is to close the
>> working group pending deployment reports,
>
> See http://tools.ietf.org/html/draft-barre-shim6-impl-02
> for a detailed implementation report about Linshim6
>
>> and recharter to address issues that arise in that deployment.
>
> We have mainly used this implementation in lab environment. If readers
> of this list are willing to deploy this implementation, we would be  
> very
> interested in participating in the tests.

That's pretty common for protocols in development. What I am  
suggesting is that the working group reconvene when there is  
operational deployment and issues resulting from it.

>> The other is the locator pair
>> issue, which should IMHO be conjoined with the RFC 3484 update  
>> ongoing
>> in 6man. I would ask 6man to pick up the locator pair question.
>
> I think that alto could play an interesting role for shim6 as well,
> although I'm not sure that this fits entirely in the restricted alto  
> charter

My line of reasoning is similarity of objectives. Shim6 would like the  
originating system to know what address pair to use, knowing that a  
choice of address pair at some level determines a route - ingress  
filtering may result in traffic loss if the wrong source address is  
used, and the RTT through one path is different than another.

A case in point that one of the shim6 chairs will recall was discussed  
on the IAB perhaps a decade ago. At my request, he simulated the  
effect of alternative address pair choices by pinging two different  
addresses in Singapore from his office in Canberra. One route was  
relatively direct and had an RTT on the order of 80 ms; the other  
route went via the US west coast, and had an RTT on the order of 600  
ms. Assuming those were two addresses for the same server (they  
weren't, but that's another discussion), choice of address pair would  
have dramatic effects on the service as perceived by the user. And as  
it turns out, the lower RTT path isn't necessarily the path through  
the shortest number of AS's or etc. a list of rules based on prefix  
matching has value but isn't the final result.

3484bis would like to know how to select a source address given a  
destination address. If there is only one destination address, that is  
exactly the same problem, and if there are multiple destination  
addresses, it only addresses part of the problem.

So I would like, under whatever aegis, for the two efforts to  
cooperate or merge.



Envelope-to: [e-mail]
Delivery-date: Fri, 03 Apr 2009 20:16:24 +0000
Message-ID: <[e-mail]>
Date: Fri, 03 Apr 2009 22:14:58 +0200
From: Jari Arkko <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: [e-mail]
CC: shim6 <[e-mail]>, =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[e-mail]>
Subject: Re: successful termination?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Thanks -- this was very useful input.

Jari

Olivier Bonaventure wrote:
> Jari,
>   
>> 4. Do something else that is important for Shim6. What?
>>
>> We would like to move forward with this in a couple of weeks. The WG
>> will either be closed or rechartered. Let us know if you are interested
>> and if so, what you believe should be done.
>>     
>
> As you know, Sébastien Barré has written an implementation of shim6 that
> is fairly complete and integrated in the Linux kernel. If there are
> other implementations being developped, it would be interesting to do
> interoperability tests among them to check that all implementors have
> interpreted the shim6 specifications in the same manner.
>
> Concerning the additional work that could be useful to pursue the
> development of shim6, I would suggest the following :
>
> - document the issues in supporting shim6 in firewalls. shim6 creates
> new challenges for firewall vendors and documenting them would be useful
>
> - network operators have argued that one drawback of shim6 from their
> point of view is that host-based multihoming gives fewer tools for
> network operators to engineer their network. I would say that operators
> can have *different* tools to engineer their network. The solution being
> developped within the ALTO WG could serve as a basis for a technique to
> allow operators to influence the selection of the addresses by hosts in
> order to traffic engineer their network. This could be considered as an
> extension of the locator-pair-selection work
>
> - another possibility could be to look at the interactions between shim6
> and multiple tcp which have been discussed recently
>
>
> Olivier
>
>
>   




Envelope-to: [e-mail]
Delivery-date: Fri, 03 Apr 2009 06:29:10 +0000
Message-ID: <[e-mail]>
Date: Fri, 03 Apr 2009 08:01:52 +0200
From: Jari Arkko <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: Geoff Huston <[e-mail]>
CC: shim6 <[e-mail]>, [e-mail]
Subject: Re: successful termination? Or interest in resumption of the work?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Geoff,

> There were the following drafts that are still WG documents at this 
> stage:
>
> - the outstanding applicability draft 
> (draft-ietf-shim6-applicability-03.txt)
>
> - the locator pair selection draft 
> (draft-ietf-shim6-locator-pair-selection-04.txt)
>
> - the API draft (draft-ietf-shim6-multihome-shim-api-07.txt)
>
> There may be work on Illitsch's proposal to perform a faster algorithm 
> in the failure detection / reachability area (he had a draft on this I 
> recall)
>
> There were areas about ULP / SHIM signalling to allow greater levels 
> of control in an instance of a ULP and greater levels of feedback from 
> the SHIM layer.

Right.

> There appears to be interest in multipath TCP, andf the possible 
> coupling of multipath TCP to Shim6

My understanding is that there are folks interested in pursuing 
multipath TCP, but they will have their own BOF, probably in Stockholm.

> There was interest in proxy shim6 and a draft on the topic 
> (draft-nordmark-shim6-esd-01.txt)

Right.

> I must point out that the past two years has been spent largely 
> waiting for the documents to clear the IESG, and the lack of work in 
> this WG in the interim was due to a decision to await these core 
> documents to be cleared through the IESG before picking up more work.

Indeed.

> So if there is interst in picking up this work now, it would be good 
> to hear from intersted individuals in response to Jari's call.

Yes.

Jari




Envelope-to: [e-mail]
Delivery-date: Thu, 02 Apr 2009 21:37:56 +0000
Cc: shim6 <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Geoff Huston <[e-mail]>
To: Jari Arkko <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: successful termination? Or interest in resumption of the work?
Date: Fri, 3 Apr 2009 08:37:14 +1100

On 03/04/2009, at 7:37 AM, Jari Arkko wrote:

> Folks,
>
> As you may have noticed, all three base Shim6 documents have now  
> been approved after extensive edits from IESG reviews. This is  
> obviously a very happy outcome even if it took a long time. Thank  
> you everyone who was involved in making this happen!
>
> Last week I when I met the chairs and lead authors I asked what they  
> believe should happen next. A lively discussion followed about the  
> status of the technology, the WG, and its few remaining WG  
> documents. But our main conclusion was that the working group  
> participants should tell us what they have in mind.
>
> Here's a couple of different alternatives:
>
> 1. Declare success and close the WG. The most important work now is  
> implementation, testing, and deployments. The WG is not needed at  
> this moment, and if it will later be needed, it is easy to create a  
> maintenance WG. Or if a new effort for some bigger new piece of  
> functionality is needed, the proper way to do that is through a BOF  
> anyway. Question: how many implementations exist? Which ones are  
> worked on actively? Is there any deployment or trial experience to  
> report?
>
> 2. Put the WG into sleep for a year or two, and return when there's  
> additional experience.
>
> 3. Work on the most important one(s) of the remaining WG documents  
> (locator-pair-selection, api, applicability). Which one? Is there  
> energy to do the work, including WG participants doing reviews,  
> commenting on issues, etc?
>
> 4. Do something else that is important for Shim6. What?
>
> We would like to move forward with this in a couple of weeks. The WG  
> will either be closed or rechartered. Let us know if you are  
> interested and if so, what you believe should be done.
>
>


 From my notes of that meeting with the AD I have:

There were the following drafts that are still WG documents at this  
stage:

- the outstanding applicability draft (draft-ietf-shim6- 
applicability-03.txt)

- the locator pair selection draft (draft-ietf-shim6-locator-pair- 
selection-04.txt)

- the API draft (draft-ietf-shim6-multihome-shim-api-07.txt)

There may be work on Illitsch's proposal to perform a faster algorithm  
in the failure detection / reachability area (he had a draft on this I  
recall)

There were areas about ULP / SHIM signalling to allow greater levels  
of control in an instance of a ULP and greater levels of feedback from  
the SHIM layer.

There appears to be interest in multipath TCP, andf the possible  
coupling of multipath TCP to Shim6

There was interest in proxy shim6 and a draft on the topic (draft- 
nordmark-shim6-esd-01.txt)

I must point out that the past two years has been spent largely  
waiting for the documents to clear the IESG, and the lack of work in  
this WG in the interim was due to a decision to await these core  
documents to be cleared through the IESG before picking up more work.

So if there is interst in picking up this work now, it would be good  
to hear from intersted individuals in response to Jari's call.


thanks,

   Geoff






Envelope-to: [e-mail]
Delivery-date: Thu, 02 Apr 2009 20:56:01 +0000
Cc: shim6 <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Fred Baker <[e-mail]>
To: Jari Arkko <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: successful termination?
Date: Thu, 2 Apr 2009 13:55:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2206; t=1238705720; x=1239569720; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Fred=20Baker=20<[e-mail]> |Subject:=20Re=3A=20successful=20termination? |Sender:=20; bh=AJ7r+aPLackWLgBeG0+sVL7Zn+qF3fx7nVN6+HmYsm8=; b=FhZqRYt66om47OxFyrcNobJXO+WasySHfnZ3aN8EflReLdminexfD9e0BH HRi5+4aH3fZ1y4KRZEX8/7wVx/C8Hh2r4e1BfbmS7lWsLiyhFUh8fZcpuBZN N4h5LoxfUC;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );

In my opinion, there are two rational outcomes. One is to close the  
working group pending deployment reports, and recharter to address  
issues that arise in that deployment. The other is the locator pair  
issue, which should IMHO be conjoined with the RFC 3484 update ongoing  
in 6man. I would ask 6man to pick up the locator pair question.

On Apr 2, 2009, at 1:37 PM, Jari Arkko wrote:

> Folks,
>
> As you may have noticed, all three base Shim6 documents have now  
> been approved after extensive edits from IESG reviews. This is  
> obviously a very happy outcome even if it took a long time. Thank  
> you everyone who was involved in making this happen!
>
> Last week I when I met the chairs and lead authors I asked what they  
> believe should happen next. A lively discussion followed about the  
> status of the technology, the WG, and its few remaining WG  
> documents. But our main conclusion was that the working group  
> participants should tell us what they have in mind.
>
> Here's a couple of different alternatives:
>
> 1. Declare success and close the WG. The most important work now is  
> implementation, testing, and deployments. The WG is not needed at  
> this moment, and if it will later be needed, it is easy to create a  
> maintenance WG. Or if a new effort for some bigger new piece of  
> functionality is needed, the proper way to do that is through a BOF  
> anyway. Question: how many implementations exist? Which ones are  
> worked on actively? Is there any deployment or trial experience to  
> report?
>
> 2. Put the WG into sleep for a year or two, and return when there's  
> additional experience.
>
> 3. Work on the most important one(s) of the remaining WG documents  
> (locator-pair-selection, api, applicability). Which one? Is there  
> energy to do the work, including WG participants doing reviews,  
> commenting on issues, etc?
>
> 4. Do something else that is important for Shim6. What?
>
> We would like to move forward with this in a couple of weeks. The WG  
> will either be closed or rechartered. Let us know if you are  
> interested and if so, what you believe should be done.
>
> Jari
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 02 Apr 2009 20:39:40 +0000
Message-ID: <[e-mail]>
Date: Thu, 02 Apr 2009 22:37:36 +0200
From: Jari Arkko <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: shim6 <[e-mail]>, [e-mail]
Subject: successful termination?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Folks,

As you may have noticed, all three base Shim6 documents have now been 
approved after extensive edits from IESG reviews. This is obviously a 
very happy outcome even if it took a long time. Thank you everyone who 
was involved in making this happen!

Last week I when I met the chairs and lead authors I asked what they 
believe should happen next. A lively discussion followed about the 
status of the technology, the WG, and its few remaining WG documents. 
But our main conclusion was that the working group participants should 
tell us what they have in mind.

Here's a couple of different alternatives:

1. Declare success and close the WG. The most important work now is 
implementation, testing, and deployments. The WG is not needed at this 
moment, and if it will later be needed, it is easy to create a 
maintenance WG. Or if a new effort for some bigger new piece of 
functionality is needed, the proper way to do that is through a BOF 
anyway. Question: how many implementations exist? Which ones are worked 
on actively? Is there any deployment or trial experience to report?

2. Put the WG into sleep for a year or two, and return when there's 
additional experience.

3. Work on the most important one(s) of the remaining WG documents 
(locator-pair-selection, api, applicability). Which one? Is there energy 
to do the work, including WG participants doing reviews, commenting on 
issues, etc?

4. Do something else that is important for Shim6. What?

We would like to move forward with this in a couple of weeks. The WG 
will either be closed or rechartered. Let us know if you are interested 
and if so, what you believe should be done.

Jari