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

"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com> Thu, 27 February 2020 21:07 UTC

Return-Path: <pcamaril@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 66ACF3A0C0D; Thu, 27 Feb 2020 13:07:52 -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=aewzMO+e; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uyNcYQbP
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 btPyh1haeLoM; Thu, 27 Feb 2020 13:07:50 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E0F3A0C0B; Thu, 27 Feb 2020 13:07:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8212; q=dns/txt; s=iport; t=1582837670; x=1584047270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ou+3aXClQnONR5l8czdtfWRGIKcOg7NSR+/FlGkRrsA=; b=aewzMO+enSho6G5dcoRf5M1uLVPJXAA5MSeIp308/4x+7dhfBe0M65D4 AXsRkJnW3rF7qsHgmm0MzI0DNyFBiMYMJ1ZRfNL3rCsCTluQILyEVk6VE TJsFmqa/+ek/6RvQ2UJ8Q6o4BtOSND32UBNu/Q6E9VP6WiKmp4qBqGZ+A c=;
X-IPAS-Result: A0DDAAAoL1he/5RdJa1mGQEBAQEBAQEBAQEBAQEBAQEBEQEBAQEBAQEBAQEBgXuBVCQsBWxYIAQLKgqECoNGA4pnToIRiWOOMYJSA1QJAQEBDAEBGAsKAgQBAYRAAheBcSQ4EwIDAQEBAwIDAQEBAQUBAQECAQUEbYU3DIVjAQEBAQMBARAREQwBASwLAQsEAgEIDgMDAQEBAQICHwQDAgICHwYLFAEICAIEDgUigwQBgkoDLgEDC6R4AoE5iGJ1gTKCfwEBBYUODQuCDAMGgQ4qhSAMhnkagUE/gREnIIIeLj5rGQGBFkkBAQKBKjkXgnoygiyNcII6O55xRAqCPI0ehRGENhyCSYgbhE6LfESPeYldkB0CBAIEBQIOAQEFgWkigVhwFTsqAYJBUBgNjh0YIIM7hRSFQXQCgSeLR4EzATBfAQE
IronPort-PHdr: 9a23:zo4n+x8eedK8Sv9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUERoMiMEYhQslVdaOAEjyNv/uRyc7B89FElRi+iLzaBIHAsv1alzMr3H39iYcSkmtEw1zK6y1ApTVk8m8y+G1/dvUfhlMgz2+J7h1KUf+pgTKvc5QioxnYqo2xwCBpHxUM+hb3mJnI1uPknOert+95pti7zhdt7o6+shMXL+yf6MjUacZAQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.70,493,1574121600"; d="scan'208";a="425773869"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Feb 2020 21:07:49 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 01RL7nhW013684 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2020 21:07:49 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Feb 2020 15:07:48 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Feb 2020 16:07:47 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Feb 2020 15:07:47 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WHfQ2SLmUW0BiStJnSaJRreja9x0VXNIes8LiVEX6zLSPyzX7oznDKetpXk+1/Trb8ux0EV+zPi/kx6xvLq9ByNeAN+b1YNUAtT0y739epLlYjNHaTyDhfvoBkVrlceL/iS1QHTOW25wO3IGLwECQ3Uej2E09qnEqarsQKtLOv4H2rzhFJV7kt6fUqQoiL5kFRxZ5+OITzIq/PPv51EEfv/KEEbBZpTwkoJ6RIIgiyAGT9X4fdj0fppJZftDSALd/WZM+1K/fgSIXsf+tsdeLlJj5KAZhbNtGghHSUg+Col9dq7/SMMJf+uPV+n33Fhxidek/cDqyFD1Soh8ism++w==
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=ou+3aXClQnONR5l8czdtfWRGIKcOg7NSR+/FlGkRrsA=; b=bQUe78+gpHKyE7L5Mq0DKuTRF7NpNSjSdrSSQbi2a10L4mjMlr89FACUsauSICfsrxwZbVQyzhV5O+Xdo/znAKlFbc/4ii49fOCKgb/iASjdMO5bzASRVPVZtsWg2g1VIn5gR0o9gFAHjZYHtp5YIy+kXGW4/DCYHaNgF12F0FWqu2O9v/6xrDCEfTV6v5EdTbp6WrMQrdCxgrp2fLZ8aAPhA3hQV8euEp/gGHXLhvquQF/seLoSac74+LQ06VFdhu+Lc57LSuj8M6zeVdXIA2GX4o3LaJYrAG/gdvtTJIwB/5T6OULGFm0U6Gckpnksg2wOt3EKuQb6OrDZ7w9xaA==
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=ou+3aXClQnONR5l8czdtfWRGIKcOg7NSR+/FlGkRrsA=; b=uyNcYQbPR7SSIiq1fwB63emQFatwAPN/YnJIMKwFznccAAz3oMm8w+1AVyT/MXPEd15wnKI2G6+9My9epRRRaeKO1eIhPH0l0Cet/wlxsOo//0awol2pwJzihCTauaCrhfRLx/UCzjfXl+7pulZ4JZnKyLW4qmNcflWniTQ1RUM=
Received: from MWHPR11MB1374.namprd11.prod.outlook.com (10.169.234.8) by MWHPR11MB1904.namprd11.prod.outlook.com (10.175.54.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Thu, 27 Feb 2020 21:07:46 +0000
Received: from MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::e481:a191:e31:f948]) by MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::e481:a191:e31:f948%12]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 21:07:46 +0000
From: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
To: Fernando Gont <fgont@si6networks.com>
CC: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Warren Kumari <warren@kumari.net>, "john leddy.net" <john@leddy.net>, Bob Hinden <bob.hinden@gmail.com>, "Zafar Ali (zali)" <zali@cisco.com>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Topic: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Index: AQHV7Mw1Z+bRbaP7BEi4D3jb6AgA/qgtycOAgAAK2oCAAAQCAIAAQ+MAgAAHeYCAAJXKAIAABzwAgADR3IA=
Date: Thu, 27 Feb 2020 20:38:43 +0000
Message-ID: <6B0AA69E-67CF-466C-A588-4305D341A61E@cisco.com>
References: <F88E3F76-DD4B-4807-A458-85FABFF20D96@gmail.com> <5D218BFB-0D6F-4F7D-858F-B571A67DC47F@leddy.net> <CAHw9_iJ_ipEvU0NUx44XbK0_DrLe_GRw6G=m+chK4wZcRP8BMg@mail.gmail.com> <ACA082A4-BC78-4C63-9F91-5C9A44F47642@cisco.com> <8abfd5a1-e806-3598-c389-8214b3d09447@si6networks.com> <10919_1582792881_5E5780B1_10919_216_1_53C29892C857584299CBF5D05346208A48DB590F@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <d37ff964-aa4f-388b-5199-66428d49336c@si6networks.com>
In-Reply-To: <d37ff964-aa4f-388b-5199-66428d49336c@si6networks.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pcamaril@cisco.com;
x-originating-ip: [213.4.210.210]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6cc51180-de60-4807-af63-08d7bbc91805
x-ms-traffictypediagnostic: MWHPR11MB1904:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MWHPR11MB1904B96918A01A7AE1E32510C9EB0@MWHPR11MB1904.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03264AEA72
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(396003)(376002)(39860400002)(136003)(189003)(199004)(4326008)(2616005)(26005)(53546011)(6512007)(2906002)(478600001)(81166006)(81156014)(6506007)(8936002)(33656002)(8676002)(71200400001)(86362001)(64756008)(91956017)(6916009)(6486002)(6666004)(76116006)(36756003)(66946007)(66446008)(186003)(107886003)(966005)(66476007)(316002)(66556008)(54906003)(66574012)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1904; H:MWHPR11MB1374.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: Kpw/WsM0Ig8k0brGcsqrNFzsxSOTL8n6sbYioAb9N3zn3khq99w8+n9Jird8z+YSBjqfAyICRY6rLn/EmJp5wYZAYoSMHBDL1LDVlRSN4dAolLpxsnynkEgz+bBnLsBsnGxMbQ7RgeoncjCQc0q5TgN7fH2uBLfI1L5FLO+qQ3dKGCz0h0iAxl6173EORuGD18aTj4GdJ9et+Vp+UtFRJy1uNtAFeKomBlhNPTgQPnojSbN6vZ1NCQck+rtaI0j/B/fYiUffywSDAbihqh0YqJG1yAimDjLap9Xlhd44c1wF4IF393lWTDM1FU3lPWenV12gSX/PUWy8PDT65J5wi8RXYqbFER/RzvjGGKX2i6RlLRmJNH1Sshvgjt1eR2vOyvvcFAjCwjXmBDYrmZWvTkqrAse0jcs5tfyzHiSAfjsuOqRlm71uhpA2n1Sk7HOV1CmFuoy0s3q+Eu04ZDbm48VMw2/ousqgwgrWuQNG0Ve/Ol8GrQ9Q/gEF9nFsJpAyQV77HjQ/wy3R8ClZ6byaDA==
x-ms-exchange-antispam-messagedata: cshpOfNwhfzlZgEAQDCaCU7r5Gh/Rt0ccXLaa3HizKKGf7LbfuoleUE0P/0Vg/3oXyrKH5PYorLoY9tdNtpkle2y3aRaoo9S3oKE919izw74uPoEnyilVizmQALNGrgx47IL/23fbC4IVqUoMHPBKA==
Content-Type: text/plain; charset="utf-8"
Content-ID: <644508C40A37F44FA95744F122266589@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6cc51180-de60-4807-af63-08d7bbc91805
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 21:07:46.1011 (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: A1DyLv4T8P9MKjZGkOlh3Xq/PPQQ3WbnRMvwmWHoBpHC6U5r/MrovOU7jk3uKyDqKv+m8+4wMYMVHH2H7Ianmw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1904
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mj8-X4oa0yiBO509-uJROfnXN2k>
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 21:07:52 -0000

Fernando,

In order for an IPv6 node to process the SRH (or other routing header) the address of such router needs to be in the IPv6 Destination Address. Right?

   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.

From this text it is clear to me that we can process extension headers when the packet reaches the node identified in the Destination Address field of the IPv6 header.
From this text it is clear to me that we can delete extension headers when the packet reaches the node identified in the Destination Address field of the IPv6 header.
Processing at the node identified in the Destination Address field of the IPv6 header has exactly the same treatment in the quote above as deletion at the node identified in the Destination Address field of the IPv6 header.

This has nothing to do with SRH insertion by a transit node. This was moved to a separate document and is out of scope of the draft that is being WGLC.

Cheers,
Pablo.

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> on behalf of Fernando Gont <fgont@si6networks.com>
Date: Thursday, 27 February 2020 at 10:07
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, Warren Kumari <warren@kumari.net>, John Leddy <john@leddy.net>
Cc: SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

    Bruno,
    
    On 27/2/20 05:41, bruno.decraene@orange.com wrote:
    > Fernando,
    > 
    >> -----Original Message-----
    >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fernando Gont
    >> Sent: Thursday, February 27, 2020 12:45 AM
    >>
    >> Hello, Eric,
    >>
    >> On 26/2/20 20:18, Eric Vyncke (evyncke) wrote:
    >>> Writing this without any hat,
    >>>
    >>> Please note that on the logical side, it still have to be "proven" that this idea is strictly forbidden by RFC 8200.
    >>
    >> Here's the proof part:
    >>
    >> 1) Isn't IPv6 end to end?
    >>
    >> 2) How do core components of IPv6, such as AH and PMTUD work in the
    >> present of intermediate nodes that can add and/or remove arbitrary
    >> extension headers?
    >>
    >> It should be clear from the above that EH insertion/deletion is forbidden.
    > 
    > This draft does not propose that intermediate node add extension header.
    >   - If this is not clear to you, please read the draft.
    
    What is this:????
    
    4.16.1.  PSP: Penultimate Segment Pop of the SRH
    
        The SRH processing of the End, End.X and End.T behaviors are
        modified: after the instruction "S14.  Update IPv6 DA with Segment
        List[Segments Left]" is executed, the following instructions must be
        executed as well:
    
      S14.1.   If (Segments Left == 0) {
      S14.2.      Update the Next Header field in the preceding header to the
                     Next Header value of the SRH
      S14.3.      Decrease the IPv6 header Payload Length by the Hdr Ext Len
                     value of the SRH
      S14.4.      Remove the SRH from the IPv6 extension header chain
      S14.5.   }
    
    
    Isn't this having the penultimate segment fo a packet removing an 
    extension header for a packet whose Destination Address is not even it's 
    own?
    
    Doesn't this read a bit as "the router was the DA of the packet, after 
    you change the DA to that of the next waypoint, if you realize Segments 
    Left == 0, remove the SRH"?
    
    (which does not even comply with the now infamous "interpretation" of 
    RFC8200 that if you are the DA, you can add/remove EHs.
    
    
    
    >   - If it's clear, please let's stick to technical comment on _this_ draft. Bringing irrelevant points to the discussion is really not helping (both the discussion  and the argument).
    > 
    > This draft does not propose that intermediate node add/or remove arbitrary  extension header.
    > 
    > This draft, and more specifically the PSP flavor [1], is about removing the SRH header by an SR EndPoint.
    
    Seriously?
    
    
    > - with regards to PMTUD, can you clarify how reducing the size of the packet break PMTUD? And if there is an impact, let's remember that this is the source of the packet which instruct the SR EndPoint to remove the SRH.
    > - with regards to AH, the SRH specification explicitly states that the use of SRH with AH by an SR source node is _not_ defined [2]. 
    
    Do you understand that AH should be usable for all IPv6 traffic?
    
    
    [....]
    >> (that's what Errata's are for, after all... and it should be clear that
    >> the EH processing part, overall, needs improvements).
    > 
    > Again, thank you for that, I believe this is useful.
    > But while this errata is not reviewed and accepted, RFC 8200 stands as is.
    
    The errata is a clarification, not a change. Of course RFC8200 stands: 
    EHs are not deleted or added en route to destination.
    
    
    Thanks,
    -- 
    Fernando Gont
    SI6 Networks
    e-mail: fgont@si6networks.com
    PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
    
    
    
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------