Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Fernando Gont <fernando@gont.com.ar> Mon, 02 March 2020 16:32 UTC

Return-Path: <fernando@gont.com.ar>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B653A0B04; Mon, 2 Mar 2020 08:32:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Fde8oOvIMX7H; Mon, 2 Mar 2020 08:32:50 -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 2EAA73A0ABC; Mon, 2 Mar 2020 08:32:50 -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 305CE80B59; Mon, 2 Mar 2020 17:32:46 +0100 (CET)
To: bruno.decraene@orange.com, 'SPRING WG List' <spring@ietf.org>
Cc: draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>, rtg-ads <rtg-ads@ietf.org>
References: =?utf-8?q?=3C17421=5F1575566127=5F5DE93B2F=5F17421=5F93=5F1=5F53?= =?utf-8?q?C29892C857584299CBF5D05346208A48D1A3DA=40OPEXCAUBM43=2Ecorporate?= =?utf-8?q?=2Eadroot=2Einfra=2Eftgroup=3E_=3C5518=5F1582908787=5F5E594573=5F?= =?utf-8?q?5518=5F436=5F1=5F53C29892C857584299CBF5D05346208A48DD1BCA=40OPEXC?= =?utf-8?q?AUBM43=2Ecorporate=2Eadroot=2Einfra=2Eftgroup=3E?= =?utf-8?q?=3C99ad1c26-55e4-6c07-c896-60b0f4d9c54a=40gont=2Ecom=2Ear=3E_=3C5?= =?utf-8?q?847=5F1583155185=5F5E5D07F1=5F5847=5F402=5F1=5F53C29892C857584299?= =?utf-8?q?CBF5D05346208A48DD4EE4=40OPEXCAUBM43=2Ecorporate=2Eadroot=2Einfra?= =?utf-8?q?=2Eftgroup=3E?=
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <a2451f01-9fd2-5d82-5a95-80a702626a26@gont.com.ar>
Date: Mon, 2 Mar 2020 13:32:41 -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: =?utf-8?q?=3C5847=5F1583155185=5F5E5D07F1=5F5847=5F402=5F1=5F53?= =?utf-8?q?C29892C857584299CBF5D05346208A48DD4EE4=40OPEXCAUBM43=2Ecorporate?= =?utf-8?q?=2Eadroot=2Einfra=2Eftgroup=3E?=
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/spring/y9cN7Vko43w3nY-Tq1igP8QMqy8>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 16:32:57 -0000

Hello, Bruno,

On 2/3/20 10:19, bruno.decraene@orange.com wrote:
[....]
>>> ===============
>>> 
>>> A) PSP [1] & RFC 8200 [2]
>>> 
>>> ===============
>>> 
>>> This point is whether SRH removal by the penultimate SR end point
>>> (aka PSP) is allowed by RFC 8200.
>>> 
>>> More specifically
>>> 
>>> " S14.4.Remove the SRH from the IPv6 extension header chain"
>>> 
>>> Vs
>>> 
>>> "Extension headers (except for the Hop-by-Hop Options header) are
>>> not processed, inserted, or deleted by any node along a packet's
>>> delivery path, until the packet reaches the node (or each of the
>>> set of nodes, in the case of multicast) identified in the
>>> Destination Address field of the IPv6 header."
>>> 
>>> On this text, what is been discussed is "the node (or each of the
>>> set of nodes,
>>> 
>>> in the case of multicast) identified in the Destination Address
>>> field
>>> 
>>> of the IPv6 header."
>>> 
>>> More specifically whether "Destination Address field of the IPv6
>>> header" means the "final Destination Address" or the "Destination
>>> Address" as seen in the packet that the node received.
>> 
>> If it meant "Destination Address", that would mean multicast
>> addresses, would be allowed in routing headers.
> 
> I don't think so. I'll try to reorganize the sentence to try to
> highlight the point:
> 
> until the packet reaches the node identified in the Destination
> Address field of the IPv6 header. (or each of the set of nodes
> [identified by that Destination Address] ,in the case of multicast)
> 
> In the case that we are discussing, there is one single node,
> identified by the Destination Address. This is not multicast.
> 
>> Do you think htat's the case?

The PSP has two non-compliant behaviors:

1) EH removal:

In order to claim that IPv6 supports en-route EH insertion/removal, it
should address the issues that would introduce with:
* pmtud
* ipsec ah
* error reporting

And it doesn't. i.e., not only it was never the intent for ipv6 to
support eh insertion/removal, but also clearly couldn't do it without
addressing these three issues.



>> [...]
>>> Finally, the responsible AD has not accepted the related errata. 
>>> https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/
>>
>>
>>> 
The status of this erratum is found here:
>> https://www.rfc-editor.org/errata/eid5933   -- not on the
>> mailing-list archive. And the erratum is marked as "reported", not
>> as "rejected".
>> 
>> Suresh may well go ahead and reject it. BUt so far the status has
>> not changed since I've reported it.
> 
> The email from Suresh seems crystal clear, including to you given
> your reaction. Even after you said you would appeal, Suresh said that
> he were standing by his decision. " > As such, I will formally Appeal
> your decision. Please do go ahead. I stand by my assessment that this
> is a misuse of the Errata process and it is not a simple
> clarification as you claim."
> 
> 
> Also, I have never sent that the errata was rejected. Please don't
> put words in my mouth. I said "not accepted".
> 
> Finally, the errata status has now change. So what's you point, now?

