Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Robert Raszuk <robert@raszuk.net> Wed, 11 December 2019 00:55 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 80746120220 for <spring@ietfa.amsl.com>; Tue, 10 Dec 2019 16:55:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 xqqgoIc_vyLg for <spring@ietfa.amsl.com>; Tue, 10 Dec 2019 16:55:45 -0800 (PST)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 C83341201AA for <spring@ietf.org>; Tue, 10 Dec 2019 16:55:44 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id c16so9803959qko.6 for <spring@ietf.org>; Tue, 10 Dec 2019 16:55:44 -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=vVFtRd69p0QU/mpr2OFJReq+gpSRQFkcvYWWBuje1lg=; b=Hqn5sZ7t2mPenjWPTImPE3EaViHqeQjRdZJiSY7dv728Pde5lLjW+sYKFB31m3KC3l ql/n760HryLOPDQvlquEzSlotF0K964WItjtqi4PumDv2Q144arfBQX1mhAh6DGvMUdx YuJ6qQPAwQehTBOmNwUxem4j+U+peLqBLBqWqspvHSMM9anyuY02AYIKWcZFYmMbOx1z WOybmSDoyHRarkWd/esD/eSqVd1gnHcQ+KwwS/A//CrdrRjn9pbS53dQbEAg2DCtb9Cv 54ZtyCevtjmhdR8y1vlT4T6IutTk3du7b3dmITaeE/G4nFq5X4pSv6y6E4gtbr1Xsl85 sNCQ==
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=vVFtRd69p0QU/mpr2OFJReq+gpSRQFkcvYWWBuje1lg=; b=ewrwIiXYL5tHpkf/K3qFF4Fw3TwFNy+fSfuTfb4KB/VqETmvSqIGVhaCkJDpROutMd rClGPK3uC8m62LL/cPyBUFVCEGcAbOBdY3hW2veA7lhyvoERkEKYBKDHexTPtXSE+G3S qab8PUqBa1jlMlK/gInUzT0uMvksAIOqcKHMrir4mce+q+UFISReQwm1ZeDQQxnrCSmt MwM+5vaKo7DiSrbr7Dj3npLWSUZrHCN17obp4Ejd9fPxyGEKGlmFMTFa+jDngsSjgs+B MO5h3L7W4YSlje3klbR1YngsCOVwe5mnY3uT2yqNEd0Xy+1fdMbGdsjON+QxMjqPygUs MaaA==
X-Gm-Message-State: APjAAAWTypONKDk5wOZ0Kx/zWtR0+y4Kg3QbmzVr24pI26xRoVjXywoy AVDX/lS/Io6x1bSMl4h2zVQKDJkVXNurOrGkDl9GZQ==
X-Google-Smtp-Source: APXvYqxMLfRro/+gg4yHXEU3TDIMw220LLHn7wpvHZcU9wpdgvVfGi4jP5ddp7Z58CZsbFwEHREisVRxn4Eh3lFh1fM=
X-Received: by 2002:a37:6087:: with SMTP id u129mr536860qkb.219.1576025743619; Tue, 10 Dec 2019 16:55:43 -0800 (PST)
MIME-Version: 1.0
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <6c674995-8cc7-c024-4181-60b160910f75@si6networks.com> <29345_1576001884_5DEFE15C_29345_229_5_53C29892C857584299CBF5D05346208A48D250B7@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <89402a30-129b-314f-90f1-ba6efcdd6a88@si6networks.com> <795b498c-39b9-a3d8-e9f8-77fd53f48e6a@joelhalpern.com>
In-Reply-To: <795b498c-39b9-a3d8-e9f8-77fd53f48e6a@joelhalpern.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 11 Dec 2019 01:55:32 +0100
Message-ID: <CAOj+MMEEBKsR5B1icNGbTd=mU-HejAK=pL24n9TMt219TJperA@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Fernando Gont <fgont@si6networks.com>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009b0d2e05996316b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/6vQjKSRHID6m4e-C492bqk-biEQ>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
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: Wed, 11 Dec 2019 00:55:47 -0000

Bravo Joel !



