Re: [spring] Question about SRv6 Insert function
Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 16 December 2019 14:31 UTC
Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892181200B1 for <ipv6@ietfa.amsl.com>; Mon, 16 Dec 2019 06:31:41 -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 kkEO79DN6kF3 for <ipv6@ietfa.amsl.com>; Mon, 16 Dec 2019 06:31:38 -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 8B51712007C for <ipv6@ietf.org>; Mon, 16 Dec 2019 06:31:38 -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 xBGEVXf2046841; Mon, 16 Dec 2019 15:31:33 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AA96720645C; Mon, 16 Dec 2019 15:31:33 +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 9C19320637E; Mon, 16 Dec 2019 15:31:33 +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 xBGEVXI2005190; Mon, 16 Dec 2019 15:31:33 +0100
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Subject: Re: [spring] Question about SRv6 Insert function
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, "ipv6@ietf.org" <ipv6@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: <35c4119f-1d46-0220-d7e4-168b27beb782@gmail.com>
Date: Mon, 16 Dec 2019 15:31:33 +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/ipv6/IGNvpDeStGpMKXHsEo8nyw3ninY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2019 14:31:42 -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 > -------------------------------------------------------------------- > >
- Question about SRv6 Insert function li zhenqiang
- Re: Question about SRv6 Insert function Ole Troan
- RE: Question about SRv6 Insert function Ron Bonica
- Re: Question about SRv6 Insert function Mark Smith
- Re: Question about SRv6 Insert function Fernando Gont
- Re: Question about SRv6 Insert function Fernando Gont
- Re: Re: Question about SRv6 Insert function li zhenqiang
- Re: RE: Question about SRv6 Insert function li zhenqiang
- Re: Question about SRv6 Insert function Suresh Krishnan
- Re: Question about SRv6 Insert function Ca By
- RE: Question about SRv6 Insert function Ron Bonica
- Re: Question about SRv6 Insert function Fernando Gont
- Re: Question about SRv6 Insert function Behcet Sarikaya
- Re: Question about SRv6 Insert function Suresh Krishnan
- Re: Question about SRv6 Insert function Fernando Gont
- Re: Question about SRv6 Insert function Suresh Krishnan
- Re: Question about SRv6 Insert function Ole Troan
- Re: Question about SRv6 Insert function Fernando Gont
- Re: Question about SRv6 Insert function Ole Troan
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- RE: [spring] Question about SRv6 Insert function Alexander Vainshtein
- Re: Re: [spring] Question about SRv6 Insert funct… li zhenqiang
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- Re: Re: [spring] Question about SRv6 Insert funct… li zhenqiang
- Re: Re: [spring] Question about SRv6 Insert funct… Robert Raszuk
- Re: Question about SRv6 Insert function Fernando Gont
- RE: [spring] Question about SRv6 Insert function bruno.decraene
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- RE: [spring] Question about SRv6 Insert function bruno.decraene
- Re: [spring] Question about SRv6 Insert function Darren Dukes (ddukes)
- Re: [spring] Question about SRv6 Insert function Darren Dukes (ddukes)
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- Re: [spring] Question about SRv6 Insert function Darren Dukes (ddukes)
- Re: [spring] Question about SRv6 Insert function Darren Dukes (ddukes)
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- RE: [spring] Question about SRv6 Insert function Ron Bonica
- Re: [spring] Question about SRv6 Insert function Darren Dukes (ddukes)
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- RE: [spring] Question about SRv6 Insert function Andrew Alston
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- RE: [spring] Question about SRv6 Insert function Ron Bonica
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- Re: [spring] Question about SRv6 Insert function Andrew Alston
- RE: [spring] Question about SRv6 Insert function Ron Bonica
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- Re: [spring] Question about SRv6 Insert function Ole Troan
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- Re: RE: [spring] Question about SRv6 Insert funct… li zhenqiang
- Re: [spring] Question about SRv6 Insert function Brian E Carpenter
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- Re: [spring] Question about SRv6 Insert function Mark Smith
- Re: [spring] Question about SRv6 Insert function Fernando Gont
- RE: [spring] Question about SRv6 Insert function bruno.decraene
- Re: [spring] Question about SRv6 Insert function Brian E Carpenter
- Re: [spring] Question about SRv6 Insert function Robert Raszuk
- SRH scratch space (was Re: [spring] Question abou… Erik Kline
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] SRH scratch space (was Re: Question … Erik Kline
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] SRH scratch space (was Re: Question … Erik Kline
- Re: [spring] SRH scratch space (was Re: Question … Mark Smith
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] SRH scratch space (was Re: Question … Mark Smith
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] SRH scratch space (was Re: Question … Bob Hinden
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] SRH scratch space (was Re: Question … Bob Hinden
- Re: [spring] SRH scratch space (was Re: Question … Brian E Carpenter
- RE: [spring] SRH scratch space (was Re: Question … Xiejingrong (Jingrong)
- Re: [spring] SRH scratch space (was Re: Question … Alexandre Petrescu
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- RE: [spring] Question about SRv6 Insert function bruno.decraene
- Re: [spring] Question about SRv6 Insert function Alexandre Petrescu
- Re: [spring] Question about SRv6 Insert function Pablo Camarillo (pcamaril)
- Re: [spring] Question about SRv6 Insert function Pablo Camarillo (pcamaril)
- Re: [spring] Question about SRv6 Insert function Alexandre Petrescu
- Re: [spring] SRH scratch space (was Re: Question … Gyan Mishra
- Re: [spring] SRH scratch space (was Re: Question … Robert Raszuk
- Re: [spring] Question about SRv6 Insert function Alexandre Petrescu
- Re: [spring] Question about SRv6 Insert function Alexandre Petrescu