Inline.
Thanks.
-----Original Message-----
From: Brian E Carpenter <brian.e.carpen...@gmail.com>
Date: Thursday, 19 December 2019 at 22:39
To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>, "spring@ietf.org"
<spring@ietf.org>
Subject: Re: [spring] I-D Action:
draft-ietf-spring-srv6-network-programming-06.txt
Sorry, I am still confused, see in line:
On 20-Dec-19 00:53, Pablo Camarillo (pcamaril) wrote:
> Brian,
>
> Inline.
>
> Thank you,
> Pablo.
>
> -----Original Message-----
> From: Brian E Carpenter <brian.e.carpen...@gmail.com>
> Date: Saturday, 14 December 2019 at 21:04
> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>, "spring@ietf.org"
<spring@ietf.org>
> Subject: Re: [spring] I-D Action:
draft-ietf-spring-srv6-network-programming-06.txt
>
> Hi Pablo,
>
> See in line:
>
> On 14-Dec-19 22:34, Pablo Camarillo (pcamaril) wrote:
> > Brian,
> >
> > Many thanks for having another look to the draft. Please see inline
[PC].
> >
> > Thank you,
> > Pablo.
> >
> > -----Original Message-----
> > From: spring <spring-boun...@ietf.org> on behalf of Brian E
Carpenter <brian.e.carpen...@gmail.com>
> > Date: Wednesday, 11 December 2019 at 23:06
> > To: "spring@ietf.org" <spring@ietf.org>
> > Subject: Re: [spring] I-D Action:
draft-ietf-spring-srv6-network-programming-06.txt
> >
> > So, I've tried to look at this with fresh eyes, and thanks for
the
> > various updates and clarifications.
> >
> > (I'm still not on the SPRING list so please leave me in CC.)
> >
> > I remain a bit puzzled. First, a quote from the SRH
specification
> > (draft-ietf-6man-segment-routing-header-26):
> >
> > > 4.2. Transit Node
> > >
> > > As specified in [RFC8200], the only node allowed to
inspect the
> > > Routing Extension Header (and therefore the SRH), is the
node
> > > corresponding to the DA of the packet. Any other transit
node MUST
> > > NOT inspect the underneath routing header and MUST forward
the packet
> > > toward the DA according to its IPv6 routing table.
> >
> > Next, a quote from the current draft:
> >
> > > SRH[n]: A shorter representation of Segment List[n], as
defined in
> > > [I-D.ietf-6man-segment-routing-header].
> > >
> > > When a packet is intercepted on a wire, it is possible
that SRH[SL]
> > > is different from the DA.
> >
> > Huh? That would be extremely unusual in the normal
interpretation
> > of a routing header, where is RH[SL] is by definition the next
> > destination where the RH will be processed. Any other node is a
transit
> > node, and I don't see anything in
draft-ietf-6man-segment-routing-header-26
> > that allows for anything else. So it seems to me that the
quoted statement
> > needs an explanation of why it isn't a violation of
> > draft-ietf-6man-segment-routing-header-26, not to mention why
it's useful.
> >
> > PC: This occurs when we use the reduced SRH as described in:
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.1.1
>
> OK, well that definitely needs to be added to the draft, since it is
very far from
> obvious to a newcomer.
>
> PC: I have removed this sentence from the latest revision of the draft.
Unneeded, misleading and covered in the SRH. See rev07. Thank you for your
comment.
Thanks.
>
> > If you think this sentence does not reflect that, I can edit it for
the next revision of the draft.
> >
> > That leads us back to:
> >
> > > 4.16.1. PSP: Penultimate Segment Pop of the SRH
> > >
> > > The SRH processing of the End, End.X and End.T behaviors
are
> > > modified: after the instruction "S14. Update IPv6 DA with
Segment
> > > List[Segments Left]" is executed, the following
instructions must be
> > > executed as well:
> > >
> > > S14.1. If (Segments Left == 0) {
> > > S14.2. Update the Next Header field in the preceding
header to the
> > > Next Header value of the SRH
> > > S14.3. Decrease the IPv6 header Payload Length by the
Hdr Ext Len
> > > value of the SRH
> > > S14.4. Remove the SRH from the IPv6 extension header
chain
> > > S14.5. }
> >
> > This is clearly a breach of RFC8200, but it can never be
reached if DA == SRH[SL].
>
> > PC: PSP executes at the segment that is the Destination Address.
>
> I am probably being stupid, but I don't understand what is
"penultimate" about
> a condition where SL == 0 and the packet has reached the node that
owns DA.
> Where will the packet be sent next, since it's already at the final
DA?
>
> PC: You are reading line 14 of a pseudocode. In the previous lines we
have received a packet with Segments Left = 1, and we have decremented by one
such value.
If I have this right, the PSP case is inserted in this pseudocode:
S14. Update IPv6 DA with Segment List[Segments Left]
S15. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination
which produces:
S14. Update IPv6 DA with Segment List[Segments Left]
S14.1. If (Segments Left == 0) {
S14.2. Update the Next Header field in the preceding header to the
Next Header value of the SRH
S14.3. Decrease the IPv6 header Payload Length by the Hdr Ext Len
value of the SRH
S14.4. Remove the SRH from the IPv6 extension header chain
S14.5. }
S15. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination
That's explicitly removing the header before forwarding the packet. How
can that not be a violation of RFC 8200? And where is it forwarded to, since
we are already at the DA?
PC:
I receive a packet at the node identified in the Destination Address field of
the IPv6 header.
I process the extension header and delete it (in that same node).
The packet, with the updated Destination Address, is forwarded towards the node
identified in the Destination Address field of the IPv6 header.
Brian
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
