Dear Jinmei-san,
Inline PC1.
Thanks,
Pablo.
-----Original Message-----
From: ipv6 <ipv6-boun...@ietf.org> on behalf of 神明達哉 <jin...@wide.ad.jp>
Date: Tuesday, 3 March 2020 at 00:21
To: Robert Raszuk <rob...@raszuk.net>
Cc: "spring@ietf.org" <spring@ietf.org>, "6...@ietf.org" <6...@ietf.org>, Bob
Hinden <bob.hin...@gmail.com>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
At Sat, 29 Feb 2020 12:06:17 +0100,
Robert Raszuk <rob...@raszuk.net> wrote:
> Even if RFC8200 section 4 text would say:
>
> "Extension headers cannot be added to a packet after it has left its
> source node and extension headers cannot be removed from a packet until it
> has arrived at its ultimate destination".
>
> PSP would be still not be violating anything said in this sentence. Reason
> being is that we are dealing here with an *encapsulated* packet which has
> as its ultimate destination SR node X. That SR node X is to perform or not
> PSP. So it is still fully compliant with the specification.
(Sorry for the hopefully small delay, I've been out of town for these
several days and am now catching up with the backlog).
Hmm, so, using the notation shown in Section 5.1 of
draft-ietf-spring-srv6-network-programming-10, is this how the PSP is
expected to work?
- Node N creates an encapsulated IPv6 packet:
(T, S1) (S3, S2, S1; SL=2) (A, B2)
- at S1, since SL != 0,
decrease SL to 1,
copy SList[SL] = SList[1] = S2 to the destination address of the
IPv6 header, so we now have:
(T, S2) (S3, S2, S1; SL=1) (A, B2)
PC1: Correct
- at S2, since SL != 0,
decrease SL to 0
copy SList[SL] = SList[0] = S3 to the destination address of the
IPv6 header, so we now have:
(T, S3) (S3, S2, S1; SL=0) (A, B2)
according to Section S14 of draft-ietf-spring-srv6-network-programming-10.
- Now we apply Section 4.16.1 (PSP).
Since SL == 0 at this point, Payload length and next header value
are adjusted, RH is removed, and we now have:
(T, S3) (A, B2)
PC1:
This is the exact processing at S2 combined End (4.1) with PSP (4.16.1):
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Send an ICMP Parameter Problem message to the Source Address
Code 4 (SR Upper-layer Header Error),
Pointer set to the offset of the upper-layer header.
Interrupt packet processing and discard the packet.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address,
Code 0 (Hop limit exceeded in transit),
Interrupt packet processing and discard the packet.
S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field.
Interrupt packet processing and discard the packet.
S11. }
S12. Decrement Hop Limit by 1
S13. Decrement Segments Left by 1
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
S16. }
It's not clear what will happen next from the text of
draft-ietf-spring-srv6-network-programming-10, but is presumably it as
follows?
- The packet will be forwarded to S3
- At S3, since it's the (ultimate) destination of the outper IPv6
packet, it decapsulates the packet, and we now have:
(A, B2)
- The decapsulated packet is forwarded towards B2
PC1: This is correct.
Please note that there have been many editorial changes in the PSP section of
the document. Hence I suggest you review revision 11.
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-11#section-4.16.1
Many thanks,
Pablo.
--
JINMEI, Tatuya
--------------------------------------------------------------------
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
