Re: [spring] Question about SRv6 Insert function

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 19 December 2019 13:33 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC85E12086C for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 05:33:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtEbgRpcmKrk for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 05:33:23 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33545120861 for <spring@ietf.org>; Thu, 19 Dec 2019 05:33:23 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (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 pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 000DD2041B2; Thu, 19 Dec 2019 14:33:18 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E5C7C2042A7; Thu, 19 Dec 2019 14:33:18 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (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)" <pcamaril@cisco.com>, "spring@ietf.org" <spring@ietf.org>
References: <HK0PR03MB3970C6DCC635E7CD802D65FDFCBD0@HK0PR03MB3970.apcprd03.prod.outlook.com> <3e31873a-278a-2154-0e71-4d820bba323d@gont.com.ar> <4012D854-2F10-4476-951D-FFFE73C5083C@gmail.com> <cb2f56f8-acdc-d68d-0878-9609cb3d7b1b@gont.com.ar> <28214_1567694772_5D711FB4_28214_238_1_53C29892C857584299CBF5D05346208A48BFA9F3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <129bbb32-0f14-b799-430c-8f76fb6b1279@gont.com.ar> <1824_1575998223_5DEFD30F_1824_112_1_53C29892C857584299CBF5D05346208A48D24EBD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <4384c08a-65f5-dbfb-85c7-8365feba9662@gmail.com> <11783_1576056453_5DF0B685_11783_221_1_53C29892C857584299CBF5D05346208A48D261E9@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <260f6f3c-e3cc-e174-1782-456df7cded86@gmail.com> <8683D672-1A59-4253-AC46-14DD2D8C8B14@cisco.com> <35c4119f-1d46-0220-d7e4-168b27beb782@gmail.com> <MWHPR11MB1374842A5AFCB0EFD5AECFA0C9530@MWHPR11MB1374.namprd11.prod.outlook.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <3b78c6b0-1153-b8ad-6b97-84c91ee915c5@gmail.com>
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: <MWHPR11MB1374842A5AFCB0EFD5AECFA0C9530@MWHPR11MB1374.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/oV0opTSZ7UMbyVI1mgmBVgxcU8c>
Subject: Re: [spring] Question about SRv6 Insert function
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=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 <alexandre.petrescu@gmail.com> *Sent:*
> Monday, December 16, 2019 3:31 PM *To:* Pablo Camarillo (pcamaril) 
> <pcamaril@cisco.com>om>; ipv6@ietf.org <ipv6@ietf.org> *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