On Tue, 25 Feb 2020 at 09:38, Pablo Camarillo (pcamaril) <pcamaril=40cisco....@dmarc.ietf.org> wrote: > > Ron, > > > > This is the 5th time that we have this discussion in the past five months. > > > > I consider those three questions as closed based on the previous discussion. > > https://mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/ > >
Ron isn't the only arbiter that you and the SPRING WG have to satisfy. If the discussion has come up 5 times in the past 5 months, yet hasn't been resolved, then I think it says SPRING aren't trying to act in good faith to attempt to comply with another IETF working group's widely deployed, full Internet Standard protocol, one of only 92 Internet Standards since 1969. I'm reminded of when the ITU did something similar to the IETF. I think it is now one IETF WG doing a similar thing to another. RFC5704, "Uncoordinated Protocol Development Considered Harmful" https://tools.ietf.org/html/rfc5704 s/SDO/IETF WG/gc "In particular, the IAB considers it an essential principle of the protocol development process that only one SDO maintains design authority for a given protocol, with that SDO having ultimate authority over the allocation of protocol parameter code-points and over defining the intended semantics, interpretation, and actions associated with those code- points." SPRING are also ignoring its own charter: "SPRING WG should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SPRING function." PSP is not required, there are existing functional equivalents that are compatible with existing deployments. (I have no affiliation with any vendors, I fight for the users.) > > Cheers, > > Pablo. > > > > From: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> > Date: Monday, 24 February 2020 at 16:27 > To: Andrew Alston <andrew.als...@liquidtelecom.com>, Mark Smith > <markzzzsm...@gmail.com>, Sander Steffann <san...@steffann.nl> > Cc: SPRING WG <spring@ietf.org>, "Pablo Camarillo (pcamaril)" > <pcama...@cisco.com> > Subject: RE: [spring] I-D Action: > draft-ietf-spring-srv6-network-programming-10.txt > > > > Folks, > > > > We may need to ask the following questions: > > > > 1) Does PSP violate letter of RFC 8200? > > 2) Does PSP violate the spirit of RFC 8200? > > 3) Is PSP a good idea? > > > > The 6man WG, and not SPRING, should answer the first two questions. So I will > avoid them an explore the third. > > > > At first glance, PSP adds no value. Once Segments Left has been decremented > to 0, the Routing header becomes a NOOP. So why bother to remove it? I see > the following arguments: > > > > 1) To save bandwidth between the penultimate and ultimate segment > endpoints. > > 2) To unburden the ultimate segment endpoint from the task of processing > the SRH > > 3) To unburden the ultimate segment endpoint from the task of removing > the SRH > > > > The first argument is weak. Routing headers should not be so large that the > bandwidth they consume is an issue. > > > > The second argument is also weak. Once the ultimate segment endpoint has > examined the Segments Left field, it can ignore the SRH. The ultimate segment > endpoint must be SRv6-aware, because it must process the SID in the IPv6 > destination address field. Given that the ultimate segment endpoint is SRv6 > aware, it should be able to process the SRH on the fast path. > > > > The third argument is even weaker. The ultimate segment endpoint: > > - Has to remove the IPv6 tunnel header, anyway > > - Being closer to the edge, may be less heavily loaded than the > penultimate segment endpoint. > > > > Can anyone articulate a better justification for PSP? If not, why test the > limits of RFC 8200 over it? > > > > > Ron > > > > > > > > > > Juniper Business Use Only > > From: spring <spring-boun...@ietf.org> On Behalf Of Andrew Alston > Sent: Monday, February 24, 2020 5:06 AM > To: Mark Smith <markzzzsm...@gmail.com>; Sander Steffann <san...@steffann.nl> > Cc: SPRING WG <spring@ietf.org>; Pablo Camarillo (pcamaril) > <pcamaril=40cisco....@dmarc.ietf.org> > Subject: Re: [spring] I-D Action: > draft-ietf-spring-srv6-network-programming-10.txt > > > > I agree with the sentiments expressed below > > > > Andrew > > > > > > From: spring <spring-boun...@ietf.org> On Behalf Of Mark Smith > Sent: Monday, 24 February 2020 00:50 > To: Sander Steffann <san...@steffann.nl> > Cc: SPRING WG <spring@ietf.org>; Pablo Camarillo (pcamaril) > <pcamaril=40cisco....@dmarc.ietf.org> > Subject: Re: [spring] I-D Action: > draft-ietf-spring-srv6-network-programming-10.txt > > > > > > On Mon, 24 Feb 2020, 07:47 Sander Steffann, <san...@steffann.nl> wrote: > > Hi, > > > We have published a new update to > > draft-ietf-spring-srv6-network-programming. This revision simplifies the > > counters as per [1], clarifies the upper layer header processing as per [2] > > and removes the reference to the OAM draft [3]. > > I still oppose the segment popping flavours in section 4.16 without updating > RFC8200. > > > > I would expect that defying Internet Standard 86/RFC8200 means this ID needs > to have Experimental rather than Standards Track status. > > > > > > > > > Cheers, > Sander > > _______________________________________________ > 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 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
