Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Dear Jinmei-san,

Inline PC1.

Thanks,

Pablo.

-----Original Message-----

From: ipv6 <ipv6-bounces@ietf.org> on behalf of 神明達哉 <jinmei@wide.ad.jp>

Date: Tuesday, 3 March 2020 at 00:21

To: Robert Raszuk <robert@raszuk.net>

Cc: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Bob Hinden <bob.hinden@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 <robert@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

    ipv6@ietf.org

    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

    --------------------------------------------------------------------