Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 19 December 2019 21:39 UTC

Return-Path: <brian.e.carpenter@gmail.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 895771208F8 for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 13:39:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 dLqKKgdVXcMB for <spring@ietfa.amsl.com>; Thu, 19 Dec 2019 13:39:46 -0800 (PST)
Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) (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 119A3120865 for <spring@ietf.org>; Thu, 19 Dec 2019 13:39:46 -0800 (PST)
Received: by mail-pj1-x1042.google.com with SMTP id n96so3132470pjc.3 for <spring@ietf.org>; Thu, 19 Dec 2019 13:39:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=w5mWpO7lv6I3OYhmhIVPKtPPxhIVHkumUWnDRP1xEMU=; b=tJpLig7YWWPgrtTvzZIv7WXPXgdR5P9OkT8rCnqkZ+lI4IZB0ptY7npQmU/wQ+fGOg qmhXGdtpxKpxjS/Z34svnRkS6DuTtd+WBjKt/c0++ECazljrVojeogX5X81AWYnCXRz7 j97+7hcNLOL6ZbrhWa8rC5Nf+xKDbmdnCygXvbE0e66M4BtCIa/GBy2naIJCPrUZfGbz I6jGefHSGj+WyiAZDlpakOC1+AuDc+oHec36GPPAPA6KRk0tMuxHCyWllQGSxbCYXIcp tl6+eKy4+Ws3SxNBtnVG1l9YkJu7LGXgqn9FEE0hxCanBfrXkdd9Q9DW+egmA14P4Af3 MZwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=w5mWpO7lv6I3OYhmhIVPKtPPxhIVHkumUWnDRP1xEMU=; b=B8ehbyGYZ8OPkAzPmJrWLlyhWGGjCF2VH6B6voEM7fZ2oLR6Z7HS9qUvc5ItobG74A 6Lm2NEyCJWyvqYtjl5GAqj3stQ6BeDZsWrAWUkn5zK1FbF5KsAJdTEtzEbAJF73Hb3P7 nq6D6Oj3VCYQVKrCPjiOwrmGPCb+QEqID7Nk00XYugcEfJz7dubkkTp/AEslOViFUoCf Se+AebUeyMQwzzIqxzKvrJ5JgkvSEfjntXvA8OQBlBNixV83nDQ+TYtr7PPJFG+SBSDq 4lV4ZTNJ1F7flrIYgJlDPc2Fz+XUt6NOqKaSBBrciVCXsWXXQwNkDxjsZgEF+03FI9tM +9SA==
X-Gm-Message-State: APjAAAVPMB4sSg2T84l5DLQJm0jXuFmNYiB/pEcfGbhR+mL0Owmp1oYL YFn0e13fynPz0+P75HoGWmB8uw78
X-Google-Smtp-Source: APXvYqxCfQA07GZO+4Kvky2BBKmg3e3EE7JYwCssaSKGKtl/op21Ra9QpnRXgu8VHOa1RQ6IinCIBA==
X-Received: by 2002:a17:90a:fe02:: with SMTP id ck2mr11793582pjb.10.1576791585315; Thu, 19 Dec 2019 13:39:45 -0800 (PST)
Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id f127sm10011063pfa.112.2019.12.19.13.39.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Dec 2019 13:39:44 -0800 (PST)
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, "spring@ietf.org" <spring@ietf.org>
References: <157609408568.11496.11799785813274132900@ietfa.amsl.com> <4c762fc5-8a61-e182-a9cc-d45b0f586ccc@gmail.com> <3A12D735-7899-4679-8FC8-DF8875D40A62@cisco.com> <628e5dfb-7ba4-d841-ebeb-cfc52d7294f1@gmail.com> <ACEF56BF-B851-43B2-9211-B6C39C34DB63@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <49b7e45f-a26f-cf4a-f8be-9aa917c34203@gmail.com>
Date: Fri, 20 Dec 2019 10:39:39 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <ACEF56BF-B851-43B2-9211-B6C39C34DB63@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/12x3H-5I6rSIojStCFyZ-dh7ato>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt
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, 19 Dec 2019 21:39:49 -0000

Sorry, I am still confused, see in line:

On 20-Dec-19 00:53, Pablo Camarillo (pcamaril) wrote:
> Brian,
> 
> Inline.
> 
> Thank you,
> Pablo.
> 
> -----Original Message-----
> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> Date: Saturday, 14 December 2019 at 21:04
> To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, "spring@ietf.org" <spring@ietf.org>
> Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt
> 
>     Hi Pablo,
>     
>     See in line:
>     
>     On 14-Dec-19 22:34, Pablo Camarillo (pcamaril) wrote:
>     > Brian,
>     > 
>     > Many thanks for having another look to the draft. Please see inline [PC].
>     > 
>     > Thank you,
>     > Pablo.
>     > 
>     > -----Original Message-----
>     > From: spring <spring-bounces@ietf.org> on behalf of Brian E Carpenter <brian.e.carpenter@gmail.com>
>     > Date: Wednesday, 11 December 2019 at 23:06
>     > To: "spring@ietf.org" <spring@ietf.org>
>     > Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt
>     > 
>     >     So, I've tried to look at this with fresh eyes, and thanks for the
>     >     various updates and clarifications.
>     >     
>     >     (I'm still not on the SPRING list so please leave me in CC.)
>     >     
>     >     I remain a bit puzzled. First, a quote from the SRH specification
>     >     (draft-ietf-6man-segment-routing-header-26):
>     >     
>     >     > 4.2.  Transit Node
>     >     > 
>     >     >    As specified in [RFC8200], the only node allowed to inspect the
>     >     >    Routing Extension Header (and therefore the SRH), is the node
>     >     >    corresponding to the DA of the packet.  Any other transit node MUST
>     >     >    NOT inspect the underneath routing header and MUST forward the packet
>     >     >    toward the DA according to its IPv6 routing table.
>     >     
>     >     Next, a quote from the current draft:
>     >     
>     >     >    SRH[n]: A shorter representation of Segment List[n], as defined in
>     >     >    [I-D.ietf-6man-segment-routing-header].
>     >     > 
>     >     >    When a packet is intercepted on a wire, it is possible that SRH[SL]
>     >     >    is different from the DA.
>     >     
>     >     Huh? That would be extremely unusual in the normal interpretation
>     >     of a routing header, where is RH[SL] is by definition the next
>     >     destination where the RH will be processed. Any other node is a transit
>     >     node, and I don't see anything in draft-ietf-6man-segment-routing-header-26
>     >     that allows for anything else. So it seems to me that the quoted statement
>     >     needs an explanation of why it isn't a violation of
>     >     draft-ietf-6man-segment-routing-header-26, not to mention why it's useful.
>     > 
>     > PC: This occurs when we use the reduced SRH as described in: https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.1.1
> 
>     OK, well that definitely needs to be added to the draft, since it is very far from
>     obvious to a newcomer.
> 
> PC: I have removed this sentence from the latest revision of the draft. Unneeded, misleading and covered in the SRH. See rev07. Thank you for your comment.

Thanks.

> 
>     > If you think this sentence does not reflect that, I can edit it for the next revision of the draft. 
>     >     
>     >     That leads us back to:
>     >     
>     >     > 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.   }
>     >     
>     >     This is clearly a breach of RFC8200, but it can never be reached if DA == SRH[SL]. 
>     
>     > PC: PSP executes at the segment that is the Destination Address.
>     
>     I am probably being stupid, but I don't understand what is "penultimate" about
>     a condition where SL == 0 and the packet has reached the node that owns DA.
>     Where will the packet be sent next, since it's already at the final DA?
> 
> PC: You are reading line 14 of a pseudocode. In the previous lines we have received a packet with Segments Left = 1, and we have decremented by one such value.

If I have this right, the PSP case is inserted in this pseudocode:

  S14.   Update IPv6 DA with Segment List[Segments Left]
  S15.   Submit the packet to the egress IPv6 FIB lookup and
            transmission to the new destination

which produces:

  S14.   Update IPv6 DA with Segment List[Segments Left]
  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.   }
  S15.   Submit the packet to the egress IPv6 FIB lookup and
            transmission to the new destination

That's explicitly removing the header before forwarding the packet. How
can that not be a violation of RFC 8200? And where is it forwarded to, since
we are already at the DA?

    Brian