On 03-Mar-20 09:02, Pablo Camarillo (pcamaril) wrote:
> Brian,
>
> The PSP pseudocode is presented as a modification to the End pseudocode
> starting at line S14 of such.
> Please go through the PSP pseudocode in conjunction with the End pseudocode
> (Section 4.1).
> You will see that the ingress state of the packet is (Segments Left == 1 and
> Destination Address == the PSP node's address).
Exactly my point. With SL == 1, you are not at the ultimate destination, so
according to what I'll call "Fernando's reading" of RFC8200, you are not
entitled to delete the header. That is the point that IMHO needs to be stated
explicitly in the draft. You are using "Darren's reading" of RFC8200.
I really think you need to say so explicitly. Something like:
Note: this behavior does not contravene section 4 of [RFC8200]
because the current destination address of the incoming packet
is the address of the node executing the PSP behavior.
This will not change the argument, but it will make the issue clear so that we
(the IETF) can decide whether to accept it or not. And that is orthogonal to
whether RFC 8200 is wrong.
Regards
Brian
>
> Many thanks,
> Pablo.
>
> -----Original Message-----
> From: ipv6 <ipv6-boun...@ietf.org> on behalf of Brian E Carpenter
> <brian.e.carpen...@gmail.com>
> Date: Monday, 2 March 2020 at 20:34
> To: "Darren Dukes (ddukes)" <ddukes=40cisco....@dmarc.ietf.org>, 6man WG
> <i...@ietf.org>, SPRING WG List <spring@ietf.org>
> Subject: Re: PSP and a logical application of RFC8200
>
> 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
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> 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
