Re: [spring] Question about SRv6 Insert function

[Alexandre Petrescu <[e-mail]>]

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?

> -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.

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).

About my initial worry - now T.Encaps cahnged its name into H.Encaps, right?

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

>    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