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

[Ron Bonica <[e-mail]>]

Folks,

I don't think that you can compare MPLS PHP with SRv6 PSP. MPLS PHP is a clear case of de-encapsulation. We do that all the time. In SRv6 PSP, we are removing something from the middle of a packet. That is quite a different story.

                                                                                                                                      Ron


Juniper Business Use Only

-----Original Message-----
From: spring <[e-mail]> On Behalf Of Joel M. Halpern
Sent: Tuesday, March 3, 2020 12:29 PM
To: [e-mail]; Martin Vigoureux <[e-mail]>om>; [e-mail]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

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://urldefense.com/v3/__https://tools.ietf.org/html/rfc3031*sectio
> n-3.16__;Iw!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6iuY
> Atn0aGSZEOQCiyxWF1i$
> 
> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCsdZKzc2$ ):
>>>>
>>>> ---- 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/sp
>>> ring/ErcErN39RIlzkL5SKNVAeEWpnAI/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOz
>>> OPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCqGhzAlS$
>>>
>>> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/sp
>>> ring/CMSX7ijacRdG8qHlla61ylJNggo/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOz
>>> OPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCsnVf_mA$
>>>
>>>
>>> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/
>>>>> spring/67ZG76XRezPXilsP3x339rGpcso/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7y
>>>>> ckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCqR0ymms$
>>>>> [2]
>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/
>>>>> spring/plidxjZFBnd4_mEzGsLC76FZmQ0/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7y
>>>>> ckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCkr-7fYe$
>>>>> [3]
>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/
>>>>> spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/__;!!NEt6yMaO-gk!R8IpdFJzyoCo7y
>>>>> ckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCizDGW--$
>>>>>
>>>>> 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-iet
>>>>>> f-spring-srv6-network-programming-05__;!!NEt6yMaO-gk!R8IpdFJzyoCo
>>>>>> 7yckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCvuKcbMU$
>>>>>>
>>>>>> _________________________________________________________________
>>>>>> ________________________________________________________
>>>>>>
>>>>>>
>>>>>> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo
>>>>>> /spring__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b
>>>>>> 6iuYAtn0aGSZEOQCie_a0dh$
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> spring mailing list
>>>>> [e-mail]
>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
>>>>> spring__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6i
>>>>> uYAtn0aGSZEOQCie_a0dh$
>>>>> .
>>>>>
>>>>
>>>>
>>>> --
>>>> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/s
>>>> pring__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6iuY
>>>> Atn0aGSZEOQCie_a0dh$
>>>
>>> ____________________________________________________________________
>>> _____________________________________________________
>>>
>>> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aG
> SZEOQCie_a0dh$
> 

_______________________________________________
spring mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!R8IpdFJzyoCo7yckOzOPMieJAOSnyq5AODMxwdW0b6iuYAtn0aGSZEOQCie_a0dh$