Hi Pablo
Looking over the benefits list, Irrespective of any other merits, I'd actually
suspect that 1.3/example 2 is kind of a specious benefit.
My reasoning is if fragmentation has occurred, and the NSH has been replicated
in all fragments and needs to be removed from each fragment by the penultimate
SR. This offers minimal benefit to the reassembly function at the ultimate
Segment Router.
IMO SRH removal at an intermediate device is a more complex operation. In a
simplistic description of operation it adds at a minimum, parsing and a memcpy
of the payload. In effect it replaces Start_of_payload_ptr += length (SRH) at
the ultimate SR with memcpy (start_of_SRH_ptr, start_of_SRH_ptr+length(SRH),
length(SRH)) at the penultimate SR.
So skipping over the exhausted SRH would appear to be trivial compared to the
work at the penultimate segment router to remove it entirely. IMO it does not
offer benefits equivalent to PHP in MPLS
The same argument could be considered without fragmentation, but fragmentation
becomes a particularly ugly example.
Hope this helps
Dave
-----Original Message-----
From: spring <spring-boun...@ietf.org> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Wednesday, December 11, 2019 12:12 PM
To: Xiejingrong (Jingrong) <xiejingr...@huawei.com>; Joel M. Halpern
<j...@joelhalpern.com>; spring@ietf.org
Subject: Re: [spring] Is srv6 PSP a good idea
Jingrong,
> Nothing new, but benefits that people have already said seems notable to me.
Agreed.
Cheers,
Pablo.
-----Original Message-----
From: spring <spring-boun...@ietf.org> on behalf of "Xiejingrong (Jingrong)"
<xiejingr...@huawei.com>
Date: Wednesday, 11 December 2019 at 05:15
To: "Joel M. Halpern" <j...@joelhalpern.com>, "spring@ietf.org"
<spring@ietf.org>
Subject: Re: [spring] Is srv6 PSP a good idea
I think it's a good idea.
Nothing new, but benefits that people have already said seems notable to me.
(1) reduce the load of final destination. This benefit can be notable for
the following sub reasons.
(1.1) final destination tends to have heavy load. It need to handle all the
EHs and do the delivery/demultiplex the packet to the right overlay service.
(1.2) example 1, the final destination may need to handle the DOH after the
RH.
(1.3) example 2, the final destination may need to do the assembly of
fragmented packets.
(1.4) example 3, the final destination may need to do AH/ESP after the
Fragmentation Header.
(1.5) example 4, the final destination may need to deliver the packet to
the right overlay service.
(2) support the incremental deployment when final destination(s) do not
process/recognize SRH. This benefit can be notable for the following sub
reasons.
(2.1) A core router may (fan-out) connected with a big number of low-end
routers that do not support SRH but support tunnel-end/service-demultiplex
function of SRv6.
Thanks
Jingrong
-----Original Message-----
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Wednesday, December 11, 2019 10:55 AM
To: spring@ietf.org
Subject: [spring] Is srv6 PSP a good idea
For purposes of this thread, even if you think PSP violates RFC 8200, let
us assume that it is legal.
As I understand it, the PSP situation is:
o the packet arrives at the place (let's not argue about whether SIDs are
locators) identified by the SID in the destination address field o that SID is
the next to last SID in the SID list o that sid is marked as / known to be PSP
o at the intended place in the processing pseudocode, the last (first) entry in
the SRH is copied into the destination IPv6 address field of the packet
-> The SRH being used is then removed from the packet.
In order to evaluate whether this is a good idea, we have to have some idea
of the benefit. It may be that I am missing some of the benefit, and I would
appreciate clarification.
As far as I can tell, the benefit of this removal is that in exchange for
this node doing the work of removing the SRH, the final node in the SRH does
not have to process the SRH at all, as it has been removed.
I have trouble seeing how that work tradeoff can be beneficial.
Removing bytes from the middle of a packet is a complex operation.
Doing so in Silicon (we expect this to be done in the fast path of
significant forwarders as I understand it) requires very special provision.
Even in software, removing bytes from the middle of a packet requires somewhere
between some and a lot of extra work. It is distinctly NOT free.
In contrast, we have assumed that the work of processing SRH itself is
tractable, since otherwise all of SRv6 would be problematic. So why is this
necessary.
Yours,
Joel
PS: Note that both the MPLS case and the encapsulation case are very
different in that the material being removed is at the front of the IP packet.
Pop or prepend are MUCH easier than middle-removal (or middle-insertion).
_______________________________________________
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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
