Re: [shim6] AD review of draft-garcia-shim6-applicability-00.txt

Jari Arkko <jari.arkko@piuha.net> Wed, 15 February 2012 13:06 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: shim6@ietfa.amsl.com
Delivered-To: shim6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0576921F8768 for <shim6@ietfa.amsl.com>; Wed, 15 Feb 2012 05:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.408
X-Spam-Level:
X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTL2eO96nYnL for <shim6@ietfa.amsl.com>; Wed, 15 Feb 2012 05:06:16 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 02A7621F8720 for <shim6@ietf.org>; Wed, 15 Feb 2012 05:06:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 51A472D35A; Wed, 15 Feb 2012 15:06:15 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoNs_rXrkU99; Wed, 15 Feb 2012 15:06:07 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 4F9362CC3C; Wed, 15 Feb 2012 15:06:07 +0200 (EET)
Message-ID: <4F3BADBF.4000308@piuha.net>
Date: Wed, 15 Feb 2012 15:06:07 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
References: <4EF089CF.5070300@piuha.net> <00d901ccc0a3$c68c7dc0$53a57940$@it.uc3m.es> <4EF33EDB.5010806@piuha.net> <011901ccc0d0$467030f0$d35092d0$@it.uc3m.es> <4F34CAFE.4030703@piuha.net> <007301cce7fe$b553f6f0$1ffbe4d0$@it.uc3m.es>
In-Reply-To: <007301cce7fe$b553f6f0$1ffbe4d0$@it.uc3m.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: 'marcelo bagnulo braun' <marcelo@bagnulo.net>, 'shim6' <shim6@ietf.org>, 'Joe Abley' <joe.abley@icann.org>
Subject: Re: [shim6] AD review of draft-garcia-shim6-applicability-00.txt
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2012 13:06:21 -0000

Thanks. I sent the document for last call.

Jari

