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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 21 December 2019 19:22 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 0381B12006B for <spring@ietfa.amsl.com>; Sat, 21 Dec 2019 11:22:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 dvdU1x7pPT4T for <spring@ietfa.amsl.com>; Sat, 21 Dec 2019 11:22:33 -0800 (PST)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 462CE12004F for <spring@ietf.org>; Sat, 21 Dec 2019 11:22:33 -0800 (PST)
Received: by mail-pl1-x633.google.com with SMTP id g6so5537786plt.2 for <spring@ietf.org>; Sat, 21 Dec 2019 11:22:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gj5hvyQYRC6hiDdn7CIqOLdI76Anv+Gapl1eSQyGx2s=; b=eM3EGjlKwvMexf1b+rJqDCCL4YFoIDt0n+OFwD5g/Zrxf+f+MQ36Uv1u1S2nGJegP3 c0dMNRjETfrg+PTWyRngkJMFJIpc5p0on6AWs66mxxrSAbRZJONxuVadYUOMb8LN78Y9 fuaUFIW7LfhffDgSjGx1VyvmRnX4WVwXoaO0RRqqnFBys2hRXZIaoiKKF/AzyN7DAk5Q p0BkbTQzWwXfAC8GWltOaDr02acFUVX3puVS+T/TPByq2E113V2KQQcVr3SPDRbGJ1qd jJ29ANu6poRs92FxCJcXPTlovM1H+wfA0B9ngciVY9DVkuW2SBWYAtX63xW7w9qRiAQx HWOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gj5hvyQYRC6hiDdn7CIqOLdI76Anv+Gapl1eSQyGx2s=; b=ZLc1Orzh1uJaEIC/6EazXNWzNw19Ia1la/iMioM5Qx/6VKBj5cvNB+Dlx3T6g5X4mY OZsu3PA0quXkIZ/paQV4pMuOZ5IrCdNqf3FRbXP5UqM0LdRJAPliB7cddlBOiLVEY8NE AzOmhAUT1zhvESJv7UAu1E1LT1AC5n0wQRB88GMn9vBFhqYN+igJ+iCGBGWUZeCMJKo7 xvjtpIuuXW9f4GSa1EzQzy5HoEjSBHpdW+oQnGswRPpdryyMjYsAklYBXfr5tMQxKZLa wkaXx9uexol35iithWHypben566YvuvvAIjibUBeNW+0nNDPAMZwcaJp7G4s2V+BH2hO rp4A==
X-Gm-Message-State: APjAAAWZm8m8c3T2qZFL6sudZ9Fgay6RZCeQxSNM93BSkBm7KyLAaeNG smIi1CHcYmWu184k9YfbqqQGXfqq
X-Google-Smtp-Source: APXvYqwjmcLT/aTEuBnpWYTVlc+YfdyJa3XrCvuhDgTN3lz70y3HPzFJbj6kFzy+MWRyRq7HBOnklg==
X-Received: by 2002:a17:902:9a49:: with SMTP id x9mr309318plv.24.1576956152400; Sat, 21 Dec 2019 11:22:32 -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 h128sm18573552pfe.172.2019.12.21.11.22.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Dec 2019 11:22:31 -0800 (PST)
To: Robert Raszuk <robert@raszuk.net>
Cc: "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> <49b7e45f-a26f-cf4a-f8be-9aa917c34203@gmail.com> <CAOj+MMFBKFBxacT9Z=HR89U10d9=jG-b8ypx4ukQgb0EFfN=Uw@mail.gmail.com> <0f492db1-d168-473c-8447-9e08d51c2039@gmail.com> <CAOj+MMEom8JcffnOdH0dsDnN5hzfPASsm=0uz8O+P68=EP_z0A@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <42cac054-ac09-fff3-4ed1-1890c7803ec9@gmail.com>
Date: Sun, 22 Dec 2019 08:22:28 +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: <CAOj+MMEom8JcffnOdH0dsDnN5hzfPASsm=0uz8O+P68=EP_z0A@mail.gmail.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/rgZfn5TAlk5RXDM5141PdrZLIBE>
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: Sat, 21 Dec 2019 19:22:35 -0000

On 20-Dec-19 22:18, Robert Raszuk wrote:
> Hi Brian,
> 
>     Right, but the language in the PSP sub-section does not talk about decapsulation. 
> 
> 
> Sure as in a way there is no decapsulation there. This is Segment N-1 node not Final Segment End node.

If there is no decapsulation and the words mean what they say, then there is certainly a violation of RFC 8200. That needs to be said *explicitly* in the text so that the community can decide what to do about it.

> 
> Of course the other way to look at this would be to conceptually describe this as decapsulation at *each* segment end point and on most just copy the SRH to a new IPv6 header and on PSP happening on Segment N-1 to not copy it.

No, we're not talking about "conceptual" decapsulation. If a packet addressed to address A contains a packet addressed to address B, it isn't going to get to B unless A physically decapsulates it. (Since we're in a state where Segments Left == 0, we're already at the end
of the segment list in the RH, so I don't see where Segment N-1 comes in.)

Where are the diagrams showing example packets to illustrate exactly what happens during PSP?

> 
>     I think the root problem may be using the word "pop", which is relevant in the MPLS label stack context but not here, without additional definition.
> 
> 
> Well I agree. "POP" does not sound like the best terminology choice here for SRH removal or deletion :). Now all what is needed for WG to convince Pablo for massive editing .... 

Yes, but that is precisely because MPLS is designed to support a label stack with pushing and popping, and IPv6 is not designed that way. So "pop" really is completely false terminology when referring to an IPv6 header.

If the explanation was that the original packet is fully decapsulated at the PSP node, so that the SRH disappears along with the rest of the encapsulating header, we wouldn't be having this conversation.

> Happy Holidays,

Indeed!
   Brian