Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

"Darren Dukes (ddukes)" <ddukes@cisco.com> Thu, 27 February 2020 23:41 UTC

Return-Path: <ddukes@cisco.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 01F193A08FF; Thu, 27 Feb 2020 15:41:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NC2Tx9qe; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Dd05+I56
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 tnPrPpG0xNB0; Thu, 27 Feb 2020 15:41:23 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2553A08D8; Thu, 27 Feb 2020 15:41:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9000; q=dns/txt; s=iport; t=1582846882; x=1584056482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nSCdasUpi6KqLL6d/ULCi+icTXxMNrTvtsBxXoSKUMk=; b=NC2Tx9qemeed0pfqh1J6MVhjDoGBdEMacA0gA7AW4Er9aEcSCLvQ4CCz gI/dq0DdSKIBHadlCwXcpybvhiQUTTbfzp2y3hCjDZz5eDgbKTPFstkY2 nwIbHF8fZa/QKUgZN3CI3DOdlho78pLPqLlAFXqb9eHjZtRtztK8N9J7d Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3Aeu9TMhchs+Dnt1RB/M9/pOzulGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKYD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YyAnH8lZfFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnBQAhU1he/51dJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVCQsBWxYIAQLKoQUg0YDimWCX4M+lFaBQoEQA1QJAQEBDAE?= =?us-ascii?q?BGAsKAgQBAYRAAheBcSQ4EwIDDQEBBQEBAQIBBQRthTcMhWMBAQEBAgEBARA?= =?us-ascii?q?REQwBASwLAQQLAgEGAhgCAh8HAgICJQsVEAEBBA4FIoMEAYJKAw4gAQ6TY5B?= =?us-ascii?q?nAoE5iGJ1gTKCfwEBBYUXGIIMAwaBDiqMJRqBQT+BEScggh4uPmsZAYFfAQG?= =?us-ascii?q?BLAQBEgEhgxEygiyNbQOCdZ81CoI8lmUcgkmIG4ROi3xEqXMCBAIEBQIOAQE?= =?us-ascii?q?FgWkiZ3FwFTsqAYJBUBgNjh0MDAsVgzuFFIVBdIEpi0iBZF8BAQ?=
X-IronPort-AV: E=Sophos;i="5.70,493,1574121600"; d="scan'208";a="461846353"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Feb 2020 23:41:21 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 01RNfLYc012456 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2020 23:41:21 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Feb 2020 17:41:20 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Feb 2020 18:41:19 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Feb 2020 17:41:19 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CwatrSUnzkg2JKibOf9ZI3KQ3ZtCR+1I2on9lNNmeoj80UaEkunPoSqdwqh9nmvE1a6gjlE4TJMVcGMI6uRB+7J1SlFNSPX+lElP2rrq7gjO/pdmubgwSdRfO2+9GH/YVDUkkqjIf/WE/mjwK0f2q8rGglZlRugm8Mce4nzOf4IN5Yq6XcNjR3OcE1fjvh4JQOCljOx1pLjjKc/V6lqB1nhoewHzw+Yf+K4ydPBICy6WFCC7zr3ZKZwGzBFHTd8H2/j9WCTcfhILqjbSm32s7ZLNh9ZEEG00hqbguh5rs+3f3+UaZU/63IGK7LxbvzV/RWpQC1pNWYPowhxL0W1Raw==
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=nSCdasUpi6KqLL6d/ULCi+icTXxMNrTvtsBxXoSKUMk=; b=iqJAGlBOmWo1YJHN5hKrJvYU9K1QYhnsEq3p7CQGZDojzLdL3aQ0vmGO9wtr91qFjL7dDTnjqDCKaVrlqcB9WAloWd1bkexGMo7vIdBL/wuW+rtW83rk+VnBxWpbf35AQkiTKwNHvU1+6K85/TyDNVufk1ubOt+jbx/VRNi4W5xTLU8oDixe1JqePisuqtPNVIL1kW30SDk8qA6+DJqXimaTDgdyimYFh1EuAGXhzdoRWORAvgR9KeEWRS14hJ2Qzdxo54xbfgSVCVhTuMc8i6FAs0AI34a649Q9ac0XR/TMA2rteJQil+LYG1F/8G7hiTYEzGub56na3iDqGOYFrQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nSCdasUpi6KqLL6d/ULCi+icTXxMNrTvtsBxXoSKUMk=; b=Dd05+I56A+1Z0yStKJ5+AKypM+9S8Tdph4PRpxcq0g166prU4+lBCycpxOEVh3XfoXXJg33FRlTQ9Ss7lBdy/5kjQt/Yca6Py36oScfVbQDBbDaGMKQySbFSVPR72C79mR9w7N14oOEE/3kgx/DzJB+oHUtn0xRei/i6EY4ZYN0=
Received: from DM5PR11MB1818.namprd11.prod.outlook.com (2603:10b6:3:114::9) by DM5PR11MB1339.namprd11.prod.outlook.com (2603:10b6:3:d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Thu, 27 Feb 2020 23:41:19 +0000
Received: from DM5PR11MB1818.namprd11.prod.outlook.com ([fe80::d136:2a22:28ef:2075]) by DM5PR11MB1818.namprd11.prod.outlook.com ([fe80::d136:2a22:28ef:2075%12]) with mapi id 15.20.2750.021; Thu, 27 Feb 2020 23:41:18 +0000
From: "Darren Dukes (ddukes)" <ddukes@cisco.com>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
CC: Fernando Gont <fernando@gont.com.ar>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Topic: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Index: AdXsmBuY1tqntXEdSECRXFRXLBEUfQAGBU6gAADKcAAACkqsgAAzaEIAAAdQVYA=
Date: Thu, 27 Feb 2020 23:41:18 +0000
Message-ID: <2ABD702A-21C0-488D-B83B-46261CB8072F@cisco.com>
References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D9364A1C2@DGGEMM532-MBX.china.huawei.com> <4038_1582727829_5E568295_4038_168_1_53C29892C857584299CBF5D05346208A48DB381A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <8ca30058-b8cf-cba4-524d-99b34e2b01d6@gont.com.ar> <CAJE_bqebPnJUoSL0KYCabh9tY5iMSFmq_Cg=7oxy4xsrOjs9Zg@mail.gmail.com> <CAJE_bqfUXUiaQQLvMVaQ2bB0-BNh2zkMwA5B1Tm5uXt=t8yu+g@mail.gmail.com>
In-Reply-To: <CAJE_bqfUXUiaQQLvMVaQ2bB0-BNh2zkMwA5B1Tm5uXt=t8yu+g@mail.gmail.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=ddukes@cisco.com;
x-originating-ip: [2001:420:c0c8:1005::424]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 172f7397-231d-404b-39f5-08d7bbde8b34
x-ms-traffictypediagnostic: DM5PR11MB1339:
x-microsoft-antispam-prvs: <DM5PR11MB13396DF7E5F4A90F0C131BD3C8EB0@DM5PR11MB1339.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03264AEA72
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(396003)(39860400002)(376002)(346002)(199004)(189003)(2906002)(33656002)(81166006)(8676002)(81156014)(76116006)(186003)(91956017)(64756008)(66556008)(66476007)(6916009)(71200400001)(66446008)(4326008)(2616005)(6512007)(86362001)(5660300002)(6506007)(6486002)(478600001)(316002)(966005)(53546011)(8936002)(66946007)(36756003)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1339; H:DM5PR11MB1818.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: obCyndI7YDTJHsa4CldaYZQRNwimQtysHsuTxhwhYz10BELGNYsR4Dg3Y5wwUrU1vfivatG38OpQrTL/0FO8NnS3aTwmRHiGO7HHdo+Y7AdzezQFhPblE+URIT4BymeN4HaP6/yjfMT0SMPK+iqDOhkarW+cZFk9aFzgbe3B9ooLXvZ1xAS9yjfluhif6QW8OQz5aRo13+Is670koFdEQjRGCeSYOKEckvaXGt34S2FCldVp56NfkQ2/EmutqlSLLwj5qkSb6KWwb/GSrm53csQoRipdYU/XYFIeDX93IG8mA8QzzRib3lPve8H86IvDsIeU1GEZlJ+22EKwseTvFE8lEy4DIggNtEUSqbe5hoWki+gKcXGj5vc1c5AnO236Lk3txslZL8qoq3KuXBEhVhi3hVkMPMiBPhR7JWjgTYtzey1u6wAlrHezqmc24ZL6FtmvT0OuG5sgjqcDoW3Rwuis5R3BMXT2FnZI6JpUQjO9wm3Oq1angyEo1dv5VCW/Lw+4VW+SxdPiwGLLRg5i9g==
x-ms-exchange-antispam-messagedata: +D2LJh30GOx4cN73RspyYvjElExyoi7F16YkDy8J2btn4WX7ufzW/oWVUBBVi+ZnTAu/IV5TEsFNa7z5CNtUBDtSAzrB32RNmh8rV0NnL9nlHlUKB61bAgpZM1KPu3N2J0wIIhU0EAnjMjVqyNnQPzfyFrBi7wKJqWswbVhelGU=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <947EC77C69327C46B384608FD79D3E69@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 172f7397-231d-404b-39f5-08d7bbde8b34
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 23:41:18.7524 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: R/R7HqzIOAcgXMY1VKC8QknTLqD7/td/GKbEEwRWh/OkhJHkDsVttl5rzel6jnZl4xZoR2erhlM2+Jujdk5y2g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1339
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RGkqaVyLGgpyHhX4bYOpIMY-YNA>
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: Thu, 27 Feb 2020 23:41:32 -0000

Hi Jinmei, allow me to address the two technical concerns you raise in this email, upon which it appears this interpretation of RFC8200 hinges for you.  You state:
> 
> Aside from that this
> interpretation logically doesn't make sense as it's not compatible
> with AH or PMTUD, if it could be justified with that logic, we
> wouldn't have had to go through the long debate in promoting RFC2460

I know a lot of documentation and work has been done with SPRING and 6man since that debate.

1 - I expect everyone reviewing and commenting on draft-ietf-spring-srv6-network-programming (NETPGM) to have fully read draft-ietf-6man-segment-routing-header (SRH) as stated in section 1 NETPGM.
1.1 - remember SRH section 5 defines a deployment model for the SR domain applicable to both documents.

2 - AH is not defined for SRH (section 7.5 of SRH) so the question of how SRH with a PSP SID affects AH is not applicable to NETPGM.

3 - PMTUD within an SR domain is unaffected by PSP.
3.1 - Section 5.3 of SRH, provides recommendation on how MTU is handled within an SR Domain for traffic encapsulated for its journey within the SR domain.  i.e. it is not reliant on PMTUD within the SR Domain.
3.2 - Regardless, as others have stated, performing PSP and reducing the size of a packet has no impact on PMTUD.

I hope this helps clarify your understanding of the current state of the art vs what may have been assumed at some point in the past before this was clarified by 6man and SPRING.

Thanks
 Darren

> On Feb 27, 2020, at 3:11 PM, 神明達哉 <jinmei@wide.ad.jp> wrote:
> 
> On Wed, Feb 26, 2020 at 11:39 AM <jinmei@wide.ad.jp> wrote:
> 
>>> So... is the plan to ship a document that violates RFC8200?
>> 
>> Please forgive me asking some clarification question that seems to be
>> obvious for others: which part of
>> draft-ietf-spring-srv6-network-programming-10 violates RFC8200?  From
>> a quick read of it, Section 4.16 seems to describe the removal of an
>> extension header from an IPv6 packet at a forwarding node.  Is that
>> the one referenced as a violation?  Or is it something else, or are
>> there others in addition to 4.16?
> 
> I've not seen any feedback, but according to the thread messages since
> then, it's now pretty clear to me that it's at least about Section
> 4.16 (or more specifically, 4.16.1, which describes "PSP").
> 
> In that case, I have to oppose moving this doc forward in its current
> form.
> 
> First, as (I believe) Brian also pointed out, the description of this
> section is obscure.  And, in fact, it wasn't immediately clear to me
> whether it's a violation of RFC8200 (hence the question).
> 
> Secondly, with more accurate understanding of the intent of this
> section through the discussion of this thread, it's now clearer to me
> that it's a violation of the following part of RFC8200:
> 
>   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.
> 
> in that an intermediate node specified in a routing header with
> segment left > 0 deletes an extension header.  So at least this
> document has to clearly declare updating RFC8200 and get consensus
> about it before moving on.  It's not done yet.  Hence my objection.
> 
> It's surprising to me that some people seem to (still) argue it's not
> a violation because this node "is identified in the Destination
> Address field of the IPv6 header" (before swapping it with the next
> hop specified in the routing header).  Aside from that this
> interpretation logically doesn't make sense as it's not compatible
> with AH or PMTUD, if it could be justified with that logic, we
> wouldn't have had to go through the long debate in promoting RFC2460
> to RFC8200 in the first place.
> 
> The conclusion at that time (I wouldn't call it a "consensus" as I
> know not everyone was happy about it) was that
> - Such kind of insertion and deletion is indeed a violation of
>  RFC2460; that's why RFC8200 now clearly says "inserted, or deleted"
>  while RFC2460 only states "examined or processed".
> - 6man and SPRING WGs will work together to see if we can define an
>  exception to loosen the limitation so that a future version of
>  SRv6 can validly coexist the base IPv6 standard.  Until then,
>  encapsulation/decapsulation is the only standard-compliant behavior.
> 
> Now, beyond these technical points, I also have meta-level concerns.
> Here I share the frustration of Fernando, even if his word may be too
> blunt.  After the hot debate on revising RFC2460, I expected us to
> "work together" towards the goal of seeking some middleground.
> Admittedly, this process wouldn't be easy - some people who opposed to
> the insertion/deletion at that time seem to believe there's no such
> middleground anyway.  But some others seem more flexible, and, as far
> as I can see, at least everyone is open to have discussions.
> 
> But, after nearly 3 years since the publication of RFC8200, we still
> seem to have the same easy circumvention:
> - Simply dismissing the concern by arguing this is not a violation
> - Labeling those who raise concerns as innovation blockers
> - Just blaming the IPv6 base protocol as being broken (because it
>  doesn't accommodate a feature they want)
> - Insisting SRv6 just happens to use IPv6 packet format and some part
>  of spec but is not IPv6, indicating it doesn't matter whether it
>  violates the IPv6 standard
> - Pushing industry agenda instead of working together to reach consensus
> 
> I'm sad, but if this doesn't change, the only thing I, as a poor
> individual, can make objections to last calls.  At least in the purely
> technical sense, I've not seen any difference now and then.  So, the
> history would suggest even if we blindly pass this WGLC we'll have a
> very long debate at the IETF last call and just reach the same
> conclusion.
> 
> That would be a waste of time for everyone.  I hope we can be more
> cooperative instead of that.
> 
> --
> JINMEI, Tatuya
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------