Re: [spring] Question about SRv6 Insert function

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 16 December 2019 14:35 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 694881200B1 for <spring@ietfa.amsl.com>; Mon, 16 Dec 2019 06:35:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 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] 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 173zYPLA33dz for <spring@ietfa.amsl.com>; Mon, 16 Dec 2019 06:35:34 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 BFE8212007C for <spring@ietf.org>; Mon, 16 Dec 2019 06:35:33 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBGEZWeD000846 for <spring@ietf.org>; Mon, 16 Dec 2019 15:35:32 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3888D206437 for <spring@ietf.org>; Mon, 16 Dec 2019 15:35:32 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2E31A206037 for <spring@ietf.org>; Mon, 16 Dec 2019 15:35:32 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBGEZWge008632 for <spring@ietf.org>; Mon, 16 Dec 2019 15:35:32 +0100
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
To: SPRING WG email list <spring@ietf.org>
References: <HK0PR03MB3970C6DCC635E7CD802D65FDFCBD0@HK0PR03MB3970.apcprd03.prod.outlook.com> <BYAPR05MB54636A2332FED916A26A6F14AEBD0@BYAPR05MB5463.namprd05.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>
Message-ID: <76bc4985-6244-115f-9c3f-8fed96ef9772@gmail.com>
Date: Mon, 16 Dec 2019 15:35:32 +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: <8683D672-1A59-4253-AC46-14DD2D8C8B14@cisco.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/kYi3utWjwaQ6kht3VHgKlHbHyWU>
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: Mon, 16 Dec 2019 14:35:36 -0000

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

Alex

