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<mailto:spring-boun...@ietf.org>> On
Behalf Of Mark Smith
Sent: Monday, 24 February 2020 00:50
To: Sander Steffann <san...@steffann.nl<mailto:san...@steffann.nl>>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; Pablo Camarillo
(pcamaril)
<pcamaril=40cisco....@dmarc.ietf.org<mailto: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<mailto: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<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Tfl9m_at6pZSp38lOtxE5WZLnsW_ojrgXUvQ_Rx-tN4MY7qa-MtwIQWgGCTduGJT$>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
