IETF Logo Mail Archive

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Fernando Gont <fgont@si6networks.com> Thu, 27 February 2020 08:06 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618DD3A14CD; Thu, 27 Feb 2020 00:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tMCkLcCr4Oz4; Thu, 27 Feb 2020 00:06:00 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9070C3A14CC; Thu, 27 Feb 2020 00:06:00 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 61DCB8051F; Thu, 27 Feb 2020 09:05:50 +0100 (CET)
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: Dirk Steinberg <dirk@lapishills.com>
Cc: "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, Warren Kumari <warren@kumari.net>, John Leddy <john@leddy.net>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>
References: <F88E3F76-DD4B-4807-A458-85FABFF20D96@gmail.com> <5D218BFB-0D6F-4F7D-858F-B571A67DC47F@leddy.net> <CAHw9_iJ_ipEvU0NUx44XbK0_DrLe_GRw6G=m+chK4wZcRP8BMg@mail.gmail.com> <ACA082A4-BC78-4C63-9F91-5C9A44F47642@cisco.com> <8abfd5a1-e806-3598-c389-8214b3d09447@si6networks.com> <CAFqxzqZgL_pg6hgW0dGbCzyjUzJdAVkfyicwTiac+8kwGxsuVw@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <3674ad2d-ea6e-5a42-b444-eca1cfb0974a@si6networks.com>
Date: Thu, 27 Feb 2020 05:05:30 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAFqxzqZgL_pg6hgW0dGbCzyjUzJdAVkfyicwTiac+8kwGxsuVw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4pLSIrb-L4Qx19_x1XFueaxLRLU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 08:06:03 -0000

On 27/2/20 04:51, Dirk Steinberg wrote:
> 
> 
> On Thu, Feb 27, 2020 at 1:45 AM Fernando Gont <fgont@si6networks.com 
> <mailto:fgont@si6networks.com>> wrote:
> 
>     Hello, Eric,
> 
>     On 26/2/20 20:18, Eric Vyncke (evyncke) wrote:
>      > Writing this without any hat,
>      >
>      > Please note that on the logical side, it still have to be
>     "proven" that this idea is strictly forbidden by RFC 8200.
> 
>     Here's the proof part:
> 
>     1) Isn't IPv6 end to end?
> 
>     2) How do core components of IPv6, such as AH and PMTUD work in the
>     present of intermediate nodes that can add and/or remove arbitrary
>     extension headers?
> 
>     It should be clear from the above that EH insertion/deletion is
>     forbidden.
> 
> 
> As I already explained to you this is not true.
> The wording of RFC8200 clearly allows this.
> The node addresses by the DA of the packet can do this.
> I understand that you would like to modify the wording of
> RFC8200 to make your point true but it simply is not.
> Repeating a false statement does not make it true.

Please answer the questions I've asked, and you'll get the response:

IPv6 is end to end, and does not support header insertion or deletion 
en-route to the final destination. It would break core IPv6 components 
such as PMTUD and AH.

If you find that the wording in RFC8200 should be improved, so be it: we 
already have to improve it from RFC2460, and it seems you still trying 
to find ways to circumvent the spec.

If the spec warrants a *clarification*, so be it: we already did it from 
RFC2460, we did it for RFC8200 for the fragmentation part, and we may 
also have to do it for EH processing (and not only for this issue).

I have given it a shot here: https://www.rfc-editor.org/errata/eid5933

That's what erratas are for.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

v2.3.2 | Report a Bug | By Email