> 
> Many thanks, Pablo.
> 
> -----Original Message----- From: ipv6 <ipv6-bounces@ietf.org> on
> behalf of Alexandre Petrescu <alexandre.petrescu@gmail.com> Date:
> Wednesday, 11 December 2019 at 10:46 To: "ipv6@ietf.org"
> <ipv6@ietf.org> Subject: Re: [spring] Question about SRv6 Insert
> function
> 
> 
> 
> Le 11/12/2019 à 10:27, bruno.decraene@orange.com a écrit :
>> Brian, Pablo
>> 
>> Please see inline (multiple points)
>> 
>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
>>> Sent: Tuesday, December 10, 2019 8:36 PM To: DECRAENE Bruno
>>> TGI/OLN; Fernando Gont Cc: Ron Bonica; spring@ietf.org;
>>> 6man@ietf.org; Suresh Krishnan;
>>> draft-voyer-6man-extension-header-insertion;
>>> draft-ietf-spring-srv6-network-programming Subject: Re: [spring]
>>> Question about SRv6 Insert function
>>> 
>>> Bruno,
>>> 
>>> On 11-Dec-19 06:17, bruno.decraene@orange.com wrote:
>>>> Fernando,
>>>> 
>>>>> From: Fernando Gont [mailto:fernando@gont.com.ar] Sent:
>>>>> Monday, December 9, 2019 9:54 PM
>>>>> 
>>>>> On 5/9/19 09:46, bruno.decraene@orange.com wrote: [....]
>>>>>>> 
>>>>>>> Since there have been plenty of attempts to do EH
>>>>>>> insertion or leave the IPv6 standard ambiguous in this
>>>>>>> respect, and the IETF has had consensus that EH insertion
>>>>>>> is not allowed, I think it would be bad, wastefull,
>>>>>>> tricky, and even dangerous to let a document go through
>>>>>>> the whole publication process, and just rely on the AD
>>>>>>> to keep the "DISCUSS" button pressed.
>>>>>> 
>>>>>> draft-ietf-spring-srv6-network-programming has a normative
>>>>>> reference to [I-D.voyer-6man-extension-header-insertion] 
>>>>>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01#section-13.1
>
>>>>>> 
>>>>> 
>>>>>> As such, from a process standpoint, it would not going to
>>>>>> be published before
>>>>>> [I-D.voyer-6man-extension-header-insertion] be itself
>>>>>> published as RFC. And from its name, the latter is intended
>>>>>> to be discussed and within control of the 6MAN WG. So I
>>>>>> don't think that we can say that it "just rely on the AD to
>>>>>> keep the "DISCUSS" button pressed."
>>>>> 
>>>>> Yes, it is just relying on that.
>>>> 
>>>> Situation has changed since this email: the network programming
>>>> draft has now removed text related to SRH insertion. Please
>>>> comment on the text if you see text related to SRH insertion.
>>> 
>>> For example: 
>>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-8.2
>
>>> 
> 
>> Quoting the draft for everyone to read " Every  node is expected to
>> advertise via BGP-LS its SRv6 capabilities (e.g. how many SIDs it
>> can insert as part of a T.Encaps behavior)"
>> 
>> 
>> This is related to T.Encaps which is using IPv6 (outer)
>> encapsulation.
> 
> The term 'IPv6 encapsulation' has a somehow precise meaning, see
> below a citation from an RFC.
> 
> Do you mean that T.Encaps 'encapsulates' just the SRv6 header or the 
> entire IPv6 packet that contains the SRv6 header?
> 
> RFC2473:
>> IPv6 encapsulation consists of prepending to the original packet
>> an IPv6 header and, optionally, a set of IPv6 extension headers
>> (see Fig.3), which are collectively called tunnel IPv6 headers.
> 
> Alex
> 
>> - If you believe that T.Encaps is unclear on that, please comment
>> on its text. [1] - If the issue is the use of the term 'insert',
>> which is too close to the 'SRH insertion issue', I'm personally
>> fine with using a different term. E.g. "add". Please propose any
>> term which suits you [1]. That been said, I hope that we are not in
>> a situation where words are being forbidden.
>> 
>> [1] Preferably in the related thread, in order to help everyone
>> (all WG members, chairs, shepherds, ADs, IESG)  to be able to track
>> all comments. As we'll likely be in a situations where the number
>> of emails may be consequent
>> 
>>> Why would draft-voyer-6man-extension-header-insertion exists if
>>> the SRH proponents do not intend to perform SRH insertion?
>> 
>> As of today, the question been asked is a WG last call on
>> draft-ietf-spring-srv6-network-programming. If you want to secure
>> that SRH insertion is not used in the document, please comment as
>> part of its last call.
>> 
>> That been said, thanks to your comment, I've seen an unused
>> reference for [I-D.filsfils-spring-srv6-net-pgm-insertion]  that
>> needs to be removed
>> 
>> --Bruno
>> 
>> 
>>> 
>>> Brian
>>> 
>>>> 
>>>>> A question of you as a chair: does the wg you chair publish
>>>>> documents based on current specs (or at the very least based
>>>>> on  changes that are going to happen in the near term as a
>>>>> result of *existing and proven consensus*), or does spring
>>>>> ship documents that implicitly betting on changes that have
>>>>> no consensus?
>>>> 
>>>> In general, I don't see the benefit of sending a draft which we
>>>> expect would never progress to RFC. So this would not be my
>>>> preferred path. However, I guess that as always, there are
>>>> exceptions and I'm not a priori aware of a process forbidding
>>>> this. As of today, I'd rather not spend time on this
>>>> hypothetical case.
>>>> 
>>>>> The former is how I expect WGs to operate. The later shows a
>>>>> clear path to a huge pile of documents stuck at IESG review,
>>>>> simply because so later in the process folks found out that
>>>>> the document turns out to violate existing specs. With the
>>>>> risk of an AD pressing "YES", and hence IETF has been
>>>>> circumvented.
>>>> 
>>>> While IESG processing is beyond my paycheck (literally ;-) ), I
>>>> trust the IESG. And I don't see a reason to doubt a priori. And
>>>> even in this case, there may be a possibly to fetch back the
>>>> document from the RFC editor queue.
>>>> 
>>>> In short: very hypothetic case and beyond my hat. As of today,
>>>> I'd propose that we work on the text of the document.
>>>> 
>>>> Thank you, --Bruno
>>>> 
>>>>> Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar ||
>>>>> fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7
>>>>> F1C9 3945 96EE A9EF D076 FFF1
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> _________________________________________________________________________________________________________________________
>
>>>> 
>>> 
>>>> Ce message et ses pieces jointes peuvent contenir des
>>>> informations confidentielles ou privilegiees et ne doivent
>>>> donc pas etre diffuses, exploites ou copies sans autorisation.
>>>> Si vous avez recu ce message par erreur, veuillez le signaler a
>>>> l'expediteur et le detruire ainsi que les pieces jointes. Les
>>>> messages electroniques etant susceptibles d'alteration, Orange
>>>> decline toute responsabilite si ce message a ete altere,
>>>> deforme ou falsifie. Merci.
>>>> 
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they
>>>> should not be distributed, used or copied without
>>>> authorisation. If you have received this email in error, please
>>>> notify the sender and delete this message and its attachments. 
>>>> As emails may be altered, Orange is not liable for messages
>>>> that have been modified, changed or falsified. Thank you.
>>>> 
>>>> --------------------------------------------------------------------
>
>>>> 
>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6 
>>>> --------------------------------------------------------------------
>
>>>> 
>>> 
>> 
>> _________________________________________________________________________________________________________________________
>
>> 
> 
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre
>> diffuses, exploites ou copies sans autorisation. Si vous avez recu
>> ce message par erreur, veuillez le signaler a l'expediteur et le
>> detruire ainsi que les pieces jointes. Les messages electroniques
>> etant susceptibles d'alteration, Orange decline toute
>> responsabilite si ce message a ete altere, deforme ou falsifie.
>> Merci.
>> 
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should
>> not be distributed, used or copied without authorisation. If you
>> have received this email in error, please notify the sender and
>> delete this message and its attachments. As emails may be altered,
>> Orange is not liable for messages that have been modified, changed
>> or falsified. Thank you.
>> 
>> --------------------------------------------------------------------
>
>> 
> IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>
>> 
> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------