Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 20 May 2016 04:46 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CD912D14F for <int-area@ietfa.amsl.com>; Thu, 19 May 2016 21:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5iXG04P9Az1 for <int-area@ietfa.amsl.com>; Thu, 19 May 2016 21:46:14 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD1412B026 for <int-area@ietf.org>; Thu, 19 May 2016 21:46:14 -0700 (PDT)
Received: by mail-pa0-x236.google.com with SMTP id bt5so35631997pac.3 for <int-area@ietf.org>; Thu, 19 May 2016 21:46:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tf+IBQ7oeOZ5ymiobQdhTlcbvdoVvboJBuMLA9/hN8M=; b=ArBVwXGncmSlxUpPbiZOKJPWmhO1jvQrDkRBnwktfuefh7d6/mmWy23VQ6EKnC18hM 1AaVB6JoEn/l58fO9qaZTdMNUIX02faPfSf8S11ZMDzg6XndyiCRmSxwh23FC85diuFS kftwjHMcC/COEwIs0ul9B2hMoLE8GjPMYGZD6sN3qWhPMFsSluBIbctsLCfY2PqSFs9b a9jVrHM9DjR5uJJNcxXEGb6aRWodjHekA9gTa5rVx1hNV3qVjhaj573p5ObtBkzV4wLX QdG1e0lkpIFgwlSl3ngNQcxU522i4mHhILENw8+LNXC85raKnD86xeVwRI1TzmShRNoN 6z5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=tf+IBQ7oeOZ5ymiobQdhTlcbvdoVvboJBuMLA9/hN8M=; b=XB8ZOe9MHJqp5ql3NVj5LC+ev9HKy6bm0WeJaQ93wTRFSR2XedCbuQs+ZXX5qzSbZu 5UmFbmqu+j+md9WXoA3cVLea0LEyOBILr8c444SjzBvqrqtan9xsBwKkB+flWN4QrO9O zYitaoSqa1oGmFjQlmziMpkojUU9yHznB/qlNgqknwQNJEn032uQJuh+cuJ2nBN2/ETH YOJT2qsfmSITEmJq6oYYJJJk+EL7/UWjmCOLoJVbdcIQBdwdecL6eHdcCbXh/Gr47Vyk hfBeZyULBESu3VF8Mq4MrfF18IaaXWvLhlU0GIhUF8Zeexz9ueB2ksx6TWbZFr9YTUqj c/dA==
X-Gm-Message-State: AOPr4FUUpSvQylClyk/pCWD1tFoNJ+Cryk2q7Vpprq4/lkqfOoJMcO+GmXcXzh5ZjWKABg==
X-Received: by 10.67.14.7 with SMTP id fc7mr1601618pad.1.1463719573554; Thu, 19 May 2016 21:46:13 -0700 (PDT)
Received: from ?IPv6:2406:e007:48d6:1:244e:c9b5:70dd:39ec? ([2406:e007:48d6:1:244e:c9b5:70dd:39ec]) by smtp.gmail.com with ESMTPSA id j192sm777464pfc.25.2016.05.19.21.46.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2016 21:46:12 -0700 (PDT)
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
References: <E83B905A-FF6D-4996-B71A-7921DE4B133B@ericsson.com> <b52bf867-21ec-4ba1-6a44-76e67e37bfb4@gmail.com> <DF5065CC-F552-4DF6-9935-10E644EC233D@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <481cdf52-0439-4c6e-1241-9a6e818d4b15@gmail.com>
Date: Fri, 20 May 2016 16:46:19 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <DF5065CC-F552-4DF6-9935-10E644EC233D@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/int-area/l6tDnStAzzlykg6zwWJZ5shrMyk>
Cc: "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 May 2016 04:46:16 -0000

On 20/05/2016 15:39, Carlos Pignataro (cpignata) wrote:
> Do equivalent arguments apply also to <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/>? 

I don't know. I've never found GRE a very interesting topic so I've never looked at that draft.

> Was this one reviewed by Int-area?

Not as far as I know, but it's still technically in TSVWG last call if you have comments.

    Brian

> 
> Thumb typed by Carlos Pignataro.
> Excuze typofraphicak errows
> 
>> On May 19, 2016, at 21:17, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> As a famous physicist once said when the discovery of the muon was announced, "Who ordered that?"
>>
>> In other words, I don't understand the use case that motivated this.
>> In the Introduction, I find:
>>
>>  "By encapsulating the Softwire
>>   service traffic into an UDP tunnel and using the source port of the
>>   UDP header as an entropy field, the existing load-balancing
>>   capability as mentioned above can be leveraged to provide fine-
>>   grained load-balancing of Softwire service traffic traffic over IP
>>   networks."
>>
>> What is meant by "the Softwire service traffic"? Does it just mean a
>> bunch of traffic from a single customer? Why does it all need a
>> common header for load balancing? The individual microflows in the
>> traffic will all get load-balanced anyway.
>>
>> I trust we are only talking about IPv6. If we're talking about IPv4, we
>> certainly shouldn't be developing new methods. If we're talking about
>> IPv6, we have the flow label for this (and it avoids tricky problems
>> like finding the transport header in the presence of extension headers).
>> That's already covered in RFC 6438 for any kind of tunnel, although
>> IP in IP seems a lot simpler than IP in UDP in IP.
>>
>> (If you really must do IPv4, IPv4 in IPv6 could still be load-balanced
>> as per RFC 6438, I guess.)
>>
>>   Brian
>>
>>
>>> On 20/05/2016 05:03, Wassim Haddad wrote:
>>> Dear all,
>>>
>>> The authors of draft-xu-intarea-ip-in-udp-03 (“Encapsulating IP in UDP”) have requested that the working group adopt this work as a WG work item.
>>> So far, WG chairs have not seen widespread support and considering that lack of opposition does not qualify as support, we’re starting a working group adoption call until June 3rd. 
>>>
>>> If you consider that the draft should be adopted as a WG work item, please indicate the reason.
>>>
>>>
>>> Regards,
>>>
>>> Wassim & Juan Carlos
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>