[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