On Wed, Dec 11, 2019 at 1:49 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> Fernando, I really wish I could agree with you.
> But I can't.
>
> In 8200, it is clear that the meaning fo "Destination Address" for an
> IPv6 packet is the value placed in the IPv6 destination address field.
> the fact that if we had looked ahead we might have said something
> different does not change what words we chose to use.  If I am going to
> insist (as I have in other contexts) that other folks live with the
> words we compromised on in 8200, then I have to live myself with the
> words we compromised on in 8200.
>
> I have concerns about whether PSP is a good design.  I am trying to
> write a useful note on the topic.  (And without such a note, I can not
> expect anyone to care about thoughts in my head.)   But I can not and
> will not claim that PSP violates RFC 8200.
>
> Yours,
> Joel
>
> On 12/10/2019 6:16 PM, Fernando Gont wrote:
> > Bruno,
> >
> > On 10/12/19 13:18, bruno.decraene@orange.com wrote:
> >> Fernando,
> >>
> >> Thank you for spelling out your comment, plus on the WGLC thread.
> >> More in-line
> >>
> >>> Bruno,
> >>>
> >>> On 5/12/19 12:15, bruno.decraene@orange.com wrote:
> >>> [....]>
> >>>> This email starts a two weeks Working Group Last Call on
> >>>> draft-ietf-spring-srv6-network-programming [1].
> >>>>
> >>>>
> >>>>
> >>>> Please read this document if you haven't read the most recent version,
> >>>> and send your comments to the SPRING WG list, no later than December
> 20.
> >>>>
> >>>>
> >>>>
> >>>> You may copy the 6MAN WG for IPv6 related comment, but consider not
> >>>> duplicating emails on the 6MAN mailing list for the comments which are
> >>>> only spring specifics.
> >>>>
> >>>>
> >>>>
> >>>> If you are raising a point which you expect will be specifically
> debated
> >>>> on the mailing list, consider using a specific email/thread for this
> point.
> >>>>
> >>>> This may help avoiding that the thread become specific to this point
> and
> >>>> that other points get forgotten (or that the thread get converted into
> >>>> parallel independent discussions)
> >>>
> >>> Penultimate Segment Popping describes/specifies the removal of a SRH at
> >>> a place other than the final destination of the packet.
> >>>
> >>> Such behavior violates RFC8200, which specifies:
> >>>
> >>     > 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.
> >>>
> >>> Note, of course, that the reference of "Destination Address" in RFC8200
> >>> is clearly the final destination of the packet -- for instance, RFC8200
> >>
> >> I hear and can understand your reading of RFC8200.
> >
> > Could you please check RFC8200, and tell me what other possible
> > interpretation of "Destination Address" you might have, in the context
> > of RFC8200.
> >
> > RFC8200 does not even specify any routing header types. SO...where's the
> > ambiguity?
> >
> >
> >
> >> At minimum, I think that we can agree that there is another reading, as
> expressed by other WG participants, and hence I disagree with "of course".
> >
> > No, I argue that there is not. IN fact, I argue that folks have been
> > following that strategy for way too long, and that's quite frustrating.
> >
> >
> >
> >> Personally, I understand "Destination Address" as "Destination Address
> field of the IPv6 header." as indicated explicitly in the text quoted.
> >
> > The quoted text is from RFC8200. In the context of RFC8200 the
> > Destination Address can only contain the ultimate destination of the
> > packet. Where's the ambiguity?
> >
> > And let me ask you, as chair, another question, that will lead you to
> > the same place: is IPv6 and end to end protocol?
> >
> >
> > The fact that I may claim that RFC8200 contains a receipe for BBQ does
> > not actually mean that that's the case.
> >
> >
> >
> >> I'm fine with having this clarified with 6MAND chairs and AD. That been
> said, the Internet AD would have an opportunity to DISCUSS this.
> >
> > For the record, I think this is a major issue that should be cleared
> > before it can be claimed that there is consensus to request publication
> > of this document.
> >
> >
> >
> >>
> >>> does not specify any routing header type, and hence the meaning is
> >>> unambiguous (there's no destination other than the final destination of
> >>> the packet).
> >>>
> >>> This is of course in line with IPv6 being and end-to-end protocol, and
> >>> crucial for other related mechanisms to work as expected (such as IPsec
> >>> AH). Please also check:
> draft-smith-6man-in-flight-eh-insertion-harmful.
> >>>
> >>> So, in order to proceed with the document, there are multiple options
> >>> forward:
> >>>
> >>> 1) Just remove the corresponding text/behavior
> >>
> >> That is indeed one option. But as of today, this is not my assumption.
> >>
> >>> 2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,
> >>> re-encap)
> >>
> >> SRH insert is out of scope of this specification. So yes, IPv6 encaps
> is used.
> >> We are talking SRH removal. I'm assuming that you are referring to PSP.
> My understanding is that this function (PSP) is to distribute the
> (forwarding plane) load between the PSP and the USP. In a way similar to
> MPLS PHP. But in all cases, this is not about SRH insertion.
> >
> > It's about SRH removal, which is also forbiden by RFC8200.
> >
> >
> >
> >
> >>> 3) Do the necessary standards work to update RFC8200, such that it
> >>> allows this sort of behavior, and only ship the network-programming
> >>> draft for publication when at least 6man has consensus to proceed on
> >>> that path.
> >>
> >> Not the preferred path as of today.
> >
> > Yes, it should be evident that it seems the preferred path has been
> > (starting with EH insertion at the time) to circumvent existing
> > specifications.
> >
> >
> >
> >>
> >>> P.S.: I will go through the document once again... but the same
> >>> reasoning should be applied to any EH-insertion/removal at a place
> other
> >>> than the source of the packet or its final destination.
> >>
> >> It looks to me that SRH insertion and SRH removal are to be treated
> differently.
> >
> > I don't see how or why. Both violate the same requirement in RFC8200.
> >
> >
> > Thanks,
> >
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>