Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

Robert Raszuk <robert@raszuk.net> Sat, 07 December 2019 16:04 UTC

Return-Path: <robert@raszuk.net>
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 642751202A0 for <spring@ietfa.amsl.com>; Sat, 7 Dec 2019 08:04:06 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 csFwKcCF5C-Z for <spring@ietfa.amsl.com>; Sat, 7 Dec 2019 08:04:03 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 96BA31207FE for <spring@ietf.org>; Sat, 7 Dec 2019 08:04:03 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id g1so10551880qtj.6 for <spring@ietf.org>; Sat, 07 Dec 2019 08:04:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gHlMurKGHaVjCcaNrJHJXS1mBnZBfIHgkY9OZhMlMqI=; b=DfhleeVtY9OUQYiumjOcT7m3va6J3DLirab3BFDVmowRr6NUM3PBc7B0Hc2hGmJZVv GXPcE4IIbl8uToANfW0+5ivTX17zFF6nbOieOeHbeVVrqlSAXKCI3WbHrpm95IvcPf52 uFPnpystEuoGdqMVxVe81RDdibA2PMnBCCFLRGrD6OV09xU5hvTkbVx7CfKycIl9MSM6 SI7NKcs5UioTSTowFjC/7ne8S6ZSwPGNDgqelcqeJpPAeh4KNP+a8cFYBZXwwC+yYcYB rRg+RVYBxlLg7cJ8b6rexai7DuGagkHhwd9sj/UIEy7cWmgD014W4yaHIqZMzZ0Xb91+ deVQ==
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; bh=gHlMurKGHaVjCcaNrJHJXS1mBnZBfIHgkY9OZhMlMqI=; b=JeOuU4OJsviY+vj5aFYsrgshkuNkkHmQvahnXuNiQL1Smmx6SibExWZfiOQfamaU6l L9rvzTJCfGcsB89t38q3ciU8X0GTpxSllrexOUA3sfnibw3r4FEcFzocAkmomfars8oX jghsfnBjl2WSyrV5b5pjOnK5W5LiRvAxaHoL3go9E0DNnR1tDjcmNIgLTE3rH6pRlCTZ vnqCXVIfo7any2LpKR+SPTMNK/2FnspNQNiu35CLX+GbDUx3YuJpOS0z7T4iGjPYo8fO gbBfIRMi/G5U+YQ9vVnPfxfRPbzouem1EKgg5kNkWkHVBqAfbVX2MhIUet82yJi69/Sk CESg==
X-Gm-Message-State: APjAAAVU1Fu82npFUj+Zf3DW3wi6TeHJ24MGgPykvbHSaQsitCa00S8t NOjlTurxb1uAwiTYqoLv7rwcqcVGKjxVGj25Oh6/Nw==
X-Google-Smtp-Source: APXvYqwkiRCI4EqQMyczW2+kUsZFtW6fLaDNK9OaJZeMHp45pZG0jCGXxstTD4LXJOHxTQAs/KItJwlsn3vFVn3mkPQ=
X-Received: by 2002:ac8:1017:: with SMTP id z23mr17625973qti.154.1575734642702; Sat, 07 Dec 2019 08:04:02 -0800 (PST)
MIME-Version: 1.0
References: <f2a0ad13-0eba-6f5a-1d3c-e45e2780f201@si6networks.com> <D666EA6E-E8E9-439A-9CDE-20857F03CB65@employees.org> <4255AD3B-379C-45BF-96E1-D3D9141A684F@liquidtelecom.com> <d59de54e-c7f8-be67-1e77-b051735d40a6@gmail.com> <3bce7b18-ea45-d29f-5dfb-1d3258b07d1e@si6networks.com> <c6e1f690-b0bf-9f45-8fa7-92ed182c5b04@gmail.com> <a2cc5cbd-ac06-e193-307c-3ffe5b21b0b1@si6networks.com> <CAOj+MMGaSooQbsRzJC2yCrFeHYFvbQgLY=merdwzjBFNXAj17g@mail.gmail.com> <09B00E32-37A1-4F06-81B9-6EE88639BC1D@cisco.com>
In-Reply-To: <09B00E32-37A1-4F06-81B9-6EE88639BC1D@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 7 Dec 2019 17:03:54 +0100
Message-ID: <CAOj+MMHtc_-=e-CUFKV4zNE9B2vqx-JzqB8tgRmsv=n35vd18w@mail.gmail.com>
To: "Darren Dukes (ddukes)" <ddukes@cisco.com>
Cc: Fernando Gont <fgont@si6networks.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, rtg-ads <rtg-ads@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a38aed05991f4fc1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/3ktZH2Oc3TvelWegxumaqmj8Jjs>
Subject: Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)
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, 07 Dec 2019 16:04:06 -0000

Exactly - That is why I thought  it does make sense to make this crystal
clear to everyone here.

>From some comments it seemed that either folks do not understand or want on
purpose to make false assertions only to mud the waters :)

All - have a great weekend,
Robert.



On Sat, Dec 7, 2019 at 4:57 PM Darren Dukes (ddukes) <ddukes@cisco.com>
wrote:

> Hi Robert, thank you for injecting clarity to this thread.
>
> draft-ietf-spring-network-programming defines PSP, and the only relevant
> portion of this thread to that draft is Discussion #3.
>
> As I stated in another post, I consider #3 closed as this is clearly
> complying with RFC8200.
> https://mailarchive.ietf.org/arch/msg/ipv6/6Uy_JuMm7W66kTql_o7FYisxkg0
>
> The remainder of the discussion in this thread is unrelated to
> draft-ietf-spring-network-programming.
>
> Thanks
>   Darren
>
> On Dec 7, 2019, at 6:47 AM, Robert Raszuk <robert@raszuk.net> wrote:
>
> Hey Fernando,
>
> (pop when you are the destination but SL!=0 is essentially 'in the
>> network removal')
>
>
> I was trying to stay out of this but I have one fundamental question or
> observation this entire debate seems to be about.
>
> In the context of SRv6 there are two parallel discussions
>
> *Discussion #1* - It is about inserting, modifying or deleting SRH by
> nodes which are not in the outer IPv6 header of the packet
>
> *Discussion #2* - It is about RFC8200 compliance when the node doing
> insertion of SRH is *the* destination of the packet as read verbatim from
> the outer IPv6 header.
>
> *Discussion #3* - It is about RFC8200 compliance when the node doing
> modification or removal of SRH is *the* destination of the packet as read
> verbatim from the outer IPv6 header.
>
> First let's observe that RFC8200 is only defining the behaviour regarding
> EH processing in the context of destination address of the IPv6 outer
> header: "identified in the Destination Address field of the IPv6
> header.identified in the Destination Address field of the IPv6 header. "
>
> Therefore stating that SL value before local decrement matters in this in
> respect to being compliant to the IPv6 RFC is at best just an individual
> interpretation. Besides the pseudocode says it black and white "S14.1.   If
> (updated SL == 0) {". We do all sort of processing decision after
> decrementing the values ... think TTL :)
>
> So back to reality ...
>
> *Discussion #1* - I think we all agree that to accomplish that RFC8200
> would need to be updated.
>
> *Discussion #2* - I think we also all agree here that to accomplish this
> RFC8200 would need to be updated as it does says clearly that "Each
> extension header should occur at most once, ..."
>
> *Discussion #3* - It seems clearly that there is no issue with compliance
> with RFC8200 and that if penultimate segment midpoint decides or is
> instructed to pop SRH it sure can and still be 100% compliant with current
> wording of RFC8200.
>
> So other then so much foam what is this debate all about ?
>
> Cheers,
> Robert.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>