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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 04 April 2017 13:36 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 DE5FC127599; Tue, 4 Apr 2017 06:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 aNKDZwr5qnz5; Tue, 4 Apr 2017 06:36:57 -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 C7A1E127342; Tue, 4 Apr 2017 06:36:55 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id n76so15034793ioe.1; Tue, 04 Apr 2017 06:36:55 -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=bUPVykfyFdCqBRXvqE4Nuor2LA7ZNf9hFPB9foDs0GY=; b=SC0R6/eT5Q7TddBgVKW3IlbU656R2831Cc0QLiWli9NZqt9M+AxkdtSDqyYFLDDiiU VNczL1O50erfYq1jqylUwVDYprmzFmdLlMj7FlFElUV4A0prgDagXc/jUDP4rsRC5xIU NTrLd3LlCLQ86HlO4W8twZEYgNTwh0Haj+YvNHbLBJEblTP5UDJcchhUco/MYNEs5Qea s5X/7jBziSpzhTqXFyg4aV14mydk4y1nabd1Dhc8tdr9xCrZHSVQZ0xUqsj7KIOc4LEL x4HpCzU7l8Njwqgx7aejrHakJA67yjUSwBy3ZpSsejp2jSsrOQdsiZDKp3PQM88nDDAE uE3Q==
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=bUPVykfyFdCqBRXvqE4Nuor2LA7ZNf9hFPB9foDs0GY=; b=hQneZ8ZZ8pPlJQdQA9xE5tRADDY7x/eN0eXlQsGl9oouy1V8w242VPO4As8hdgyCBy /28ShvxE6DK9thuuSa/5xvak0KnYoKmgfxpsfwZK9zWt3FpTieuAFIscHBqg8dFQYBBi 1M8aBrJuRCosgweRY5IudP5JvDImZpb5fszpszhpjEdgWMKMm7ZYJ1cxXs1mC+yypAmT 0VMCtaWwUKk9FlH10M3Y+9BCulNL8JE/pkfveBhdxXh69a4SFfnzuH+tA2p9qGtPcjZI 5qbOKgkSAR4uyTGD1mHEULwPSIq3+vjDbFyQCek8+qqTBB3BYiDMUF6vXzoJHJhRCETM hgEg==
X-Gm-Message-State: AFeK/H3/X4YiSuUBRXVrVHA79m8jG672T9nU5tc66aCMOJ4y255W9i6zomhy+REt95QgcA==
X-Received: by 10.107.62.68 with SMTP id l65mr24996480ioa.213.1491313014869; Tue, 04 Apr 2017 06:36:54 -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 m77sm7240562ita.16.2017.04.04.06.36.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 06:36:54 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Robert Raszuk <robert@raszuk.net>
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> <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> <CA+b+ERk2E43abOjYQSLQNpYu7OUunZhMzrHdaNxndWEujPa9Qw@mail.gmail.com> <ec10ed2a-a187-4539-d62e-67d331881887@gmail.com> <CA+b+ERnowxo2ynO9QomXMOEwnQjVJB703NsNUzW9qACOco8CVg@mail.gmail.com>
Cc: Fernando Gont <fgont@si6networks.com>, "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: <0a74d9a6-24d3-ea00-07f2-61144f7725a4@gmail.com>
Date: Wed, 05 Apr 2017 01:36:54 +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+ERnowxo2ynO9QomXMOEwnQjVJB703NsNUzW9qACOco8CVg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/57UAAeaf2uSM3VsrpPnDIYVRdnQ>
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 13:36:59 -0000

On 05/04/2017 01:22, Robert Raszuk wrote:
> Hi Brian,
> 
>> 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.
>>
> 
> 
> ​Are you saying that it is "legal" to fragment IPv6 packet by a router at
> the encapsulation point in the network ?

I can't see any reason why the encapsulating packet couldn't be fragmented;
it's just a packet (whose payload happens to be another packet). But I would
hope that jumbo frames would make this unnecessary in the scenarios where
SR will be used.

Also, assuming 2460bis is on its way through the IESG and RFC Editor soon,
I can't see any reason why draft-ietf-6man-segment-routing-header-06
couldn't proceed to WG Last Call. I'm not quite sure why we're having this
conversation.

   Brian