Mark,
The point that you are making has already been addressed at the mailer (and
indeed you have participated in such discussion)
https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk/
https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw/
https://mailarchive.ietf.org/arch/msg/spring/JdpSLS7ax0VUZLG6SINxnOWJzbY/
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
I don't see the point of starting a new thread from zero that discusses exactly
the same thing.
Cheers,
Pablo.
-----Original Message-----
From: Mark Smith <markzzzsm...@gmail.com>
Date: Tuesday, 25 February 2020 at 00:40
To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>
Cc: Ron Bonica <rbon...@juniper.net>, SPRING WG <spring@ietf.org>
Subject: 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....@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
