Re: [spring] Question about SRv6 Insert function

Alexandre Petrescu <> Thu, 19 December 2019 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC85E12086C for <>; Thu, 19 Dec 2019 05:33:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PtEbgRpcmKrk for <>; Thu, 19 Dec 2019 05:33:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 33545120861 for <>; Thu, 19 Dec 2019 05:33:23 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBJDXJP7004097; Thu, 19 Dec 2019 14:33:19 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 000DD2041B2; Thu, 19 Dec 2019 14:33:18 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id E5C7C2042A7; Thu, 19 Dec 2019 14:33:18 +0100 (CET)
Received: from [] ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBJDXIrg013915; Thu, 19 Dec 2019 14:33:18 +0100
To: "Pablo Camarillo (pcamaril)" <>, "" <>
References: <> <> <> <> <28214_1567694772_5D711FB4_28214_238_1_53C29892C857584299CBF5D05346208A48BFA9F3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <1824_1575998223_5DEFD30F_1824_112_1_53C29892C857584299CBF5D05346208A48D24EBD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <11783_1576056453_5DF0B685_11783_221_1_53C29892C857584299CBF5D05346208A48D261E9@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Thu, 19 Dec 2019 14:33:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [spring] Question about SRv6 Insert function
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Dec 2019 13:33:28 -0000

Le 19/12/2019 à 12:52, Pablo Camarillo (pcamaril) a écrit :
> Hi Alex.
> Please see inline.
> Many thanks,
> Pablo.
> ------------------------------------------------------------------------
*From:*Alexandre Petrescu <> *Sent:*
> Monday, December 16, 2019 3:31 PM *To:* Pablo Camarillo (pcamaril) 
> <>om>; <> *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 

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.


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