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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 04 March 2020 14:06 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 060243A0F89 for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 06:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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 75A9NWST3Ymi for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 06:06:48 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 173A03A0F86 for <spring@ietf.org>; Wed, 4 Mar 2020 06:06:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48XbKM75Ljz6GGDC; Wed, 4 Mar 2020 06:06:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1583330808; bh=CXFDZKKREgd1de3RMFSdl4CgOK1LeQoEjVY4TtapIkA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=AchEX9/sgW73s1YTcxcQle4KIIctD6CYeLl4py8RGyb+ZVKGkCaphuQWRR8WkSVXK e0H8QelqKkS7pVUb2VdLpE2j0iYdtEnKDmY+1XZauPrDlY0zq6AtWW9ian0ZYNIKxq I1yayVkEtaUTGNKb5vX27B2ebnnrIcmoKkLcaLaE=
X-Virus-Scanned: Debian amavisd-new at a2.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 maila2.tigertech.net (Postfix) with ESMTPSA id 48XbKL49Wbz6GGD6; Wed, 4 Mar 2020 06:06:46 -0800 (PST)
To: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>, "spring@ietf.org" <spring@ietf.org>
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <3e2da3a5-5d1b-10a0-aeb4-320c57584241@nokia.com> <8259d37e-b460-5f76-1ce6-b0d026bccf6b@gont.com.ar> <20143_1583250558_5E5E7C7E_20143_390_3_53C29892C857584299CBF5D05346208A48DD80E6@OPEXCAUBM43.corporate.adroot.infra.ftgroup><5d693a5e-baa0-6ffb-4e39-2695795b7413@joelhalpern.com> <MW3PR11MB457071CFC70E5F1F9CBA3A79C1E50@MW3PR11MB4570.namprd11.prod.outlook.com><d38e0835-22e6-cc60-b479-454bec33718f@joelhalpern.com> <MW3PR11MB4570A58DA2DBD870A5D92974C1E50@MW3PR11MB4570.namprd11.prod.outlook.com><80c4817d-c053-a66f-67eb-3e81af2d49d5@joelhalpern.com> <MW3PR11MB45705454C47A38679B6CDF67C1E50@MW3PR11MB4570.namprd11.prod.outlook.com> <7cc38d35-0139-7958-0393-7a24d0a5b276@joelhalpern.com> <335d93d7ee624fb689b8dbcce3aa60cc@huawei.com> <d85835e7-d93a-19e3-28a0-406457ae06b9@joelhalpern.com> <600a5b357fd04bbd910aa11ff142d773@huawei.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <44043fc4-9c8e-c37e-2d20-f077444b6749@joelhalpern.com>
Date: Wed, 04 Mar 2020 09:06:43 -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: <600a5b357fd04bbd910aa11ff142d773@huawei.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/spring/Iz_G98jCJWc3V39uvBvPltFPzBo>
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: Wed, 04 Mar 2020 14:06:53 -0000

Then don't pretend that box is part of the SR Domain.  It clearly isn't.
Yours,
Joel

