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

Fernando Gont <fernando@gont.com.ar> Thu, 27 February 2020 11:12 UTC

Return-Path: <fernando@gont.com.ar>
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 91A943A0901; Thu, 27 Feb 2020 03:12:14 -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 ZIggTgoFb9m8; Thu, 27 Feb 2020 03:12:05 -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 AF8453A08F3; Thu, 27 Feb 2020 03:12:02 -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 1CC9D805AC; Thu, 27 Feb 2020 12:11:56 +0100 (CET)
Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: Ted Lemon <mellon@fugue.com>, "Maojianwei (Mao)" <maojianwei@huawei.com>
Cc: SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
References: <6B803B308679F94FBD953ABEA5CCCCD701089509@dggema524-mbx.china.huawei.com> <6E7A3022-DEC7-4E35-9A56-0F708CD41180@fugue.com>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <58c706f7-2370-2b63-37df-0b5daf1ad8a5@gont.com.ar>
Date: Thu, 27 Feb 2020 08:11:08 -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: <6E7A3022-DEC7-4E35-9A56-0F708CD41180@fugue.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ViJvNcJNVyCdBjhiLo94JpHJjpg>
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 11:12:15 -0000

On 27/2/20 07:27, Ted Lemon wrote:
> The IETF serves users, not “industry”.  The IETF does not promote. Our 
> job is to make the internet work interoperably. Brian has raised an 
> objection that could be answered, but has not been. It is inappropriate 
> to say that this document has passed last call.
> 
> In my experience, when it is hard to get consensus in situations like 
> this it is because there is a wish to not address a concern that has 
> been raised, not because the concern could not be addressed or should 
> not have been raised. It may feel unreasonable, and like an imposition, 
> but it is not. It is part of the process.
> 
> Rather than trying to steamroll over the objection, why not simply 
> answer it?

As a service to the community, let me explain:

Essentially, and for some reason, they seem to be meaning to circumvent 
specs and processes.

One of their last inventions has been to pretend that IPv6 allows EH 
insertion/deletion en-route, based on their reading of RFC8200. Based on 
a curious interpretation of the text, they claim that each waypoint 
(intermmediate router that received the packet because its address was 
set as de Destination Address) can insert/remove EHs, and they claim 
that that's not a violation of RFC8200.

However, the PSP behavour doesn't even fit in that fictional 
interpretation of RFC8200.

What PSP does is that, given:

  ---- B ----- C


routers, when B realizes, after processing the SRH and setting the Dest 
Addr to the last segment, SegmentsLeft==0, it removes the SRH.

This case is not even covered by their fictional interpretation of RFC8200.

Hence the question is avoided, u<because thye would have no option than 
admiting they are violating RFC8200..unless... who knows... there might 
be yet another curious interpretation of the spec that allows it.


It should eb evident here that the strategy is not really to follow IETF 
process, gain consensus, formally update specs if/where needed, but 
rather push whatever they publish, at whatever cost, ignoring the issues 
raised in this wg, and circumventing IETF process.

The fact that this behavior is allowed seems to be unfair with 
participants, and a dis-service to the group.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1