Re: PSP and a logical application of RFC8200

[Fernando Gont <[e-mail]>]

On 2/3/20 11: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.*

That is certainly not the intended behavior of RFC8200.

In fact, you may see that Appendix B says:

    o  Clarified that 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.


and the routing headers (Section 4.4) are specified as:

    The Routing header is used by an IPv6 source to list one or more
    intermediate nodes to be "visited" on the way to a packet's
    destination.


As it may be obvious, teh wording in RFC8200 is indeed prone to 
confusion, and hence should be fixed (this is not the only bug in the 
EH-processing part of RFC8200, as noted by Brian, myself, and others).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492