On 3/4/2020 8:51 AM, Xiejingrong (Jingrong) wrote:
> Hi Joel,
> I guarantee you there is case the performance penalty is more than 90%, only if the box send the IPv6 packet with RH or EH to the slow path (just to be compatible with RFC8200)!
> And I think that's common even for not very old box.
> 
> Thanks
> Jingrong
> 
> -----Original Message-----
> From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com]
> Sent: Wednesday, March 4, 2020 9:39 PM
> To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>; spring@ietf.org
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
> 
> Jingrong, the only "processing" of the SRH required in the ultimate node is to ignore it.  Which is required by 8200.
> 
> Skipping the SRH is not a 50% performance penalty in any situation.
> 
> Yours,
> Joel
> 
> On 3/4/2020 8:36 AM, Xiejingrong (Jingrong) wrote:
>> Hi Joel, Ketan,
>> Let me share my points about the statement "The SRH removal does not remove the expensive part of the work, namely the need to decapsulate and process the inner header."
>> For the ultimate segment endpoint that is well capable of processing SRH, the statement is true I think. I guess the benefits may be around 50%?
>> While for the real network, the incremental deployment may be much more important ---- It is determining, from 1(success) to 0(fail) or vice versa!
>> No matter how good a feature you provided, it just doesn't work on the network with a bunch of PEs that is not capable of SRH, then it is useless.
>>
>> **Maybe my previously suggested text can be referenced** This has some
>> very important benefits for deployment in some networks when the final
>> tunnel end point is a lower-end node which is not capable of
>> processing the SRH for reasons like the hardware is overloaded or
>> unable to upgraded to process well with SRH.
>>
>> In case the final tunnel endpoint router is fully capable of the
>> functionality of SRH and the SRv6-NP defined in this document, it is
>> recommended not to use the PSP.
>> **End for reference**
>>
>> Thanks
>> Jingrong
>>
>> -----Original Message-----
>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M.
>> Halpern
>> Sent: Wednesday, March 4, 2020 4:34 PM
>> To: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>;
>> bruno.decraene@orange.com; spring@ietf.org
>> Subject: Re: [spring] WGLC -
>> draft-ietf-spring-srv6-network-programming
>>
>> Given that we are talking about the ultimate node, all that it is being asked to do is ignore the SRH.  Whether it ignores it because it uses the option 8200 permits to ignore things which are understood, or ignores it because SL=0, it is required to be able to ignore it.
>> In either the encapsulated case or the native termination case, the
>> result of ignoring it is that the proper things will happen.  The IP
>> header will be removed, and what is enclosed will be processed.  (In
>> the native case, the upper layer header.  In the encapsulated case,
>> the inner header.)
>>
>> So I am still confused as to what the advantage to any node is of doing more work in the preceding node, work that is much more than the act of ignoring the header in the final node.  The SRH removal does not remove the expensive part of the work, namely the need to decapsulate and process the inner header.
>>
>> Yours,
>> Joel
>>
>>
>> On 3/4/2020 3:27 AM, Ketan Talaulikar (ketant) wrote:
>>> Hi Joel,
>>>
>>> I would not like to misquote Bruno, but his conclusion on this topic
>>> was very logical, practical and nuanced (again most likely comes from
>>> working with a network operator).
>>>
>>> /QOUTE/
>>>
>>> /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). The fact that this has been implemented by some
>>> platforms and deployed by some operators, is, to me, an indication
>>> that it is useful for those cases. (I believe that an English proverb
>>> is *"the proof of the pudding is in the eating"*. Although I'm
>>> certainly missing part of its meaning and culture, in it's literal
>>> reading, it seems to apply)./
>>>
>>> /UNQOUTE/
>>>
>>> I don’t believe we need to get into the details of the 18 [1]
>>> publicly disclosed (I understand there are more) hardware
>>> implementations from multiple vendors to debate the gains from PSP. I
>>> don’t believe that is appropriate for an IETF mailing list or
>>> pursuant to IETF policy or practice (as you say)?
>>>
>>> Again, I like to make the point of how/why HBH processing was made
>>> optional based on real world considerations when moving from RFC2460
>>> to RFC8200. So options are good and necessary!
>>>
>>> That said, let us turn the tables around.  There is no technical
>>> reason for not allowing PSP with SRH – all the ones that have been
>>> brought up have been answered and clarified in the text as well as on the mailer.
>>> So I fail to understand the resistance of “the other side (including
>>> yourself)”.
>>>
>>> Therefore, I would suggest we go ahead with the declared Spring WG
>>> consensus.
>>>
>>> Thanks,
>>>
>>> Ketan
>>>
>>> [1]
>>> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-s
>>> t
>>> atus-05#section-4.2
>>>
>>> -----Original Message-----
>>> From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
>>> Sent: 04 March 2020 13:26
>>> To: Ketan Talaulikar (ketant) <ketant@cisco.com>;
>>> bruno.decraene@orange.com; Martin Vigoureux
>>> <martin.vigoureux@nokia.com>; spring@ietf.org
>>> Subject: Re: [spring] WGLC -
>>> draft-ietf-spring-srv6-network-programming
>>>
>>> Bruno's statement, which you chose to quote, was that all it takes is
>>> for one person to find something useful.  I was responding to what
>>> the chair said.  It is not true as stated.
>>>
>>> Having said that, I agree that more than one person has asked for this.
>>>
>>> But the actual requirement is that there be a coherent and
>>> understandable explanation of why the feature adds value.  From where
>>> I sit, I have not seen such an explanation.  It is generally the
>>> unbiased chair's job to judge whether sufficient explanation has been
>>> given.  But what Bruno said was not "explanation ... seems sufficient"
>>> but rather the text you quoted.  Which is not an accurate statement
>>> of IETF policy or practice.
>>>
>>> If there is a claim that there is significant problems on the
>>> ultimate node for processing the SRH, I would like to see an
>>> explanation of how an 8200 compliant node would have such problems.
>>> In particular, unlike the MPLS case, the presence or absence of an
>>> SRH with SL=0 has no effect on the number of forwarding lookups that
>>> need to be performed.  And 8200 requires the ability to ignore a routing header with SL=0.
>>>
>>> Yours,
>>>
>>> Joel
>>>
>>> On 3/4/2020 2:49 AM, Ketan Talaulikar (ketant) wrote:
>>>
>>>    > Hi Joel,
>>>
>>>    >
>>>
>>>    > Surely you are exaggerating when you say "one person" asked for
>>>
>>>    > something in the context of PSP? 😊
>>>
>>>    >
>>>
>>>    > Would you like to clarify?
>>>
>>>    >
>>>
>>>    > And also respond on the real life and practical deployment
>>> scenarios and considerations that I've pointed out below? I doubt you
>>> meant to just dismissing them without sharing your views?
>>>
>>>    >
>>>
>>>    > Thanks,
>>>
>>>    > Ketan
>>>
>>>    >
>>>
>>>    > -----Original Message-----
>>>
>>>    > From: Joel M. Halpern <jmh@joelhalpern.com
>>> <mailto:jmh@joelhalpern.com>>
>>>
>>>    > Sent: 04 March 2020 13:16
>>>
>>>    > To: Ketan Talaulikar (ketant) <ketant@cisco.com
>>> <mailto:ketant@cisco.com>>;
>>>
>>>    > bruno.decraene@orange.com <mailto:bruno.decraene@orange.com>;
>>> Martin Vigoureux
>>>
>>>    > <martin.vigoureux@nokia.com <mailto:martin.vigoureux@nokia.com>>;
>>> spring@ietf.org <mailto:spring@ietf.org>
>>>
>>>    > Subject: Re: [spring] WGLC -
>>>
>>>    > draft-ietf-spring-srv6-network-programming
>>>
>>>    >
>>>
>>>    > If we really want to say that it takes only one person asking for
>>> something to put it in a planned RFC, then I guess we have to publish
>>> all of the competing versions of route headers for v6, since we
>>> clealry have more than 1 party asking for each variant?
>>>
>>>    > Put differently, no, putting something in because one person
>>> asked for it (even with the caeat that it appears not to break) is
>>> not how the IETF generally works.  I do not know where Bruno got that
>>> premise, but it does not match the history or written policies of the IETF.
>>>
>>>    >
>>>
>>>    > Yours,
>>>
>>>    > Joel
>>>
>>>    >
>>>
>>>    > On 3/4/2020 2:43 AM, Ketan Talaulikar (ketant) wrote:
>>>
>>>    >> Hi Joel,
>>>
>>>    >>
>>>
>>>    >> I would like to echo the arguments that Bruno has made (and
>>> quote
>>>
>>>    >> part of it) in his summary and then previously on this thread.
>>>
>>>    >>
>>>
>>>    >> /QOUTE/
>>>
>>>    >>
>>>
>>>    >> /The point was related to the usefulness of the optional
>>> feature,
>>>
>>>    >> which has been challenged./
>>>
>>>    >>
>>>
>>>    >> /I was trying to say the required argumentation to declare
>>> usefulness
>>>
>>>    >> or usefulness is asymmetric, from a logical discussion stand
>>> point./
>>>
>>>    >>
>>>
>>>    >> //
>>>
>>>    >>
>>>
>>>    >> /a) It only requires one person to find it useful, in order to
>>> make
>>>
>>>    >> the feature useful (for that person)./
>>>
>>>    >>
>>>
>>>    >> /b) In order to state that this is un-useful,  requires to prove
>>> that
>>>
>>>    >> this is never useful./
>>>
>>>    >>
>>>
>>>    >> /UNQOUTE/
>>>
>>>    >>
>>>
>>>    >> It’s pure logic!
>>>
>>>    >>
>>>
>>>    >> Please check inline below.
>>>
>>>    >>
>>>
>>>    >> -----Original Message-----
>>>
>>>    >> From: spring <spring-bounces@ietf.org
>>> <mailto:spring-bounces@ietf.org>> On Behalf Of Joel M. Halpern
>>>
>>>    >> Sent: 03 March 2020 21:54
>>>
>>>    >> To: bruno.decraene@orange.com
>>> <mailto:bruno.decraene@orange.com>;
>>> Martin Vigoureux
>>>
>>>    >> <martin.vigoureux@nokia.com
>>> <mailto:martin.vigoureux@nokia.com>>;
>>> spring@ietf.org <mailto: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.
>>>
>>>    >>
>>>
>>>    >> */[KT] To start with, there are other/more use-cases for PSP as
>>> have
>>>
>>>    >> been discussed on the list over the course of the WGLC and before then.
>>>
>>>    >> I think you are referring to the use-case that Dan Voyer brought
>>> up
>>>
>>>    >> with legacy hardware - I don't see an issue of being practical
>>> and
>>>
>>>    >> sensitive to real world problems and scenarios. This is what
>>> results
>>>
>>>    >> in actual adoption and deployment success. We have options
>>> everywhere
>>>
>>>    >> - the EH themselves are optional … IIRC HBH options were not so
>>>
>>>    >> recently made optional out of pure consideration of the actual
>>> metal
>>>
>>>    >> out there in the Internet! /**/😊/*
>>>
>>>    >>
>>>
>>>    >> 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.
>>>
>>>    >>
>>>
>>>    >> */[KT] A device can be conformant with RFC8200 even if were
>>> punting
>>>
>>>    >> the packets for local s/w processing in the presence of an EH
>>> (or RH
>>>
>>>    >> in this case). In that case, it would not be doing line-rate
>>>
>>>    >> forwarding which is the requirement here. This is again a very
>>>
>>>    >> practical consideration that is rooted in real world problems
>>> and
>>>
>>>    >> deployments. /*
>>>
>>>    >>
>>>
>>>    >> So no, from where I sit I have not seen a clear explanation of
>>> the
>>>
>>>    >> value for PSP.
>>>
>>>    >>
>>>
>>>    >> */[KT] There have been many use-cases and values expressed for
>>> PSP by
>>>
>>>    >> those that have implemented and deployed it. I can understand if
>>> you
>>>
>>>    >> do not appreciate them. But they are optional and it is unfair
>>> to
>>>
>>>    >> deny it to those who need it./*
>>>
>>>    >>
>>>
>>>    >> 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.
>>>
>>>    >>
>>>
>>>    >> */[KT] I think we can go by the track record through the
>>> progression
>>>
>>>    >> of this draft. The contentious topics related to SRH insertion
>>> were
>>>
>>>    >> removed by the authors based on WG feedback and technical
>>> arguments –
>>>
>>>    >> note this was done after it was a WG document. This WGLC has
>>> gone
>>>
>>>    >> beyond the usual timeframe and resulted in unusually large
>>> amount of
>>>
>>>    >> technical discussions. We do see that the document has undergone
>>>
>>>    >> through multiple changes to improve the text as well as fix
>>> certain
>>>
>>>    >> issues. /*
>>>
>>>    >>
>>>
>>>    >> *//*
>>>
>>>    >>
>>>
>>>    >> */So by no stretch of imagination can we say that the authors
>>> have
>>>
>>>    >> been resistant to change when such a change was technically warranted.
>>>
>>>    >> I do not believe the removal of PSP makes practical and
>>> technical
>>>
>>>    >> sense for those who have implemented and deployed it with real
>>> world
>>>
>>>    >> scenarios in
>>>
>>>    >> mind./*
>>>
>>>    >>
>>>
>>>    >> *//*
>>>
>>>    >>
>>>
>>>    >> */Thanks,/*
>>>
>>>    >>
>>>
>>>    >> */Ketan/*
>>>
>>>    >>
>>>
>>>    >> Yours,
>>>
>>>    >>
>>>
>>>    >> Joel
>>>
>>>    >>
>>>
>>>    >> On 3/3/2020 10:49 AM, bruno.decraene@orange.com
>>> <mailto:bruno.decraene@orange.com>
>>>
>>>    >> <mailto: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
>>> <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>>>
>>>    >>
>>>
>>>    >>   >> Cc: 6man@ietf.org <mailto:6man@ietf.org>
>>> <mailto:6man@ietf.org>; 'ietf@ietf.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/ErcErN39RIlzkL5SKNVAeEWp
>>>
>>>    >> n
>>>
>>>    >>
>>>
>>>    >>   > AI/
>>>
>>>    >>
>>>
>>>    >>   >
>>>
>>>    >>
>>>
>>>    >>   > 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/CMSX7ijacRdG8qHlla61ylJN
>>>
>>>    >> g
>>>
>>>    >>
>>>
>>>    >>   > go/
>>>
>>>    >>
>>>
>>>    >>   >
>>>
>>>    >>
>>>
>>>    >>   >
>>>
>>>    >>
>>>
>>>    >>   > 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/67ZG76XRezPXilsP3x339rG
>>>
>>>    >>
>>>
>>>    >>   >>> pcso/
>>>
>>>    >>
>>>
>>>    >>   >>> [2]
>>>
>>>    >>
>>>
>>>    >>   >>>
>>>
>>>    >>
>>> https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76F
>>>
>>>    >>
>>>
>>>    >>   >>> ZmQ0/
>>>
>>>    >>
>>>
>>>    >>   >>> [3]
>>>
>>>    >>
>>>
>>>    >>   >>>
>>>
>>>    >>
>>> https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jS
>>>
>>>    >>
>>>
>>>    >>   >>> IKBc/
>>>
>>>    >>
>>>
>>>    >>   >>>
>>>
>>>    >>
>>>
>>>    >>   >>> Le 2019-12-05 à 18:15, bruno.decraene@orange.com
>>> <mailto:bruno.decraene@orange.com>
>>>
>>>    >> <mailto: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-programm
>>>
>>>    >>
>>>
>>>    >>   >>>> ing-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 <mailto:spring@ietf.org>
>>> <mailto:spring@ietf.org>
>>>
>>>    >>
>>>
>>>    >>   >>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>>    >>
>>>
>>>    >>   >>>>
>>>
>>>    >>
>>>
>>>    >>   >>>
>>>
>>>    >>
>>>
>>>    >>   >>> _______________________________________________
>>>
>>>    >>
>>>
>>>    >>   >>> spring mailing list
>>>
>>>    >>
>>>
>>>    >>   >>> spring@ietf.org <mailto:spring@ietf.org>
>>> <mailto:spring@ietf.org>
>>>
>>>    >>
>>>
>>>    >>   >>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>>    >>
>>>
>>>    >>   >>> .
>>>
>>>    >>
>>>
>>>    >>   >>>
>>>
>>>    >>
>>>
>>>    >>   >>
>>>
>>>    >>
>>>
>>>    >>   >>
>>>
>>>    >>
>>>
>>>    >>   >> --
>>>
>>>    >>
>>>
>>>    >>   >> Fernando Gont
>>>
>>>    >>
>>>
>>>    >>   >> e-mail: fernando@gont.com.ar <mailto:fernando@gont.com.ar>
>>> <mailto:fernando@gont.com.ar> ||
>>>
>>>    >> fgont@si6networks.com <mailto:fgont@si6networks.com>
>>> <mailto:fgont@si6networks.com> PGP
>>>
>>>    >>
>>>
>>>    >>   >> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076
>>> FFF1
>>>
>>>    >>
>>>
>>>    >>   >>
>>>
>>>    >>
>>>
>>>    >>   >>
>>>
>>>    >>
>>>
>>>    >>   >>
>>>
>>>    >>
>>>
>>>    >>   >> _______________________________________________
>>>
>>>    >>
>>>
>>>    >>   >> spring mailing list
>>>
>>>    >>
>>>
>>>    >>   >> spring@ietf.org <mailto:spring@ietf.org>
>>> <mailto: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.
>>>
>>>    >>
>>>
>>>    >>   >
>>>
>>>    >>
>>>
>>>    >> _______________________________________________
>>>
>>>    >>
>>>
>>>    >> spring mailing list
>>>
>>>    >>
>>>
>>>    >> spring@ietf.org <mailto:spring@ietf.org>
>>> <mailto:spring@ietf.org>
>>>
>>>    >>
>>>
>>>    >> https://www.ietf.org/mailman/listinfo/spring
>>>
>>>    >>
>>>
>>>
>>> _______________________________________________
>>> 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
>>