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

[Ron Bonica <[e-mail]>]

Folks,

A WG can set its bar for acceptance anywhere it wants. Some WG's manage technologies where the need to innovation exceeds the need for stability. In those WG's, the bar is appropriately set low. Other WG's manage technologies where the need for stability exceeds the need for innovation. In those WG's, the bar is appropriately set high. That's all good.

However, when a WG moves the bar for unspecified reasons, it becomes dysfunctional. If the bar for PSP is low, the bar for alternative Routing header types should be equally low.

But this is really a topic upon which the AD and WG chair should be speaking. Maybe they want to chime in?

                                                   Ron



Juniper Business Use Only

-----Original Message-----
From: spring <[e-mail]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Wednesday, March 4, 2020 2:50 AM
To: Joel M. Halpern <[e-mail]>; [e-mail]; Martin Vigoureux <[e-mail]>; [e-mail]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

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 <[e-mail]>
Sent: 04 March 2020 13:16
To: Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]; Martin Vigoureux <[e-mail]>; [e-mail]
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 <[e-mail]> On Behalf Of Joel M. Halpern
> Sent: 03 March 2020 21:54
> To: [e-mail]; Martin Vigoureux 
> <[e-mail]>; [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.
> 
> */[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, [e-mail] 
> <mailto:[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] <mailto:[e-mail]>
> 
>  >> Cc: [e-mail] <mailto:[e-mail]>; '[e-mail]';
> 
>  >> 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!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxykYS4q3oqNE6urz$ ):
> 
>  >>
> 
>  >> ---- 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/spri
> ng/ErcErN39RIlzkL5SKNVAeEWpn__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1n
> wNO_r94uSmb4o6oAlGVSAktxykYS4q3oj3Fz7Ru$
> 
>  > 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
> ng/CMSX7ijacRdG8qHlla61ylJNg__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1n
> wNO_r94uSmb4o6oAlGVSAktxykYS4q3omdHTq66$
> 
>  > 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
> ng/67ZG76XRezPXilsP3x339rG__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwN
> O_r94uSmb4o6oAlGVSAktxykYS4q3ooesyxsd$
> 
>  >>> pcso/
> 
>  >>> [2]
> 
>  >>>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
> ng/plidxjZFBnd4_mEzGsLC76F__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwN
> O_r94uSmb4o6oAlGVSAktxykYS4q3ouHMfFRe$
> 
>  >>> ZmQ0/
> 
>  >>> [3]
> 
>  >>>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
> ng/uBYpxPyyBY6bb86Y2iCh3jS__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwN
> O_r94uSmb4o6oAlGVSAktxykYS4q3omdTRgI-$
> 
>  >>> IKBc/
> 
>  >>>
> 
>  >>> Le 2019-12-05 à 18:15, [e-mail] 
> <mailto:[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-ietf-spr
> ing-srv6-network-programm__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO
> _r94uSmb4o6oAlGVSAktxykYS4q3oqs6U8hu$
> 
>  >>>> 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
> 
>  >>>> [e-mail] <mailto:[e-mail]>
> 
>  >>>> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxyk
> YS4q3ouCAL3e5$
> 
>  >>>>
> 
>  >>>
> 
>  >>> _______________________________________________
> 
>  >>> spring mailing list
> 
>  >>> [e-mail] <mailto:[e-mail]>
> 
>  >>> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxyk
> YS4q3ouCAL3e5$
> 
>  >>> .
> 
>  >>>
> 
>  >>
> 
>  >>
> 
>  >> --
> 
>  >> Fernando Gont
> 
>  >> e-mail: [e-mail] <mailto:[e-mail]> || 
> [e-mail] <mailto:[e-mail]> PGP
> 
>  >> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
>  >>
> 
>  >>
> 
>  >>
> 
>  >> _______________________________________________
> 
>  >> spring mailing list
> 
>  >> [e-mail] <mailto:[e-mail]>
> 
>  >> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxyk
> YS4q3ouCAL3e5$
> 
>  >
> 
>  >
> ______________________________________________________________________
> 
>  > ___________________________________________________
> 
>  >
> 
>  > 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] <mailto:[e-mail]>
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxyk
> YS4q3ouCAL3e5$
> 
_______________________________________________
spring mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!RoMsrLt00PwzObp12rXzsVN1nwNO_r94uSmb4o6oAlGVSAktxykYS4q3ouCAL3e5$