Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 31 March 2017 18:18 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D82126DFB; Fri, 31 Mar 2017 11:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 fqvI5mmhVYLH; Fri, 31 Mar 2017 11:18:46 -0700 (PDT)
Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 36C02120725; Fri, 31 Mar 2017 11:18:46 -0700 (PDT)
Received: by mail-it0-x244.google.com with SMTP id e75so2797131itd.1; Fri, 31 Mar 2017 11:18:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OXx02gTkEjtTOC68+xl7oUQBokNg7HenrItSxIx7BZo=; b=NNlR6F+CtcP9eaa+IQeoQKcIrGenqbIIANKS1h78REdZW2QyWmP5kRh9Vg/NdSWx0W B6e2V/Lgdy/qLu4EaSz7S07gr41/Oqj56iJmnuTv7xL4EgZTsnoWvjBElMMK3AyaAuQH ZUkkCvlgmKeTsY5X7/+NpO0kczXUnttNJmPZ0zYFUyJF7gTnFZUQLr8rjgdlI4viV1Ec PKIMguS+TSdjRcDwPwMDUtg3FDFeUz/ES8FhCfn/uOSt/QVEKIWYoK43IyKH3RABSgYS ufGHVDoObFZnv6kVHTZmqVaQt0RBMSrSAXxq5weVUiOQOOq/LjAHszTZG3gwyVJ+LwnO Mdow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=OXx02gTkEjtTOC68+xl7oUQBokNg7HenrItSxIx7BZo=; b=RsxbjydjBA7wJ7Db08rGZdaCgUfJSI3Eijfs/qRdu31TRkUy0RfZeS1YPbVKt3M6fQ Z4l3T8AsJ7MP0aP6mQCmIJNyKD2rMF/T/GWP723Yb7vRFuXSBl0Ca+BMySEEu8s3KmLl 44whVMg2l668V9G1j5XUstJsxtMUKqOS2f7hEZ4n6H3/z4qbqjsaYbA6ithkIAlzTqtQ HGnotffKOPh3AsdIlC/IY9U5dRPIeW6bXklNzEuYME51zfj+WL93tAwzLx7eJmpIp42z Tgk9ik0fwLBcN2vH/8JMpTabmduhsKqV+IDxX8EpwxZpSup7soqDXyaQgt8SUJ6WvnvO KL5w==
X-Gm-Message-State: AFeK/H1l/6zgWl+m/XGgAKN8poyU40GTfWFAEDMlUi/jIBj1ZiYCBf8J5vWYkVM4/DJRIw==
X-Received: by 10.36.0.198 with SMTP id 189mr5503452ita.82.1490984325587; Fri, 31 Mar 2017 11:18:45 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n73sm3538071ioe.10.2017.03.31.11.18.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 11:18:44 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Robert Raszuk <robert@raszuk.net>, Suresh Krishnan <suresh.krishnan@ericsson.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> <CA+b+ERk8kHWyBY3GPp21-pgrL_SsShaLkrn4UdecFeQPYamSEg@mail.gmail.com> <A0F19A98-7DBE-4616-B949-529ED2A81D62@ericsson.com> <CA+b+ERk_cKGB6a0SQd560cMiOzT4KbSic6fCCwQWrhNkNEcO3Q@mail.gmail.com> <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> <CA+b+ERmqpRuw0z4ZQkhNYfEqGvqEJKYwM0hkuWg8dZrYXT4DdQ@mail.gmail.com> <FCFFDDCF-7A53-41E2-B414-53E568C92B35@employees.org> <CA+b+ERmELF1p_5vX_nqhB58Bm8c34N6=kkijuCRYkfkQcfKneQ@mail.gmail.com> <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> <CA+b+ERm7vO-ZpSHKLvY+BfgWpMa7+abKR6BFnXkgUuUPEXYVEg@mail.gmail.com> <6C78BE2C-58B6-4A3A-B42A-C8A46D68B730@ericsson.com> <CA+b+ERk4mbHrTZi3JFKBh4RjUzN=SVUGONvFuEA5Ed178MzZmA@mail.gmail.com> <3A7C2C05-8513-4248-82F3-15CC9C75B69E@ericsson.com> <CA+b+ERmchYvF9uexQZ-j752OPrtzr_TQgyDov7q01EvYe1ByWQ@mail.gmail.com>
Cc: "Leddy, John" <John_Leddy@comcast.com>, otroan@employees.org, IETF Discussion <ietf@ietf.org>, 6man WG <ipv6@ietf.org>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <b1109215-0bc9-188e-3df7-92a0f67e9566@gmail.com>
Date: Sat, 1 Apr 2017 07:18:54 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CA+b+ERmchYvF9uexQZ-j752OPrtzr_TQgyDov7q01EvYe1ByWQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/jIHynLPGavYqLg8vH6PogH6hGoE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Mar 2017 18:18:48 -0000

Robert,

Actually this was thoroughly discussed (mainly with Stefano I think)
and these texts in draft-ietf-6man-segment-routing-header-06 were
carefully designed to be compatible with both RFC2460 and RFC2460bis:

Section 2.3.1:
>  The outer header with the SRH is no different from any other
>  tunneling encapsulation mechanism and allows a network operator to
>  implement traffic engineering mechanisms so to efficiently steer
>  traffic across his infrastructure.
 
Section 5.1:
>  A Source SR Node can be any node originating an IPv6 packet with its
>  IPv6 and Segment Routing Headers.  This include either:
> 
>     A host originating an IPv6 packet.
> 
>     An SR domain ingress router encapsulating a received IPv6 packet
>     into an outer IPv6 header followed by an SRH.

I suppose we need expert review of the routing header itself, but
for me there is simply no issue about compatibility with 2460(bis).

(draft-voyer-6man-extension-header-insertion is a quite different
conversation and we should not confuse the two. That would be FUD.)

Regards
   Brian

On 01/04/2017 06:56, Robert Raszuk wrote:
> Even if we treat encapsulation in new IPv6 header as only an option ?
> 
> Thx
> R.
> 
> 
> 
> On Mar 31, 2017 12:46, "Suresh Krishnan" <suresh.krishnan@ericsson.com>
> wrote:
> 
>> Hi Robert,
>>
>> On Mar 31, 2017, at 12:01 PM, Robert Raszuk <robert@raszuk.net> wrote:
>>
>> Hi Suresh,
>>
>> As you requested one of many quotes from the draft which your
>> clarification to 2460bis directly contradicts with:
>>
>> This include either:
>>
>>       A host originating an IPv6 packet.
>>
>>       *An SR domain ingress router encapsulating a received IPv6 packet
>>       into an outer IPv6 header followed by an SRH.*
>>
>>
>> Excellent. Thanks for pointing out the exact text. I can confirm that this
>> text  *is compliant* with the RFC2460bis text.
>>
>> Thanks
>> Suresh
>>
>>
>