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

Mark Smith <markzzzsmith@gmail.com> Thu, 27 February 2020 22:57 UTC

Return-Path: <markzzzsmith@gmail.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 3924F3A045B; Thu, 27 Feb 2020 14:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level:
X-Spam-Status: No, score=-0.598 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CSrRxCHx_XJK; Thu, 27 Feb 2020 14:57:39 -0800 (PST)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0EF3A041A; Thu, 27 Feb 2020 14:57:39 -0800 (PST)
Received: by mail-oi1-x235.google.com with SMTP id q81so1017991oig.0; Thu, 27 Feb 2020 14:57:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zCLPK7Cpy8RkoHpAnX2TnhqkCpbLbeKxHpHHsDIrk8Y=; b=nf4DCtG4GV403+hWGMdSQociBuCNC7Iq//GU9M8FPPm7ELtJzLngL4+2/kCXrfOivi DH2Gxdd7ttUGALexaS6fHxRLItEMD6Bz1bry1FPXEqrVbSNH7NZnVLlMtNvpBit6mCch ecYp+nlnUoKJu3RW04VInCMbp7D2vQoJPrELe9wbJv8pTHq29WEw5BPHeLLM3YbjE9Vc sqIBhml+X0yIzathGKABHqMWHTb3F9yVb/TVcHgcvV/sE8sUYbDHLkpJmLpKuXEPkD+e 2cR8sv528gLHnLDtqup28o1AfIItP/99lmPu7XtFmFgao85TgC/Ah/MYI5V5fFMgvWk+ pLlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zCLPK7Cpy8RkoHpAnX2TnhqkCpbLbeKxHpHHsDIrk8Y=; b=O5SY52U3ml45e7KB6y/A9CJDTeig6AzoEbV160iMCbhRl+5ujsCMlaREmJO+cHzqDY 53zu5bQhthXIqkT1lYKIPG+b4xl52wnYwGjKU2Ox/KCs2Sxj/EBHyn1x5Z7zav4Zs5c0 Sq3fU15d+cfcT+ln570wF/9CjWvzEipz7tNI9tRsiiZYJFRBIlU0N7bVfbg6pT1yiqTe ooqqg8zC1CvgxFhruemcrPW0rYsRTglBLXRKPXg8zdBXcGSHJhjPT+fpPCjzPGMGkQym Zh0dQ9BtJbSuMLAqEKemM6jTElFrwfgRQdUobhXVFei3SSZOJQqIXL6c10V5DTlLo6um m59g==
X-Gm-Message-State: APjAAAXK2NI7B5rVrR8ud9jmxjlHw1FeSybzWtiE2gNNVG3cS5ZblifT FQEnoZMRZ3VBPGkb1LrArDhVPdF/YYOvfMU6Y/DRLA==
X-Google-Smtp-Source: APXvYqx4YPEZNvtVTs9uvzdfL/yLBl/GW7hCrhCyC17ki0NjjW5qQTV8sGCVMzaafeA5k/WIdrv12NmccLlrX0rjFRE=
X-Received: by 2002:a05:6808:916:: with SMTP id w22mr1038150oih.7.1582844258803; Thu, 27 Feb 2020 14:57:38 -0800 (PST)
MIME-Version: 1.0
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> <DM6PR05MB6348E24C7B3334B45571B7F2AEEB0@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB6348E24C7B3334B45571B7F2AEEB0@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 28 Feb 2020 09:57:12 +1100
Message-ID: <CAO42Z2yGfwMkvztBivin_BqGE2dqmb+9q20Wt0YUsKJeGt+NxA@mail.gmail.com>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>, 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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pHokna53Zo3O9CzGEVjG84RWyI4>
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 22:57:41 -0000

Hi Ron,

On Fri, 28 Feb 2020 at 08:30, Ron Bonica
<rbonica=40juniper.net@dmarc.ietf.org> wrote:
>
> Jinmei,
>
> The current discussion is about Penultimate Segment Popping (PSP) (Section 4.16). Normally, when an IPv6 node processes a packet that includes a Routing header with Segment Left equal to 1, the node decrements Segments Left and forwards the packet, with the Routing header intact. In PSP, when an IPv6 node processes a packet that includes a Routing header with Segment Left equal to 1, the node removes the Routing header and forwards the packet, without the Routing header.
>
> The question is whether PSP violates the following clause from Section 4 of RFC 8200:
>
> "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."
>
> A literal reading of this text suggest that any segment endpoint (i.e., any node referenced in the Routing Header) can process, insert, or delete any extension header. This is because when a packet arrives at a segment endpoint, one of its addresses appears in the IPv6 Destination Address field.
>

Some other text that is relevant to the above Section 4 from Section
4.4, "Routing Header":

"The Routing header is used by an IPv6 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   destination."

Can intermediate node DAs ever be multicast IPv6 addresses?

If the answer was no, then that means that

"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."

can only be referring to final unicast or final multicast DAs, not the
intermediate node DAs in an RH.

I wondered if SIDs in the the SRH could be multicast.
'draft-ietf-spring-srv6-network-programming-10' doesn't mention the
word 'multicast' at all, and neither does
'draft-ietf-6man-segment-routing-header-26'.

Regards,
Mark.






> At least one RFC contradicts this literal reading. Section 3.3.3.1.1.2 of RFC 4302 says that the payload length and next header fields of the IPv6 header are immutable. PSP would change both of these and break AH processing.
>
> When RFC 4302 was published, nobody questioned the assumption that the payload length and next header fields of the IPv6 header are immutable. Therefore, we can assume that it was a commonly held belief.
>
> Some argue that none of this is a problem because the SRH is incompatible with the IPv6 Authentication header (see Section 7.5 of draft-ietf-6man-segemnt-routing-header-26).
>
> Others argue that PSP may break more than IPv6 AH. Other applications may, may concur with the RFC 4302 reading of RFC 8200. If they rely on payload length and next header fields of the IPv6 header being immutable, they will also break.
>
>                                                                     Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: spring <spring-bounces@ietf.org> On Behalf Of ????
> Sent: Wednesday, February 26, 2020 2:40 PM
> To: Fernando Gont <fernando@gont.com.ar>
> Cc: bruno.decraene@orange.com; SPRING WG List <spring@ietf.org>rg>; 6man@ietf.org; Lizhenbin <lizhenbin@huawei.com>om>; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
> Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
>
> At Wed, 26 Feb 2020 11:45:14 -0300,
> Fernando Gont <fernando@gont.com.ar> 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?
>
> --
> JINMEI, Tatuya
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!X7yacQY8b6Y0TpWJZiqa09s9YN5jOWOtfAZJteY4jOHczN4U3b7fl6FDtYPDLknI$
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------