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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 31 March 2017 18:35 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 7281212945F; Fri, 31 Mar 2017 11:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 T5f5Zj8AJ7G2; Fri, 31 Mar 2017 11:35:27 -0700 (PDT)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 F0F2B126B71; Fri, 31 Mar 2017 11:35:26 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id f103so6687429ioi.2; Fri, 31 Mar 2017 11:35:26 -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=sDMdb0NZ2SurtAK9PGMUIE16I+bMTPjorljEyyDoT9c=; b=Bg5in8An6ADxA5yMfR0/hkpq53mRZiAnyTaDjJnLSOERCrv8B+WSDz6TGOYpXBtD6f EG2EkNZxzwA+/T3wPTIene+jLuQdmMIRUDOjVpXcFO9mLeTtid/APRCSpTAey75QWKJq l71DyVuV5yX6ky/Mb6OMIf8Wax6OFK35HKUNA7K3cCfFan4TdnX07ViNyXx0wbI7SOM3 +PZGc2Q/JrQfmckDBwc345vC1bk65Iptt1aNYeq+Wnl3LUVeEZ0N8VkpgiBJU4szLeaG 4mcS+InbtcFVCGuzry6abH2rZXZYm1qPyQuiK1uzJFb8ZZ32SR7KoyaSxx68VU8ObukD ve9Q==
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=sDMdb0NZ2SurtAK9PGMUIE16I+bMTPjorljEyyDoT9c=; b=LqYvTRmcfZqhoUeQnz57YmvCl4oUUnmxnv04/vl7aB16t6HlT6Lc8StpoV0EorDJv1 kYPyJGD2IcomW+utw4QGgv5E8NiSd0Th4MpsegDozh1R1JTekdpcdTQ10T/4mvwNXYrm i1md+7m72IoKUlcexfuiMMtnzvE/X+CI0sFILDaKQx7tYLctvc9skCiqPh0AV/8IJZLj uCWL2a7BkO7rCs3Cw+1XX6A6Bjg6zRDlesjEMNRJ7qgL3htck4J5BcxqLHgTezoylKRd MU5fj5y2YCgxJWby2Fa8qA23Sx8z+vPRafBtbUG7UPc9YtfYtOJx1yNGcHZ1zM7cydhI P/5w==
X-Gm-Message-State: AFeK/H2ofx3GmXTPCqD06jLToXURgnKzMha8mq3CgzSsvnyq97TcS4O9u/bga0zeyCb/zA==
X-Received: by 10.107.1.16 with SMTP id 16mr5311052iob.44.1490985326260; Fri, 31 Mar 2017 11:35:26 -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 k63sm3556143ioi.19.2017.03.31.11.35.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 11:35:25 -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> <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> <CA+b+ERmL_J3O8VRQikXcb0LQ8TXW2RUg4mOK3MkVS0Sj+NqasQ@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: <1eb66a47-9bcc-ea5b-ae6a-35243aa99e87@gmail.com>
Date: Sat, 1 Apr 2017 07:35:34 +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+ERmL_J3O8VRQikXcb0LQ8TXW2RUg4mOK3MkVS0Sj+NqasQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/FyDO26qTlunxc9dBbnIsD5i60O0>
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:35:29 -0000

On 01/04/2017 07:14, Robert Raszuk wrote:
> 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 

Sure, any tunnel needs a decapsulator as well as an encapsulator. That's
not news, so what is the problem here? I assume you'd decapsulate in
the last hop router. I don't claim to understand segment routing, so
I can't actually understand the above text. But the text elsewhere
is clear enough that either the original source or the encapsulator
builds the routing header, and that's all we need to know for
2460(bis) compatibility. So why are we still discussing?

    Brian

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