Darren,
Regardless of whether you accept Fernando's comment about the intention of RFC
8200, there is also the fact that the description of the PSP flavor cheats by
considering the packet to have
(Segments Left == 0 and Destination Address == the PSP node's address).
In fact that is *never* the state of the packet on the wire, which is either
(Segments Left == 1 and Destination Address == the PSP node's address)
or
(Segments Left == 0 and Destination Address == the final node's address)
OK, maybe it's not cheating, maybe it's only a side effect of the pseudocode,
but the fact is that the test "S14.1. If (Segments Left == 0) {" in section
4.16.1 is very confusing because it's applied to a packet that is half way
through processing of the routing header (Segments Left has been updated, but
Destination Address has not been updated). This makes it very unclear how the
spec is claiming to interpret RFC 8200.
Regards
Brian Carpenter
On 03-Mar-20 03:52, Darren Dukes (ddukes) wrote:
> What follows has been made clear on the list for a while,
> I am re-stating it.
>
> The draft-ietf-spring-srv6-network-programming PSP behavior
> strictly follows the letter of RFC 8200.
>
> RFC8200 section 4 says:
>
> Extension headers (except for the Hop-by-Hop Options header) are not
> *processed, inserted, or deleted* by any node along a packet's delivery
> path, until the packet reaches *the node* (or each of the set of nodes,
> in the case of multicast) *identified in the Destination Address field*
> * of the IPv6 header.*
>
>
> The processing, insertion and deletion restrictions only apply
> “until the packet reaches the node identified in the Destination
> Address field of the IPv6 header”.
>
> At the penuptimate segment of the segment list, the endpoint IS
> “the node identified in the Destination Address field of the IPv6
> header” and hence the PSP operation programmed by the source SR
> node strictly follows the letter of RFC 8200.
>
>
> Thanks,
> Darren
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
