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

神明達哉 <> Fri, 28 February 2020 00:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21F483A0A8F; Thu, 27 Feb 2020 16:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4LaY9kJFtuJC; Thu, 27 Feb 2020 16:48:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 568B43A0A8B; Thu, 27 Feb 2020 16:48:31 -0800 (PST)
Received: by with SMTP id v2so998985wrp.12; Thu, 27 Feb 2020 16:48:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oIsl1lf7oroi3bQb/R0TuO/qvoWsmoQ9CPjD1lvKR3Y=; b=CR7pdyEfxuWK5ndl43PL5P2GZUjvrq4EPT3WPET1PwsllNZ1fNyianYtF8GReRFTqH sSZGpvkSSOa1GermsUyOt69bLN7Ni8FSV3JAbJ7myfExkhK2Y4WH45BQzP88MjRfhZIb getFJprMK3c7LV0hGKpVNFkKUe+Vt9heC46RLO+e32py5zEWu9EcUYjjPOJ3kxXALMls w2hY5ix/o08192OKJv7wHLGM0Utd2POVlHlU0+ZffXSDUjF6c4nPH7cphe9LiHZqsCQm c8fVxBq1m0B35bw6NhLyPyBqfY8M1oBWuh49RMTei5MQIXGXrWLgMVKWjQgRkOXCEYyb UztQ==
X-Gm-Message-State: APjAAAU4/2POZ0+5b7eG72ZTe5FzEcr4pDf5vMwBfsvvYkvcr16oCjzM dh1ir78KpfDDnltDBSgvnNAd3jkppvlNhT+rIZA2Zpf8
X-Google-Smtp-Source: APXvYqzqUIuWnQA6RjkYxsZxBFlq8m02bS8hBT5Iq9aWoDh6ZDz5jsQO4UnbvvD1O1zkiDgbCwgdDBee5bLw4XaH2OQ=
X-Received: by 2002:a5d:4584:: with SMTP id p4mr1685988wrq.25.1582850909656; Thu, 27 Feb 2020 16:48:29 -0800 (PST)
MIME-Version: 1.0
References: <> <4038_1582727829_5E568295_4038_168_1_53C29892C857584299CBF5D05346208A48DB381A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <> <> <>
In-Reply-To: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Thu, 27 Feb 2020 16:48:17 -0800
Message-ID: <>
Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: "Darren Dukes (ddukes)" <>
Cc: Fernando Gont <>, SPRING WG List <>, "" <>, draft-ietf-spring-srv6-network-programming <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Feb 2020 00:48:33 -0000

At Thu, 27 Feb 2020 23:41:18 +0000,
"Darren Dukes (ddukes)" <> wrote:

> Hi Jinmei, allow me to address the two technical concerns you raise
> in this email, upon which it appears this interpretation of RFC8200
> hinges for you.  You state:

> > Aside from that this
> > interpretation logically doesn't make sense as it's not compatible
> > with AH or PMTUD, if it could be justified with that logic, we
> > wouldn't have had to go through the long debate in promoting RFC2460
> I know a lot of documentation and work has been done with SPRING and 6man since that debate.
> 1 - I expect everyone reviewing and commenting on draft-ietf-spring-srv6-network-programming (NETPGM) to have fully read draft-ietf-6man-segment-routing-header (SRH) as stated in section 1 NETPGM.
> 1.1 - remember SRH section 5 defines a deployment model for the SR domain applicable to both documents.
> 2 - AH is not defined for SRH (section 7.5 of SRH) so the question of how SRH with a PSP SID affects AH is not applicable to NETPGM.
> 3 - PMTUD within an SR domain is unaffected by PSP.
> 3.1 - Section 5.3 of SRH, provides recommendation on how MTU is handled within an SR Domain for traffic encapsulated for its journey within the SR domain.  i.e. it is not reliant on PMTUD within the SR Domain.
> 3.2 - Regardless, as others have stated, performing PSP and reducing the size of a packet has no impact on PMTUD.
> I hope this helps clarify your understanding of the current state of the art vs what may have been assumed at some point in the past before this was clarified by 6man and SPRING.

This is not my point (I was actually afraid about having this type of
response when referring to AH/PMTUD.  In retrospect it was probably a
mistake...); I didn't mean NETPGM violates RFC8200 because it would be
incompatible with AH/PMTUD.  My point was that it doesn't make sense
to refer to the phrase "the node...identified in the Destination
Address field of the IPv6 header" to justify the argument that NETPGM
doesn't violate RFC8200.

Now, please note that I'm not necessarily saying that the NETPGM draft
shouldn't move forward simply because it violates RFC8200.  If the
authors/WG believe NETPGM can be an exception to this part of RFC, it
should say it updates this part of RFC8200 and explain why it's
justified (where the discussion about AH/PMTUD will matter).  This
will certainly draw more attention from various kinds of reviewers and
you may find it difficult to defend the claim for these reviewers, but
I don't think it necessarily impossible.  The current version of the
draft doesn't do this, and authors and its supporters just seem to
dismiss the RFC violation with the awkward reference to the
"Destination Address" text.  That's what concerned me.

JINMEI, Tatuya