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

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 03 March 2020 17:29 UTC

Return-Path: <jmh@joelhalpern.com>
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 18B583A23F7 for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 09:29:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 GjgX5LLBg4iG for <spring@ietfa.amsl.com>; Tue, 3 Mar 2020 09:29:02 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DF63A23F3 for <spring@ietf.org>; Tue, 3 Mar 2020 09:29:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 48X3sB4xv0z1p0WQ; Tue, 3 Mar 2020 09:29:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1583256542; bh=Wwqiu/F995pdOIfgGJtTcT0ZhdrXUdsqfpGV6L7DgOY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=N0nER49/doVNx23mXZqOkb+WNsySjAZr5mK72eESTC/eA+obN7rjE3nhtJ4h1ddQN +W1hfKsc9OFG+Zk0L+aojeRQZRpztBAgV1joLLFhUNkdpdjHmECxVSOMRpPHkp0xgZ /gGqkJEkdTIzo2jo2JVQYLngpl5CUeUDQLqb7giA=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 48X3sB0B3Rz1p0L6; Tue, 3 Mar 2020 09:29:01 -0800 (PST)
To: bruno.decraene@orange.com, Martin Vigoureux <martin.vigoureux@nokia.com>, "spring@ietf.org" <spring@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?= <3e2da3a5-5d1b-10a0-aeb4-320c57584241@nokia.com> =?utf-8?q?=3C8259d37e-b460-5f76-1ce6-b0d026bccf6b=40gont=2Ecom=2Ear=3E_=3C2?= =?utf-8?q?0143=5F1583250558=5F5E5E7C7E=5F20143=5F390=5F3=5F53C29892C8575842?= =?utf-8?q?99CBF5D05346208A48DD80E6=40OPEXCAUBM43=2Ecorporate=2Eadroot=2Einf?= =?utf-8?q?ra=2Eftgroup=3E?= =?utf-8?q?=3C5d693a5e-baa0-6ffb-4e39-2695795b7413=40joelhalpern=2Ecom=3E_?= =?utf-8?q?=3C7501=5F1583255845=5F5E5E9125=5F7501=5F499=5F1=5F53C29892C85758?= =?utf-8?q?4299CBF5D05346208A48DD84FF=40OPEXCAUBM43=2Ecorporate=2Eadroot=2Ei?= =?utf-8?q?nfra=2Eftgroup=3E?=
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <fc5bf8d9-073f-2eff-6041-e1610bf6e116@joelhalpern.com>
Date: Tue, 3 Mar 2020 12:29:00 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: =?utf-8?q?=3C7501=5F1583255845=5F5E5E9125=5F7501=5F499=5F1=5F53?= =?utf-8?q?C29892C857584299CBF5D05346208A48DD84FF=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: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/8V3_LnzZuZGqhsO_S-8x2n58kQM>
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: Tue, 03 Mar 2020 17:29:05 -0000

Note, I said "is not usually, in and of itself".  Recognizing that there 
are exceptions.  There appears to be significant disagreement as to 
whether the MPLS case was a good one. )There are lots of other aspects 
for that case which do not apply here.)

Yours,
Joel

