[spring] H.Encaps pseudocode (was Re: Question about SRv6 Insert function)

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Alex,

I will update the line 04 as suggested to clarify that it refers to the outer IPv6 header. Thank you.
More inline.

Happy Holidays,
Pablo.

-----Original Message-----
From: Alexandre Petrescu <[e-mail]>
Date: Thursday, 19 December 2019 at 14:33
To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [spring] Question about SRv6 Insert function

    
    
    Le 19/12/2019 à 12:52, Pablo Camarillo (pcamaril) a écrit :
    > Hi Alex.
    > 
    > Please see inline.
    > 
    > Many thanks,
    > 
    > Pablo.
    > 
    > ------------------------------------------------------------------------
    >
    >
    > 
    *From:*Alexandre Petrescu <[e-mail]> *Sent:*
    > Monday, December 16, 2019 3:31 PM *To:* Pablo Camarillo (pcamaril) 
    > <[e-mail]>; [e-mail] <[e-mail]> *Subject:* Re: 
    > [spring] Question about SRv6 Insert function
    > 
    > Hi, SPRINGers,
    > 
    > This is my first post to this list.
    > 
    > This is about draft-ietf-spring-srv6-network-programming-06 more 
    > precisely the T.Encaps section 5.2.
    > 
    > Le 11/12/2019 à 21:05, Pablo Camarillo (pcamaril) a écrit :
    >> Alex,
    >> 
    >> The precise definition T.Encaps is done in section 5.1 [5.2 now] of
    >> draft-ietf-spring-srv6-network-programming-06. If you have any 
    >> comment on such definition please let me know -on a separate thread
    >> and directed to SPRING mailer-.
    > 
    > Thank you for the reply.
    > 
    > Please make the T.Encaps part of the draft easier for me to read, 
    > e.g.: -expand what it means 'S01'; is it 'Step 01', like in BASIC 
    > programming language?
    > 
    > PC: Same format as in other documents (e.g. SRH).
    
    What is the other document SRH?

PC: draft-ietf-6man-segment-routing-header-26
    
    > -clarify that the original packet in transit is not modified upon 
    > transition (modulo the Hop Limit field and the Segments Left field if
    > present); new packet is created to carry the original packet - yes.
    > 
    > PC: I have added a paragraph in the latest version of the draft to 
    > capture your point. See rev07. Many thanks.
    
    I think you mean that you added this paragraph:
    > The T.Encaps received packet is encapsulated unmodified (with the
    > exception of the TTL or Hop Limit that is decremented as described in
    > [RFC2473]).
    
    I think it is good to say the packet is encapsulated unmodified.
    
    Indeed the Hop Limit is the sole exception.  I think the TTL should not
    be mentioned.  (side note: each IPv4 occurence should be dropped from
    everywhere in the document now :-)
    
    > -clarify what it means 'a packet (A, S2)(S3, S2, S1; SL=1)'; because 
    > it is confusing in several ways; (A,S2) invites to think it is src 
    > and dst addresses, but their place is switched (the normal order is 
    > Source, Destination).  S in 'S2' might mean a Source Address but
    > also might mean a Segment ID, or a Destination address.  Confusion
    > should be avoided, at least in my mind.
    > 
    > PC: This is explained in the terminology section of the draft (with
    > a detailed example).
    
    It is indeed in the terminology section.
    
    It clarifies many things to me.
    
    I am still left with the question: is a Segment Identifier an IPv6 
    address?  (all the 128bits of it).  I cant find an answer neither in 
    this I-D neither in its reference RFC8402 "Segment Routing" terminology 
    section.

PC: See the first paragraph of section 3.
    
    This is important to know, because in below the text says a destination 
    address is an S1 (DA=S1) and it also says that S1 is part of a segment list.
    
    In a destination address field one cant have something else than an IPv6 
    address.  But a segment identifier could be something else than an IPv6 
    address, if so it wanted.  (somewhere else people talk about 'locator' 
    being a 64bit value, I am not sure).

PC: Read section 3.1.
    
    About my initial worry - now T.Encaps cahnged its name into H.Encaps, right?

PC: Yes. 
    
    It seems to not modify packets in transit, but to encapsulate them, 
    which is ok.

PC: Indeed.
    
    >    Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1;
    >    SL=1).  B2 is neither a local address nor SID of N.
    > 
    >    N steers the transit packets P1 and P2 into an SR Policy with a
    >    Source Address T and a Segment list <S1, S2, S3>.
    > 
    >    The H.Encaps transit encapsulation behavior is defined as follows:
    > 
    >    S01.   Push an IPv6 header with its own SRH (S3, S2, S1; SL=2)
    >    S02.   Set outer IPv6 SA = T and outer IPv6 DA = S1
    >    S03.   Set outer payload length, traffic class and flow label
    >    S04.   Update the Next-Header value
    
    'Update' or rather 'create'?  I hope it is the next-header value of the 
    outer IPv6 header; this is the first time to put something inside, so it 
    is rather a creation.
    
    'Updating' makes think that maybe the next header value of the inner 
    (original) packet is updated from value x to y.
    
    Or?
    
    >    S05.   Decrement inner Hop Limit or TTL
    >    S06.   Submit the packet to the IPv6 module for transmission to S1
    > 
    >    After the H.Encaps behavior, P1 and P2 respectively look like:
    > 
    >    - (T, S1) (S3, S2, S1; SL=2) (A, B2)
    > 
    >    - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1)
    
    It looks ok - the P1 and P2 packets have not been modified in transit, 
    but encapsulated.
    
    I wonder though about the 1 value for SL (SL=1) in P2 original and P2 
    transited.  I wonder whether it should be decremented or not.  I think 
    it might complicated but I do not mind.
    
    Alex