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

Robert Raszuk <robert@raszuk.net> Fri, 31 March 2017 18:14 UTC

Return-Path: <rraszuk@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 3B8D11200C5; Fri, 31 Mar 2017 11:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 WKicYDbec0_4; Fri, 31 Mar 2017 11:14:10 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 999021299AC; Fri, 31 Mar 2017 11:14:08 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id y18so17723617itc.0; Fri, 31 Mar 2017 11:14:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=e9GDzSw9LZoVDZXq/8fJf4VqjAyzisgpM/tRNpfbeaM=; b=GqcPww3ayYLw7uQFm4cH4r2TIvV7bNs+gut8W3LKPBFqYyvIakJFmhdlX2fuizg0Hp DwaSoXbikT42bccZ9OcP78mRtvaIG3usRZYKgRvYWNzwXlioRaVI193RryVHztk61tSO QkNpkWj03Lf8oMZJx4cMbDYdwwkPOw4KM6/8hOQAHP+Y4CQAqBnKQsyUhnRrSE01rHHE gNQiErw1o7c6/PngL2zbjyb6VQECI/X8bFz10tT2O+M46EustMi7QO3nV2XkBmaxDOzN 0K+kiHaPSOM8TQDHYsX6urxwXfrfFJ/OMOS4TEfDeczlKF6OIxOoLbzvUSdiYkTOm5Ag C5Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=e9GDzSw9LZoVDZXq/8fJf4VqjAyzisgpM/tRNpfbeaM=; b=qsBlFB3F4xKJgs1buAaviIf6x0k9iCWKPrBxmmi4Cvgo5WUlK6HmEaiW4HdmNJZYC9 fOGdmixQZNSaBUS0Rk7kLLxlFdBtWpl1Mj0/9ZRXdkKyqUiI9bCKnFyPQrG4UDLeglKj WNk4xTYpsumM6jpIMjO37FWcGekIBF6J3R3qmbKBzN1W519CA82MccukX1yjJnl2KxE0 X8KoQsO/x1z04mI7SyHwtHX1vEATcIfKzvSxejz6HjM1yVC/iG5RcLxg56tEbssg2KNP JkbFbBucl2o+PFcgYhEfOM29iVhZKnku5qKNwSMSuU9/xGxM9QZ+aHQLqeZRnZux5q1s ZoGw==
X-Gm-Message-State: AFeK/H2E1NHyCj5HAbtSKMGpjcJAW96BmSQE6pzUirjCfRHU/IZPMCK96432Xessap+5r+uXmRn02O7TusJ4aQ==
X-Received: by 10.36.46.81 with SMTP id i78mr5421651ita.39.1490984047915; Fri, 31 Mar 2017 11:14:07 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 11:14:06 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 11:14:06 -0700 (PDT)
In-Reply-To: <0206BF42-1C7C-44F2-8F18-DC9ABB6DA746@ericsson.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.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> <0206BF42-1C7C-44F2-8F18-DC9ABB6DA746@ericsson.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 31 Mar 2017 13:14:06 -0500
X-Google-Sender-Auth: 3hXVJHe969Fm_-3tR3x3yxa5hmg
Message-ID: <CA+b+ERmL_J3O8VRQikXcb0LQ8TXW2RUg4mOK3MkVS0Sj+NqasQ@mail.gmail.com>
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
Cc: "Leddy, John" <John_Leddy@comcast.com>, otroan@employees.org, IETF Discussion <ietf@ietf.org>, 6man WG <ipv6@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>
Content-Type: multipart/alternative; boundary="001a114a93ce8abcfc054c0ac60a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wptnGaB9onu38hj33JHswNqDcxY>
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:14:12 -0000

Hi Suresh,

The fact that encapsulation in new v6 header is optional to me is clearly
stated in section 4.1 of that document:

 By default, a local SID bound to the End function does not allow
      the decapsulation of an outer header.  As a consequence, an End
      SID cannot be the last SID of an SRH and cannot be the DA of a
      packet without SRH.

   o  If the decapsulation is desired, then another function must be
      bound to the SID (e.g., End.DX6 defined in
      [I-D.filsfils-spring-srv6-network-programming
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.filsfils-spring-srv6-network-programming>]).
This prevents
      any unintentional decapsulation by the segment endpoint node.  The
      details of the advertisement of a SID in the control plane are
      outside the scope of this document (e.g.,
      [I-D.previdi-idr-segment-routing-te-policy
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.previdi-idr-segment-routing-te-policy>],
      [I-D.dawra-bgp-srv6-vpn
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.dawra-bgp-srv6-vpn>]
and [I-D.bashandy-isis-srv6-extensions
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.bashandy-isis-srv6-extensions>].


On Mar 31, 2017 13:08, "Suresh Krishnan" <suresh.krishnan@ericsson.com>
wrote:

> Hi Robert,
>
> On Mar 31, 2017, at 12:56 PM, Robert Raszuk <robert@raszuk.net> wrote:
>
> Even if we treat encapsulation in new IPv6 header as only an option ?
>
>
> There are two options listed in the draft with the “either” clause quoted
> below. Both of them are compliant. In fact, in my not so careful reading, I
> do not see any text in draft-ietf-6man-segment-routing-header-06
> <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06> that
> would be contrary to this text in RFC2460bis.
>
> Thanks
> Suresh
>
> P.S.: I am assuming you are using the word option to mean a choice and not
> an IPv6 option. If not, please clarify.
>
>
> 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
>>
>>
>