Comment at the end:
On 21-Dec-19 06:30, Pablo Camarillo (pcamaril) wrote:
> Inline.
>
> Thanks.
>
> -----Original Message-----
> From: Brian E Carpenter <[email protected]>
> Date: Thursday, 19 December 2019 at 22:39
> To: "Pablo Camarillo (pcamaril)" <[email protected]>, "[email protected]"
> <[email protected]>
> 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 <[email protected]>
> > Date: Saturday, 14 December 2019 at 21:04
> > To: "Pablo Camarillo (pcamaril)" <[email protected]>,
> "[email protected]" <[email protected]>
> > 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 <[email protected]> on behalf of Brian E
> Carpenter <[email protected]>
> > > Date: Wednesday, 11 December 2019 at 23:06
> > > To: "[email protected]" <[email protected]>
> > > 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.
Thanks, I understand that. I think that after the holidays we need to take that
explanation back to 6MAN, where I suspect we will find strong objections. This
means that two strange things are happening to the packet: in-flight deletion
of a header and NAT.
As I just said to Robert, MPLS was designed in a way that makes this natural,
but IPv6 wasn't. The natural solution for IPv6 is Penultimate Segment
Decapsulation, not PSP, I think.
Regards
Brian
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