My point is that, as part of declaring consensus on the network
programming draft, you based such decision (dismissing the non-compliant
behavior of PSP) on a fact that had not taken place. That doesn't seem
correct.



[...]
>> 
>> Clearly, there was no "threat". I did indicate that one of our
>> specs was being violated, and that our processes were being
>> circumvented (in the same way that I'm quite curious how you can
>> claim consensus on this document, but.. ).  That says, appeals are
>> part of our processes.
>> 
>> I have no idea whatsoever how, sticking to our processes could be 
>> considered a threat.
> 
> I used the wording from the official shepherd write up. " (10) Has
> anyone threatened an appeal" 
> https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents/
>
>  I you have an issue with this term, please raise it to the IESG.

My bad -- I didn't remember the sheperd's write-up had such question.


> 
> I fully agree that appeal is part of the process (so does errata). I
> would go further that IMHO this is definitely a required part of the
> process. Making an appeal is your right. I don't want discourage or
> encourage you do use it in any way.

Agreed.



[...]
>>> Independently of RFC 8200, the question has been raised with
>>> regards to the benefit of PSP.
>>> 
>>> My take is that PSP is an optional data plane optimization.
>>> Judging its level of usefulness is very hardware and
>>> implementation dependent. It may range anywhere from "not needed"
>>> to "required for my platform" (deployed if you are network
>>> operator, or been sold if you are a vendor), with possible
>>> intermediate points along "n% packet processing gain", or
>>> "required when combined with a specific other feature". I don't
>>> think that the SPRING WG can really evaluate this point (lack of 
>>> hardware knowledge, lack of detailed information on the
>>> hardwares).
>> 
>> Am I reading correctly? Are you kind of stating that the same
>> working group that is shipoing this document doesn't have enough of
>> a clue to analyze the benefits (or lack thereof) of PSP?
>> 
>> And, because of that, you make the assessment yourself?
> 
> On the mailing list, multiple persons stated that it was implemented
> in their implementation or useful for their deployment. I'm saying
> that the performance gain cannot be evaluated by the working group.

How can a working group ship a document it cannot evaluate?

If you're saying that the wg doesn't have the skills to evaluate a
document it is shipping, what's the value in your statement that this
document has wg consensus?

Seriously.... it is the wg shipping the document, not a vendor (at least
formally speaking).




>> From a logical standpoint, to prove that this is useful, it's
>> enough to have one implementation/deployment case to benefit from
>> it. This has been stated on the mailing list.
> To prove that this is not useful, one need to prove that this is not
> useful some any one/any case. This is much harder. No one has even
> tried to make that demonstration.

This is *terrible* reasoning. Really. To an extent that I'm even 
surprised that you're saying it.

Several folks have raised questions on the need for PSP, which the 
authors *failed* to respond or address.

If you want to ship a document, you should at least be able to make a 
case for it.



>>> ===============
>>> 
>>> I'm listed as a contributor on this document (among 23
>>> contributors).
>>> 
>>> Even though I have zero specific write/modification privilege on
>>> the text in this document, and I'm not part of the authors email
>>> alias, this would not be ideal for me to take the decision to
>>> forward this document to the IESG. I've discussed this with our
>>> AD (Martin) and he agreed to make the formal decision to send the
>>> document to the next level. Thank you Martin.
>> 
>> Indeed, this could be seen as a possible conflict of interests.
> 
> That's why both myself and Martin have stated that the decision would
> be taken my Martin.

Weren't you the one declaring consensus on this document? Weren't you 
the one preparing the shepherd's write up?




> That been said, "conflict of interest" is about "interest". I'm not
> working for a vendor who may have an interest to push, or delay or
> stop a work based on it's hardware and software capability. I'm not
> working for an operator who is deploying it. My only interest would
> be to be listed as an contributor on a document. Really? I'm fine
> with been removed from the list of contributors. I have not proposed
> that because doing so would be borderline with regards to IPR
> declaration, and could be seen an trying to hide this. Trying very
> hard to see a remote conflict of interest, it would be to slow down
> SRv6 to avoid the competitors of my employer to use it. So quite the
> opposite direction.

I'll repeat: conflict of interest refers to a situation where you're 
"judge" and "part" at the same time. It doesn't argue that you have or 
will be intentionally benefiting from such position.

Normally, such situations are avoided, because probing one thing or 
another is, unfortunately, materially impossible,

So that's what my clarification was about. I would have made the same 
comment if someone had flagged the same situation for any other 
document, and a co-author/contributor was shepherding the document or 
calling consensus.

As noted, I disagree with your declaring of consensus to move this 
document forward. But I provided a rationale for my disagreement, and 
never linked the outcome of the consensus call to the aforementioned 
conflict of interest.

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