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

Alberto García <alberto@it.uc3m.es> Fri, 10 February 2012 14:17 UTC

Return-Path: <alberto@it.uc3m.es>
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 D83E721F86F1 for <shim6@ietfa.amsl.com>; Fri, 10 Feb 2012 06:17:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 etnXOFKEx8Z6 for <shim6@ietfa.amsl.com>; Fri, 10 Feb 2012 06:17:11 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2841A21F86D6 for <shim6@ietf.org>; Fri, 10 Feb 2012 06:17:10 -0800 (PST)
X-uc3m-safe: yes
Received: from BOMBO (unknown [163.117.139.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id E696EC2F870; Fri, 10 Feb 2012 15:17:08 +0100 (CET)
From: =?iso-8859-1?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
To: "'Jari Arkko'" <jari.arkko@piuha.net>
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>
In-Reply-To: <4F34CAFE.4030703@piuha.net>
Date: Fri, 10 Feb 2012 15:17:23 +0100
Message-ID: <007301cce7fe$b553f6f0$1ffbe4d0$@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
thread-index: AQGDOZmzRYcIB0SkvRGwi/BNWMGwMgCBFVc7AUaz2k4Cfcj+iADaULDylqA7pgA=
Content-Language: es
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18666.006
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: Fri, 10 Feb 2012 14:17:13 -0000

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
|  >
|  >