On 10.02.2012 16:17, Alberto García wrote:
> Hi Jari
>
> |  -----Mensaje original-----
> |  De: Jari Arkko [mailto:jari.arkko@piuha.net]
> |  Enviado el: viernes, 10 de febrero de 2012 8:45
> |  Para: Alberto García
> |  CC: 'shim6'; 'marcelo bagnulo braun'; 'Joe Abley'
> |  Asunto: Re: AD review of draft-garcia-shim6-applicability-00.txt
> |
> |  Alberto,
> |
> |  I'm returning back to this thread... we should progress the document. Can
> |  you provide a revision? I've included some additional answers to your
> |  questions below.
>
> I have just uploaded a new version for the draft, to move it forward:
> -----
> http://www.ietf.org/internet-drafts/draft-garcia-shim6-applicability-03.txt
> A new version of I-D, draft-garcia-shim6-applicability-03.txt has been
> successfully submitted by Alberto Garcia-Martinez and posted to the IETF
> repository.
>
> Filename:	 draft-garcia-shim6-applicability
> Revision:	 03
> Title:		 Applicability Statement for the Level 3 Multihoming Shim
> Protocol (Shim6)
> Creation date:	 2012-02-10
> WG ID:		 Individual Submission
> Number of pages: 26
> -----
>
> Some responses inline
>
> |
> |>  Hi Jari,
> |>
> |>  [Trimming out all the issues already agreed]
> |>
> |>  |>   |  The source address problem discussed in one paragraph in
> |>  |>  Section 4  | should  be highlighted much earlier. It is a key
> |>  |>  missing pieces for  | Shim6 to  work, and  |  it would be honest to
> |>  |>  tell this to the reader. Similarly, the  | initial  contact  |
> |>  |>  issue from Section 5.1.1 should also be highlighted up front.
> |>  |>
> |>  |>   To address this, I suggest moving the current section '3.
> |>  |>  Addresses  and Shim6' after 'Shim6 capabilities'. The result would
> be:
> |>  |>   1.  Introduction
> |>  |>   2.  Deployment Scenarios<- this is a short section which define
> |>  |>  the  topology... which is convenient before discussing all the
> |>  |>  problems  related with the attachment to different providers.
> |>  |>   3.  Shim6 in Multihomed Nodes<- source address problem 4.  Shim6
> |>  |>   Capabilities<-- initial contact issue 5. Addresses and Shim6
> |>  |>
> |>  |>   The 'addresses and Shim6' section does not include problematic
> |>  |>  issues,  so I think there is no problem in placing it later.
> |>  |>   Do you think this solves the issue?
> |>  |
> |>  |  Perhaps you could solve it in a simpler way, without this much
> |>  | surgery to  the structure of the document. Just mention the things
> |>  | we need to
> |>  highlight
> |>  |  in the introduction, and you should be fine.
> |>
> |>  OK. I undo the position change of the 'address' section.
> |>
> |>  I have added some text to the 4th paragraph of the 'introduction':
> |>
> |>  "   Shim6 provides layer-3 support for making re-homing events
> |>      transparent to the transport layer by means of a shim approach.
> |>  NEW TEXT ---->
> |>      Once
> |>      a Shim6 session has been established, the failure detection
> mechanism
> |>      defined for Shim6 allows finding new valid locator combinations in
> |>      case of failure, and using these locators to continue the
> |>      communication.  However, Shim6 does not provide failure protection
> to
> |>      the communication establishment, so if a host within a multihomed
> |>      site attempts to establish a communication with a remote host and
> |>      selects an address which corresponds to a failed transit path, the
> |>      communication will fail.
> |>  <--- END OF NEW TEXT
> |>      State information relating to the
> |>      multihoming of two endpoints exchanging unicast traffic is retained
> |>      on the endpoints themselves, rather than in the network.
> |>      Communications between Shim6-capable hosts and Shim6-incapable
> |  hosts
> |>      proceed as normal, but without the benefit of transport-layer
> |>      stability.  The Shim6 approach is thought to have better scaling
> |>      properties with respect to the state held in the DFZ than the IPv4
> |>      approach.
> |>  NEW TEXT ---->
> |>  In order to successfully deploy Shim6 in a multihomed site, additional
> |>  mechanism may be required to solve issues such as selecting the source
> |>  address appropriate to the destination and to the outgoing provider,
> |>  or to allow the network manager to perform traffic engineering. Such
> |>  problems are not specific of Shim6, but are suffered by the hosts of
> |>  any site which is connected to multiple transit providers, and which
> |>  receives an IPv6 prefix from each of them. Some of these mechanisms are
> |  not defined today.
> |>  <--- END OF NEW TEXT"
> |>
> |>  Do you think this is enough?
> |
> |  Fine for me. Modulo Brian's comments (he had a point, maybe you want to
> |  revise the above a bit).
>
> OK. To address Brian's comment, I have added a new line to the end of the
> previous paragraph, which says
> 'However, note that once a Shim6 session has been established, Shim6 reduces
> the impact of these problems, because if a working path exists, Shim6 will
> find it.'
>
> [Trimming out agreed parts]
>
> |
> |>
> |>  |>
> |>  |>   |
> |>  |>   |  Section 7 should indicate if there is any implementation of  |
> |>  |>  deployment  experience with these combinations. I'm doubtful on  |
> |>  |>  whether all the ipsec  layering mechanisms and so on would actually
> |>  |>  | work in real implementations  without someone having tested such
> |>  |  combinations.
> |>  |>
> |>  |>   I assume you are referring specifically to discuss deployment
> |>  |>  experience for the 'Shim6 and Mobile IPv6' subsection, aren't you?
> |>  |
> |>  |  No, I was thinking of all the combinations listed in Section 7.
> |>
> |>  I think there are two different cases for this. Some combinations are
> |>  NOT RECOMMENDED by the draft. These are
> |>  - shim6 and SCTP.
> |>  - shim6 and HIP.
> |>  - shim6 and NATs: since shim6 security is end-to-end, NATs break Shim6
> |>  as currently defined.
> |>  Although it would be nice to have some experimental proof of this... I
> |>  think it is easier to accept that, if the analysis is ok, no further
> |>  experiment is required.
> |>
> |>  The rest combinations are assumed to work. However, since IFAIK there
> |>  is no production deployment of Shim6, most of them have not been
> |>  tested. And even those tested, have not been tested in 'real'
> |>  conditions. For this, we have
> |>  - shim6 and IPsec and shim6 and MIPv6 (and the three of them). Barre's
> |>  implementation to check
> |>  - shim6 and SEND. It seems there should be no problem in the
> |>  interaction, since both protocols deal with different issues. I'm not
> |>  aware of any combined test for them.
> |>  - shim6 and NEMO. I'm not aware of any implementation/test of NEMO
> |>  with
> |>  Shim6
> |>  - shim6 and firewalls. There is an implementation (a modification to
> |>  Linux
> |>  netfilter) developed for a Master Thesis from U. of Lovaina:
> |>  http://inl.info.ucl.ac.be/system/files/memoire_0.pdf. They analyze
> |>  several possible issues that may arise with firewalling shim6 traffic,
> |>  although all of them seem to be solved without requiring any protocol
> |>  modification. The main problem seems to be the large amount of state
> |>  that the firewall is required to store (the locators, context tag, etc.
> for each
> |  shim6 session).
> |>  Of course, there is lack of real-world experience, so this conclusions
> |>  may not be close to reality.
> |>
> |>  So, it is very likely that we could not find info for real tests on
> |>  many of these combinations. Would it suffice to write a disclaimer for
> |>  this section saying that there is a lack of real experience with most
> |>  of these combinations?.
> |
> |  Yes, stating lack of information would be fine.
> |
>
> OK. I've added the following text:
>
> "7.  Interaction with Other Protocols and Mechanisms
> NEW TEXT ---->
>     In this section we discuss the interaction between Shim6 and other
>     protocols and mechanisms.  Before starting the discussion, it is
>     worth noting that at the time of this writing there is a lack of
>     experience with the combination of Shim6 and these protocols and
>     mechanisms.  Therefore, the conclusions stated should be review as
>     real experience is gained in the use of Shim6.
> <--- END OF NEW TEXT
> 7.1.  Shim6 and Mobile IPv6
> "
>
> Regards,
> Alberto
>
> |  Jari
> |>
> |>  Regards,
> |>  Alberto
> |>
> |>  |
> |>  |>   I will ask Sebastien Barre, which had a MipShim6 implementation,
> |>  |>  with  which I think he successfully tested some of the
> |>  |>  configurations  discussed in the draft, although I'm not sure if
> |>  |>  IPsec was involved in
> |>  the
> |>  |  tests.
> |>  |>
> |>  |  OK
> |>  |
> |>  |  Jari
> |>
> |>
>
>