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

["Joel M. Halpern" <[e-mail]>]

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, [e-mail] wrote:
>> From: Joel M. Halpern [mailto:[e-mail]]
>> Sent: Tuesday, March 3, 2020 5:24 PM
>> To: DECRAENE Bruno TGI/OLN; Martin Vigoureux; [e-mail]
>> 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, [e-mail] wrote:
>>> Fernando
>>>
>>>> From: spring [mailto:[e-mail]] On Behalf Of Fernando Gont
>>>> Sent: Monday, March 2, 2020 9:23 PM
>>>> To: Martin Vigoureux; [e-mail]
>>>> Cc: [e-mail]; '[e-mail]'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, [e-mail] 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> spring mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>> .
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Fernando Gont
>>>> e-mail: [e-mail] || [e-mail]
>>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> spring mailing list
>>>> [e-mail]
>>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>