Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

<bruno.decraene@orange.com> Tue, 10 December 2019 13:16 UTC

Return-Path: <bruno.decraene@orange.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 DA0ED12008A; Tue, 10 Dec 2019 05:16:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qI9v6tT32Lkp; Tue, 10 Dec 2019 05:16:42 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9BDE120098; Tue, 10 Dec 2019 05:16:41 -0800 (PST)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 47XLDl3hv4z208w; Tue, 10 Dec 2019 14:16:39 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 47XLDl2n1LzyQ7; Tue, 10 Dec 2019 14:16:39 +0100 (CET)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Tue, 10 Dec 2019 14:16:39 +0100
From: <bruno.decraene@orange.com>
To: Fernando Gont <fgont@si6networks.com>
CC: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, Andrew Alston <Andrew.Alston@liquidtelecom.com>, rtg-ads <rtg-ads@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "Ole Troan" <otroan@employees.org>, Suresh Krishnan <Suresh@kaloom.com>, "Robert Raszuk" <robert@raszuk.net>
Thread-Topic: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))
Thread-Index: AQHVrM69NORQVRbL0kC2c8q9tirIQqeuthaAgAAFsYCAACVTgIAAEDEAgABon4CAA/8mwA==
Date: Tue, 10 Dec 2019 13:16:38 +0000
Message-ID: <27448_1575983799_5DEF9AB7_27448_30_1_53C29892C857584299CBF5D05346208A48D245CD@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <f2a0ad13-0eba-6f5a-1d3c-e45e2780f201@si6networks.com> <D666EA6E-E8E9-439A-9CDE-20857F03CB65@employees.org> <4255AD3B-379C-45BF-96E1-D3D9141A684F@liquidtelecom.com> <d59de54e-c7f8-be67-1e77-b051735d40a6@gmail.com> <3bce7b18-ea45-d29f-5dfb-1d3258b07d1e@si6networks.com> <c6e1f690-b0bf-9f45-8fa7-92ed182c5b04@gmail.com> <a2cc5cbd-ac06-e193-307c-3ffe5b21b0b1@si6networks.com> <80A78F48-9802-4DA9-B264-1A8920C1DDF9@kaloom.com> <c727fb5e-015d-90e2-9860-6c48ce021ac4@si6networks.com> <CAOj+MMEyMDHULL7Pr=QmucTJy9b=3ph9TgTZ7koi9BBLkFCJ6g@mail.gmail.com> <bb767aff-8737-a749-2f99-ac350f66def5@si6networks.com> <CAOj+MMEjzxrEbmKbUn11EsTSnVOZC0cKZhAeXapV2vW++g0ZdA@mail.gmail.com> <885c9ad6-ddd2-392a-7e9f-722509753e2d@si6networks.com>
In-Reply-To: <885c9ad6-ddd2-392a-7e9f-722509753e2d@si6networks.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/dJoL1S-aapSRz6zuIsoL08ELw_k>
Subject: Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))
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: Tue, 10 Dec 2019 13:16:45 -0000

Fernando,

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Fernando Gont
> Sent: Sunday, December 8, 2019 1:55 AM
> 
> On 7/12/19 15:40, Robert Raszuk wrote:
> > Hi Fernando,
> >  
> > 
> >     The online possible instantiation of "Destination Address" as in RFC8200
> >     is the final destination of the packet.
> > 
> > 
> > No. That is incorrect. 
> > 
> > Hint: Please read carefully RFC2473. 
> 
> If you think a document on tunnels rules how IPv6 operates, and its
> end-to-endianness, then you have a huge problem reading specs.
> 
> So I will not enter that game, because it would be accepting to be
> mocked at.
> 
> I'll wait for a few days for our INT AD's response (Suresh), a response
> from the spring chairs (if any), and a response from the RTG AD(s).

I'm not sure what response to what question you expect from spring chairs.
draft-ietf-spring-srv6-network-programming is under WG LC: this is the time for everyone to comment on the document and hopefully improve it. At this stage, I'd rather not influence the discussion.

That been said, since you are insisting

>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Fernando Gont
>> Sent: Saturday, December 7, 2019 6:43 PM
>>  The online possible instantiation of "Destination Address" as in RFC8200 is the final destination of the packet.

It appears to me that, at minimum, multiple opinions have been expressed on this point, including from Suresh. So, assuming that by "online" you meant "only", the statement "only possible" seems excessive to me.
But I have noted your reading of RFC8200 and your objection, which I believe concern the PSP and USP 'flavors' sections 4.16.1 and 4.16.2
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16

Regards,
--Bruno

> Then I will escalate the problem as required, including a formal appeal,
> if necessary.
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

_________________________________________________________________________________________________________________________

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.