Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

On Tue, 25 Feb 2020 at 09:38, Pablo Camarillo (pcamaril)
<pcamaril=40cisco.com@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.net@dmarc.ietf.org>
> Date: Monday, 24 February 2020 at 16:27
> To: Andrew Alston <Andrew.Alston@liquidtelecom.com>, Mark Smith <markzzzsmith@gmail.com>, Sander Steffann <sander@steffann.nl>
> Cc: SPRING WG <spring@ietf.org>, "Pablo Camarillo (pcamaril)" <pcamaril@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-bounces@ietf.org> On Behalf Of Andrew Alston
> Sent: Monday, February 24, 2020 5:06 AM
> To: Mark Smith <markzzzsmith@gmail.com>; Sander Steffann <sander@steffann.nl>
> Cc: SPRING WG <spring@ietf.org>; Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@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-bounces@ietf.org> On Behalf Of Mark Smith
> Sent: Monday, 24 February 2020 00:50
> To: Sander Steffann <sander@steffann.nl>
> Cc: SPRING WG <spring@ietf.org>; Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@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, <sander@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