On 3/3/2020 12:17 PM, bruno.decraene@orange.com wrote:
>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Sent: Tuesday, March 3, 2020 5:24 PM
>> To: DECRAENE Bruno TGI/OLN; Martin Vigoureux; spring@ietf.org
>> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>>
>> I'm sorry, but "in my gear I want an option to move some work around, so
>> I need a protocol behavior for that" is not usually, in and of itself,
>> enough reason to add an optional feature to a protocol.
> 
> I can't speak on 'usually', but it certainly happened before. Cf the "Penultimate Hop Popping" section in RFC3031 (MPLS):
> 
> "   However, some hardware switching engines may not be able to pop the
>     label stack, so this cannot be universally required."
> https://tools.ietf.org/html/rfc3031#section-3.16
> 
> Yours,
> --Bruno
> 
>> At one point there was an argument that PSP was needed for compliant
>> devices that would not be able to process the packet.  It has been
>> pointed out since that such devices would not comply to 8200 (not
>> because of PSP, but because being able to ignore an exhausted routing
>> header is required in 8200).  Having an optional feature to take care of
>> devices which violate a standard again requires some strong evidence to
>> justify it.
>>
>> So no, from where I sit I have not seen a clear explanation of the value
>> for PSP.
>>
>> I also do not understand why the authors have resisted the usual
>> solution to this sort of disagreement, namely moving the feature to a
>> separate document.  Given the structure of the network programming
>> draft, and that it is not exhaustive in either flavors or programming
>> behaviors, there is no violence done to the draft by removing this flavor.
>>
>> Yours,
>> Joel
>>
>> On 3/3/2020 10:49 AM, bruno.decraene@orange.com wrote:
>>> Fernando
>>>
>>>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Fernando Gont
>>>> Sent: Monday, March 2, 2020 9:23 PM
>>>> To: Martin Vigoureux; spring@ietf.org
>>>> Cc: 6man@ietf.org; 'ietf@ietf.org'org'; draft-ietf-spring-srv6-network-programming
>>>> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>>>>
>>>> Martin,
>>>>
>>>> As an Area Director, what are your thoughts regarding Bruno's claim that
>>>> this working group (Spring) doesn't have the necessary skills for
>>>> evaluating the need of a functionality (PSP) that this wg is including
>>>> in draft-ietf-spring-srv6-network-programming?
>>>>
>>>> Specifically, Bruno has noted (in
>>>> https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/):
>>>>
>>>> ---- cut here ----
>>>> 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).
>>>> ---- cut here ----
>>>>
>>>>
>>>> Doesn't this sound a bit like a group is shipping something that it
>>>> cannot really understand?
>>>
>>>
>>> There have been replied and statement from the WG. E.g. From Dan (network operator) & Jingrong (vendor).
>>> https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/
>>>
>>> My comment is that a statement such as "(1) reduce the load of final destination.", while true in general, is difficult to evaluate, e.g. in term of packet processing gain, or NPU processing resource gain.
>>> One can say "not on my hardware", but nobody can say "not in your hardware".
>>>
>>> And I think that this is along Joel reply (although I would not want to speak for Joel)
>>> "Do you have any comments on what appears to be the significant increase
>>> in complexity on the device performing PSP?  The question I am trying to
>>> get at is about the tradeoff, which needs one to evaluate both sides."
>>> https://mailarchive.ietf.org/arch/msg/spring/CMSX7ijacRdG8qHlla61ylJNggo/
>>>
>>>
>>> So in the end, what we have is the statement "(1) reduce the load of final destination.".
>>>
>>> Thanks,
>>> --Bruno
>>>    
>>>> Thanks,
>>>> Fernando
>>>>
>>>>
>>>>
>>>>
>>>> On 2/3/20 15:53, Martin Vigoureux wrote:
>>>>> WG,
>>>>>
>>>>> as I had indicated in a previous message I am the one evaluating
>>>>> consensus for this WG LC.
>>>>>
>>>>> I have carefully read the discussions on the list. I acknowledge that
>>>>> disagreements were expressed regarding what a particular piece of text
>>>>> of RFC 8200 says, and on which this document builds to propose an
>>>>> optional capability. Since RFC 8200 is not a product of the SPRING WG, I
>>>>> have paid specific attention to the messages ([1], [2], and [3]) sent by
>>>>> the responsible AD of 6MAN and of RFC8200.
>>>>>
>>>>> My overall conclusion is that there is support and rough consensus to
>>>>> move this document to the next stage.
>>>>>
>>>>> Bruno will handle the immediate next steps.
>>>>>
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>> [1]
>>>>> https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
>>>>> [2]
>>>>> https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
>>>>> [3]
>>>>> https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/
>>>>>
>>>>> Le 2019-12-05 à 18:15, bruno.decraene@orange.com a écrit :
>>>>>> Hello SPRING,
>>>>>>
>>>>>> This email starts a two weeks Working Group Last Call on
>>>>>> draft-ietf-spring-srv6-network-programming [1].
>>>>>>
>>>>>> Please read this document if you haven't read the most recent version,
>>>>>> and send your comments to the SPRING WG list, no later than December 20.
>>>>>>
>>>>>> You may copy the 6MAN WG for IPv6 related comment, but consider not
>>>>>> duplicating emails on the 6MAN mailing list for the comments which are
>>>>>> only spring specifics.
>>>>>>
>>>>>> If you are raising a point which you expect will be specifically
>>>>>> debated on the mailing list, consider using a specific email/thread
>>>>>> for this point.
>>>>>>
>>>>>> This may help avoiding that the thread become specific to this point
>>>>>> and that other points get forgotten (or that the thread get converted
>>>>>> into parallel independent discussions)
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Bruno
>>>>>>
>>>>>> [1]
>>>>>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05
>>>>>>
>>>>>> _________________________________________________________________________________________________________________________
>>>>>>
>>>>>>
>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>>> confidentielles ou privilegiees et ne doivent donc
>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>>>>> recu ce message par erreur, veuillez le signaler
>>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>>>>>> messages electroniques etant susceptibles d'alteration,
>>>>>> Orange decline toute responsabilite si ce message a ete altere,
>>>>>> deforme ou falsifie. Merci.
>>>>>>
>>>>>> This message and its attachments may contain confidential or
>>>>>> privileged information that may be protected by law;
>>>>>> they should not be distributed, used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender and
>>>>>> delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that have
>>>>>> been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> spring mailing list
>>>>>> spring@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> spring mailing list
>>>>> spring@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>> .
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Fernando Gont
>>>> e-mail: fernando@gont.com.ar || fgont@si6networks.com
>>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> spring mailing list
>>>> spring@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>> Thank you.
>>>   
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>