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

Stefano Salsano <stefano.salsano@uniroma2.it> Thu, 27 February 2020 13:26 UTC

Return-Path: <stefano.salsano@uniroma2.it>
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 95D083A0834; Thu, 27 Feb 2020 05:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=KBfcaJPJ; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=ryVZuLEp
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 eRi46M4NMYmb; Thu, 27 Feb 2020 05:26:26 -0800 (PST)
Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.16]) (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 C4AEA3A084E; Thu, 27 Feb 2020 05:26:25 -0800 (PST)
Received: from smtpauth-2019-1.uniroma2.it (smtpauth-2019-1.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 01RDQA6a028364; Thu, 27 Feb 2020 14:26:16 +0100
Received: from [192.168.100.176] (unknown [160.80.103.191]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id 51014120F5A; Thu, 27 Feb 2020 14:26:02 +0100 (CET)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1582809962; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0jON1esKPs7bLsNhCE3k2L9HqemVUIaK/ug00ReJ+fI=; b=KBfcaJPJ+918vIcxMVHF7evW6mpBUOdjPqpIMJHnaA0cqKkyyWNi8TJeUlWsprKT8zEKTe ZhnaDPsv3IXcRABA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1582809962; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0jON1esKPs7bLsNhCE3k2L9HqemVUIaK/ug00ReJ+fI=; b=ryVZuLEpwp4YFVKkddG1jigFoIA+eL5IsqY7HMHJlVmKlBSs5Acl10A4rTVSPATWU9T3Kc SH4p8RJ+2kdPRVyahB8o3YgZIyfQjJ93cISY7DKP1RMF3RxkA/o++ui/uo/mZcmU6ZR/e0 SKTkwt2pl+TfAWn7VQghCgU3D6Xk0WWA9BrelNHnPD5Yg+yUwfKyNjm7mX+tAlMgMrtsMB OQYgsloqFynnRbX1DgYgrEznwmpPHoJrEJ8YCCQ3+rdpqryZPXBfm3lK5uYwJYkz4JG0JM CXkkEheU/WPZn0l8uPzHam4AgRaDPZicfVtIJxex9VKADQ/LwrNHc7RqL2D2sw==
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: Fernando Gont <fgont@si6networks.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>
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>
From: Stefano Salsano <stefano.salsano@uniroma2.it>
Message-ID: <36dfd49f-6a17-dd29-adb6-b7e3d0ae2f47@uniroma2.it>
Date: Thu, 27 Feb 2020 14:26:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <d37ff964-aa4f-388b-5199-66428d49336c@si6networks.com>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Language: it-IT
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IRChtvFMl6uTlHnbsm6080I0aZo>
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 13:26:28 -0000

Fernando,

Il 2020-02-27 10:07, Fernando Gont ha scritto:
> 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?

no, this is a wrong interpretation
the penultimate segment is removing the extension header for a packet 
whose Destination Address *is its own address*
> 
> 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.

during the processing, as described in the pseudo code, there is an 
intermediate step in which the packet *processed inside the router* has 
the destination address of the last segment and the router removes the SRH

it is never suggested/allowed in the draft that a router can remove the 
SRH from a received packet that does not have a router address as DA

Stefano

> 
> 
> 
>>   - 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,


-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : stefano.salsano@uniroma2.it
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************