[spring] Non-final destination address (was Re: Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)))
Suresh Krishnan <Suresh@kaloom.com> Thu, 12 December 2019 00:04 UTC
Return-Path: <Suresh@kaloom.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 F339C1201EF; Wed, 11 Dec 2019 16:04:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com
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 DB4lFfEl3ReR; Wed, 11 Dec 2019 16:04:36 -0800 (PST)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670113.outbound.protection.outlook.com [40.107.67.113]) (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 44E761200F4; Wed, 11 Dec 2019 16:04:36 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ncYJmnl4/e/VyQuS5uTh2B97AWF0srJoG0XAk/d+p4pNvi08YjWXLDCN9f+WZj71/so7PtRYOGTQKcuEnjwV0MW/sNeAtSHwp0MgSOWEUUJkS59chWm3gKUbfdLHx3qy0TBRys3KLwxQRNFh4KJsrscAr4ouqKEN63hrcQoaMq8SqGW/IOmsd0Ypz1NqpqZgXd8fVkNvoBDMqmDcJKBjBHZtlkkVm0YRdt8bYv4K9uhVfFGnyS1Jb9eIVaee9WVA9TeYIMwDwUNvm3hoNjnq3Sr2bUoViCLcRBYMjnw7a3+VPJvpEivtmgBuBu0VIoUFu1zD4F/uOEp0ggP5B5pzEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eg4KcujSK7q3S5x5p7ke74vJ0ia+aWp1ZoN0JMIsMZ8=; b=UGb5jPSsZ3kkQi4f20kawwok1n4vhLkrSQ3Zu51Fry/CuCoZCrBql9eErVUX/4J/bylefzg2PrpfHuHM6SP968aAI0BDzENHGSO/GuZzG4HvuUYLM/he+BXh+nGE+Nbfle8t25sqo+m/C1OiJLD54csUPMfEPKpeeN7C2qtM9fPJYMj+4yl9TDSNWMXufmO0GrYXCISYKgZ2RZCYhSngyB7z1XjDFj3TbCNW4EQJf0e8WbeXnwVVTtY5FWJcyz1NN4p4y2tSS3YhM4XK9sojLPd8JIcZ5kdaQ/ELokeFKrS9G4bJZ5rWTY0m7wL5oWhnzYWVuR2j9zqiWn6+h9YRXA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kaloom.com; dmarc=pass action=none header.from=kaloom.com; dkim=pass header.d=kaloom.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eg4KcujSK7q3S5x5p7ke74vJ0ia+aWp1ZoN0JMIsMZ8=; b=QWmFwOV7HB7uyVnU9i8pLMticxLkDeTZzWUg05XL/jQPUUSvZyHtS6lZpv1L8fanQ97SlPF9/Vree5NIYPXSU29QJv2APn7WD0xRGES8V9DwylkYpp36gJ7R+IDGDiEgvf0ByBWx1umkty6jFQRM3sJB5y7KA3ZG5o1qwiOZAXY=
Received: from YQXPR01MB2888.CANPRD01.PROD.OUTLOOK.COM (52.132.92.18) by YQXPR01MB3416.CANPRD01.PROD.OUTLOOK.COM (52.132.94.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.15; Thu, 12 Dec 2019 00:04:33 +0000
Received: from YQXPR01MB2888.CANPRD01.PROD.OUTLOOK.COM ([fe80::cdc8:a6f5:5192:8f44]) by YQXPR01MB2888.CANPRD01.PROD.OUTLOOK.COM ([fe80::cdc8:a6f5:5192:8f44%7]) with mapi id 15.20.2538.016; Thu, 12 Dec 2019 00:04:33 +0000
From: Suresh Krishnan <Suresh@kaloom.com>
To: Fernando Gont <fgont@si6networks.com>
CC: SPRING WG <spring@ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.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>, Ole Troan <otroan@employees.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: Non-final destination address (was Re: [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: AQHVsH+7DXT1ZCyqd0+hvtabGv7MOg==
Date: Thu, 12 Dec 2019 00:04:33 +0000
Message-ID: <858E25C2-36FA-4E37-A70C-72D9DEA1BF3D@kaloom.com>
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> <6bc831ce-326f-3648-6e6f-4c715b2a49ac@si6networks.com>
In-Reply-To: <6bc831ce-326f-3648-6e6f-4c715b2a49ac@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com;
x-originating-ip: [45.19.110.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c1416b0c-54b1-4b81-301a-08d77e96de59
x-ms-traffictypediagnostic: YQXPR01MB3416:
x-microsoft-antispam-prvs: <YQXPR01MB3416A2B9FD81FA31CE3871E0B4550@YQXPR01MB3416.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0249EFCB0B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(396003)(136003)(346002)(366004)(376002)(199004)(189003)(5660300002)(6486002)(508600001)(186003)(6506007)(53546011)(4326008)(33656002)(2906002)(8676002)(316002)(26005)(66946007)(76116006)(86362001)(91956017)(6916009)(36756003)(66476007)(66556008)(71200400001)(64756008)(81166006)(81156014)(6512007)(54906003)(2616005)(8936002)(66446008); DIR:OUT; SFP:1102; SCL:1; SRVR:YQXPR01MB3416; H:YQXPR01MB2888.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6H7TLcpeIAr4LZQUrjWSeFYHmo+MpkOlZ9IVzTKhKr/bUxgduriImikV1nJDpWQcKEToKaGimYFy88YbVr0dM7tLU9ASq3/p5TSLc4yIaPvnr0VLMq0q293j74wjBsFpBhUeC/ye7ne+EYnkuMveMyCEOtVb7GIOKw+yaM0giik7boI8QBAOmqOJ48k6witr/QvRz7sJZi/dXGSO5zOMkG7ODWGa/WpOZgMIqt/XyQdadm6xEOOu8ccHwPraLUwUK1jeQs3o/6qVdk5wT91mR71YPER1NKCQxupF0M1q1PTEh5mPUpSErV1eZrVfLh//uvSvDFLND+shdeVoaTznU6YyARjUBDM32m+XKe7eBhO/uvhTxHE41/vVxI/O0A0Rp45x1sEqoM9HLqdf9DWeX2RC6iq2vojDnbOLQ9gFrQEYCIWfdI0eZ4nkdvtO2+Uq
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <AB2E2C6BB4F368448FB2E7A143E41540@CANPRD01.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: kaloom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c1416b0c-54b1-4b81-301a-08d77e96de59
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2019 00:04:33.6255 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WT2C8VF6+5vlSAJqDY0OvWfS8Ki/qVt9aJF4R3mpHq2QQl+HGcYtRUZTrwlqIVpXLoz7SUD7i6V4XOOWlIgPmg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3416
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0>
Subject: [spring] Non-final destination address (was Re: 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: Thu, 12 Dec 2019 00:04:40 -0000
Hi Fernando, Answer inline. > On Dec 7, 2019, at 9:31 AM, Fernando Gont <fgont@si6networks.com> wrote: > > On 7/12/19 04:19, Suresh Krishnan wrote: >> (responding on spring mailing list) >> >> Hi Fernando, >> >>> On Dec 7, 2019, at 11:07 AM, Fernando Gont <fgont@si6networks.com >>> <mailto:fgont@si6networks.com>> wrote: >>> >>> On 6/12/19 23:47, Brian E Carpenter wrote: >>>> Again, comment at the end... >>>> On 07-Dec-19 14:37, Fernando Gont wrote: >>>>> On 6/12/19 22:15, Brian E Carpenter wrote: >>>>> [...] >>>>>> >>>>>>> and if such a thing is required, an update to RFC8200 should be done. >>>>>> >>>>>> Why does that follow? Alternatively, >>>>>> draft-ietf-spring-srv6-network-programming could acknowledge that >>>>>> it deviates from RFC8200. >>>>> >>>>> You can deviate from s "should", not from a "must". This is an outright >>>>> violation of a spec, rather than a mere "deviation". >>>>> >>>>> >>>>>> Whether that's acceptable would be a question for the IETF Last >>>>>> Call rather than any single WG. >>>>> >>>>> I would expect that a WG cannot ship a document that is violating an >>>>> existing spec, where the wg shipping the document is not in a position >>>>> of making decisions regarding the spec being violated. >>>>> >>>>> That would be like a waste of energy and time for all. >>>>> >>>>> >>>>> >>>>>> At the moment, the draft only mentions RFC8200 in a context that >>>>>> discusses neither insertion nor removal of extension headers, which >>>>>> is beside the point. Like draft-voyer, if it describes a violation >>>>>> of RFC8200, shouldn't that be explicit in the text? >>>>>> >>>>>> There's a lot of jargon in >>>>>> draft-ietf-spring-srv6-network-programming. I can't tell from the >>>>>> jargon whether "insert" means "insert on the fly" and whether "Pop >>>>>> the SRH" means "delete on the fly". Should those terms be clarified >>>>>> before the draft advances? >>>>> >>>>> Well, if it's not clear to you, it would seem to me that the simple >>>>> answer would be "yes". >>>> >>>> But if "insert" refers to the encapsulating node at the SR domain >>>> ingress, it's no problem, and if "pop" simply means doing normal >>>> routing header processing, it's no problem. It simply isn't clear in >>>> the text, at least not clear to me. >>> >>> The fact that a folk that has been deeply involved with IPv6 cannot >>> unequivocally tell what they talking about should be an indication with >>> respect to how ready the document is to be shipped. >>> >>> (pop when you are the destination but SL!=0 is essentially 'in the >>> network removal’) >> >> It is not obvious to me why you think this is a violation of RFC8200 >> though it is possible that I misread your comment. The relevant text I >> am looking at is >> >> " Extension headers (except for the Hop-by-Hop Options header) are not >> processed, inserted, or deleted by any node along a packet's delivery >> path, until the packet reaches the node (or each of the set of nodes, >> in the case of multicast) identified in the Destination Address field >> of the IPv6 header.” >> >> which seems to permit it. Can you please clarify where there is a >> violation? > > In the context of RFC8200, where the text you have quoted is present, > can you tell me which address other than that of the final destination > can be in the Destination Address of the packet? RFC8200 *clearly* speaks about the possibility of the destination address not being the ultimate recipient in the presence of a Routing Header. This is from Section 3 defining the Destination Address as "128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present).” Thanks Suresh
- [spring] Network Programming - Penultimate Segmen… Ron Bonica
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… Darren Dukes (ddukes)
- Re: [spring] Network Programming - Penultimate Se… Ron Bonica
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… otroan
- Re: [spring] Network Programming - Penultimate Se… Ron Bonica
- Re: [spring] Network Programming - Penultimate Se… otroan
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- [spring] We don't seem to be following our proces… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Tom Herbert
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Enno Rey
- Re: [spring] We don't seem to be following our pr… Enno Rey
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Bob Hinden
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Joel M. Halpern
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Tom Herbert
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Bob Hinden
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Tom Herbert
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… Darren Dukes (ddukes)
- Re: [spring] Network Programming - Penultimate Se… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Ole Troan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- [spring] Separating issues (was Re: We don't seem… Suresh Krishnan
- [spring] Penultimate Segment Popping and RFC8200 … Suresh Krishnan
- Re: [spring] Separating issues (was Re: We don't … Ketan Talaulikar (ketant)
- Re: [spring] Penultimate Segment Popping and RFC8… Ketan Talaulikar (ketant)
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Alexandre Petrescu
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… Darren Dukes (ddukes)
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Darren Dukes (ddukes)
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] Network Programming - Penultimate Se… Tom Herbert
- Re: [spring] Network Programming - Penultimate Se… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Brian E Carpenter
- Re: [spring] Penultimate Segment Popping and RFC8… Adrian Farrel
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] We don't seem to be following our pr… bruno.decraene
- Re: [spring] Penultimate Segment Popping and RFC8… bruno.decraene
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Mark Smith
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Brian E Carpenter
- Re: [spring] Penultimate Segment Popping and RFC8… bruno.decraene
- Re: [spring] Penultimate Segment Popping and RFC8… Pablo Camarillo (pcamaril)
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- [spring] Non-final destination address (was Re: P… Suresh Krishnan
- Re: [spring] Non-final destination address (was R… Fernando Gont
- Re: [spring] Non-final destination address (was R… Suresh Krishnan
- Re: [spring] Non-final destination address (was R… Fernando Gont