IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 04 April 2017 12:57 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 8D795126BF7; Tue, 4 Apr 2017 05:57:26 -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 7HSAmAxS_ZtP; Tue, 4 Apr 2017 05:57:24 -0700 (PDT)
Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 B8C6F1272E1; Tue, 4 Apr 2017 05:57:24 -0700 (PDT)
Received: by mail-io0-x243.google.com with SMTP id f84so14941858ioj.0; Tue, 04 Apr 2017 05:57:24 -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=WWQfwUJPwpAcRz1apkb40APl7+n7NxiBjuS1xaIv7Zk=; b=Ko4fK2GIT8ecN+8U73CW71DXbd6jp4zQ0iPbmNwWzBlhxEEPksAGdazIc+Myjyn6D4 NSyYGYxj3Y6H/De2+AboUWGhdapulwOrbYZPWxiIEKsMOl1Zc2R2a9OXiocsBwHXosaf te2lpEda+qV3X352bfWlCQqjrO41Qd4HFEkUS0T+dHlA8SN95zsGWgCa0EzcVXD1xs7r 38Mltg2Pof7VDfH/1lNugA9ZNs2eOK/Qd6QDji3YAMa89itgctvwxn4lwLj5chQwNNxF TysBQUcNShltS43AAWLqSkgh0c8Xrn9IynAqTljAMn1jdFDpWCVCTS9XYeqJONympDPk 0ofA==
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=WWQfwUJPwpAcRz1apkb40APl7+n7NxiBjuS1xaIv7Zk=; b=TD4S/igOZ1kp2UYCbtpDvc/aLIRzhbgHQOZtpTnTW1OIQJYIqV4FecHjuSiH5MmAnM 79Av2FsmRAL0IwB/K5fTTdzwwS69u1ND3XdcGX7zfCqXjobv3Tj0tf63+4ULaRlToKkU TkOYUS2/wuwaIVVriG56oTSmFaiZINM2900/LePvvn63irLg46MgswbX2mnjUlsP6Pze S3dDIOz/EDYNOrr8a7uimqi8Qce3T7++yCAUNUd9FcHrCEttsSjhNZ+C4C1Dxaz9+jHV pmo+1nqcQsdDJ1nh2+TSA5ZFQj0ezgLCn0kxBgNgdZ3Z2yxizxEvsydmq/U5IynSfhLC kpOg==
X-Gm-Message-State: AFeK/H21SP4Z2kdP45Pl8McmYHbbTWJNBCa0xY6BGgAA/jy6GOaJJLkK67bXncgHo0yieg==
X-Received: by 10.107.174.27 with SMTP id x27mr21260900ioe.35.1491310643940; Tue, 04 Apr 2017 05:57:23 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id v187sm8627663ith.18.2017.04.04.05.57.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 05:57:23 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Robert Raszuk <robert@raszuk.net>, Fernando Gont <fgont@si6networks.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> <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> <CA+b+ERk2E43abOjYQSLQNpYu7OUunZhMzrHdaNxndWEujPa9Qw@mail.gmail.com>
Cc: "Leddy, John" <John_Leddy@comcast.com>, 6man WG <ipv6@ietf.org>, IETF Discussion <ietf@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: <ec10ed2a-a187-4539-d62e-67d331881887@gmail.com>
Date: Wed, 05 Apr 2017 00:57:19 +1200
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+ERk2E43abOjYQSLQNpYu7OUunZhMzrHdaNxndWEujPa9Qw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NEdc_U1Psx7O5BU5Q3ArG6x8FzA>
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: Tue, 04 Apr 2017 12:57:26 -0000

On 04/04/2017 18:12, Robert Raszuk wrote:
> Hi Fernando,
> 
> The WG document talks about two cases ...
> 
> * EH insertion at the host (src of packet)
> 
> * IPv6 new encapsulation + EH insertion on the ingress to SR domain
> followed by decapsulation at the egress of SR domain.
> 
> I hope we can agree on that.

We can't, because neither of them is "insertion". They are simply packets
created at their source (the encapsulator) that happen to contain SR headers,
or any other kind of IPv6 extension header for that matter.

> However is it wise to expect any time within SR domain for a packet (v6
> encapsulated on ingress) to get steered differently (say coming out of
> service chain) to decapsulate and encapsulate again ? Seems to me like
> quite local box decision anyway.

Yes, they can decapsulate and re-encapsulate as often as they like and 
remain consistent with 2460bis.

> Hence my comment about implicit insertion.
> 
> In any case if we see this entire thread the only technical concern with EH
> insertion was MTU. And how that issue is solved when you do additional IPv6
> header encap ?

PMTUD applies to the path between source A (encapsulator) and destination B
(decapsulator). If you decapsulate at B and the encapsulate again, PMTUD
applies to the path between B (encapsulator) and C (decapsulator). They are
completely independent; it's a new packet. PMTUD doesn't occur between A 
and C at all.

    Brian

> 
> Or maybe encap is allowed simply as it can not be forbidden :))
> 
> Cheers,
> Robert.
> 
> 
> On Tue, Apr 4, 2017 at 1:15 AM, Fernando Gont <fgont@si6networks.com> wrote:
> 
>> On 03/31/2017 04:11 PM, Robert Raszuk wrote:
>>> I do not understand how 2460bis makes it "easier" if proposed change to
>>> the text directly tries to prohibit what is described in a document
>>> already long time back accepted as a 6man working group draft.
>>
>> This is incorrect. For instance, the condition to accepting such I-D as
>> a wg items was indeed that EH insertion was removed, and that
>> encapsulation be used instead.
>>
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>>
>

v2.23.0 | Report a Bug | By Email