Re: [PANRG] [irsg] IRSG review request draft-irtf-panrg-questions-07

Colin Perkins <csp@csperkins.org> Thu, 24 June 2021 21:49 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: panrg@ietfa.amsl.com
Delivered-To: panrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E636E3A2C74; Thu, 24 Jun 2021 14:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=csperkins.org
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 wcccDMiQjdkS; Thu, 24 Jun 2021 14:49:37 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF0F3A2C6E; Thu, 24 Jun 2021 14:49:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=hglbG5gN5/uN4VX1KGahhLX17JMVlTp/Zish2dkzXEY=; b=kFaOoamD8Wl4VWLDEK5uTqReOZ pCcbFh5h1h7SRSo6ZWukDXCASdbdHoVmkUISyP3lc8fawXnUXGahQ7isofV8HMxIuULfn5CkUJOwy vdCRQ60ZWP29bvl3VJRGzmjHFYsAmt8f63e4i+s4x098IguG6gs41pUmxAF1ohuogyeyFzYQBDHRf hYtNAzbOTWV8vdhiXW5xFW3jbt7+flXHZqM7B653hPbt1ifwalO5n3t6N7PfeNCCJxELLAP/wNAGK hsUAY8VnRwnD5EYAIfYujMMm4YX+reN7BfSSjS2KCIDo4oqnFmaRcIE+xyX8Sg3GHJkmKzPvRHrFS D8LOfWGw==;
Received: from [81.187.2.149] (port=40402 helo=[192.168.0.69]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1lwXDy-0001pt-V5; Thu, 24 Jun 2021 22:49:31 +0100
From: Colin Perkins <csp@csperkins.org>
Message-Id: <5600214C-65FB-4F60-91DD-4B78896D7075@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D5EDB9F6-7DDD-40DF-985E-0D4E2395D9B1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Thu, 24 Jun 2021 22:49:13 +0100
In-Reply-To: <CAKKJt-e+T9YDaSN5sUJg+YNpfnbc7684TNV+0SgtwoF6LRTJ6w@mail.gmail.com>
Cc: Adrian Farrel <adrian@olddog.co.uk>, "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <laurent.ciavaglia@nokia.com>, Brian Trammell <ietf@trammell.ch>, draft-irtf-panrg-questions.authors@ietf.org, panrg@irtf.org, The IRSG <irsg@irtf.org>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
References: <797F9120-3BB0-4877-BD19-24DCB169B1AE@csperkins.org> <PR3PR07MB6826E939CD12468F56C25C23F3F90@PR3PR07MB6826.eurprd07.prod.outlook.com> <681761A2-C43B-4AC2-8974-58E5F9467981@trammell.ch> <83D26DD2-5358-4C82-8504-8D708B743ECC@csperkins.org> <CAKKJt-dObYbjQBwEnNq89SCRWAj8TALZLpZGd_2WhhYhcUDcSw@mail.gmail.com> <22A66BC8-A440-409C-8448-9FF9D33EFBDB@csperkins.org> <CAKKJt-d+t6+U6hgmiQy4dp5Y+deRnrNYgqWQW3AxToi-Zz4hCw@mail.gmail.com> <090901d766e7$75665c00$60331400$@olddog.co.uk> <CAKKJt-e+T9YDaSN5sUJg+YNpfnbc7684TNV+0SgtwoF6LRTJ6w@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.21)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/CD6uGvOkRWsUjiObNL3xw9J2aVQ>
Subject: Re: [PANRG] [irsg] IRSG review request draft-irtf-panrg-questions-07
X-BeenThere: panrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" <panrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/panrg>, <mailto:panrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panrg/>
List-Post: <mailto:panrg@irtf.org>
List-Help: <mailto:panrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/panrg>, <mailto:panrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jun 2021 21:49:43 -0000

Hi Spencer, Adrian, all,

Thank you for the detailed discussion. 

If there are no objections in the next week, I’ll move forward with the -09 draft to the IRSG approval ballot prior to publication.

Colin



> On 24 Jun 2021, at 21:08, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Hi, Colin, 
> 
> So, just to wrap this up with a bow ...
> 
> On Mon, Jun 21, 2021 at 4:50 PM Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>> wrote:
> Hi Spencer, Colin, RG,
> 
>  
> 
> Spencer does a fine job of summarising the discussions that went on and to pointing up the changes to the document that resulted.
> 
>  
> 
> To the first point, I think that it is good that 1.1 has more text on the definition of a “path” although (to me) it is unfortunate to dodge the question in this foundational document. If, as seems to be the case, the intention is to deliberately leave open to future research the meaning of “path” I feel that the document could more clearly articulate what it is about a path that is open for debate (i.e., explicitly pose the questions that the paragraph claims exist). I think that “technology dependent” may also be misleading if (as I believe is the intention) this definition is intended to apply at multiple layer of Ye Olde OSI Model.
> 
>  
> 
> However, I also accept that, as I am not willing/able to invest significantly in helping to craft text and drive it to consensus, I should get out of the way.
> 
>  
> 
> To the second point, the discussions of PCE were lengthy. It’s good that there is now a reference to 4655, but I wonder whether the text has simply introduced a new confusion: what is an endpoint? Is the end of a tunnel (i.e., a point of encapsulation or decapsulation) an endpoint? I would certainly argue it is. But, you see the problem with “endpoint”? Is it intended to mean “source of an IP packet”, in which case how does IP-in-IP relate? Is it intended to mean the source of the data flow (regardless of encapsulation) in which case it may extend beyond the IP domain. Or…
> 
>  
> 
> And I would claim that a PCE is precisely an endpoint-exposed approach. But perhaps the new text in 1.1 is ambiguous?
> 
> While
> 
> there are technologies that attempt better-than-best-effort delivery,
> 
> the interfaces to these are generally administrative as opposed to
> 
> endpoint-exposed (e.g.  PCE [RFC4655] and SD-WAN approaches), and
> 
> they are often restricted to single administrative domains.
> 
> Does the “e.g.” apply to “generally administrative” or “endpoint-exposed”?
> 
>  
> 
> But I agree that inspiring questions is the thing (we don’t do enough of that, IMHO), and without questions we can’t have answers. So, since this document clearly inspires me to ask more questions, it must be doing something right.
> 
> 
> After chatting with Brian and with Jen, all of us think that Adrian is pointing to a potential (and important, and worthwhile) new work item, as we take the heavily transport-influenced https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/> and https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/> forward to understand how much these questions, and lessons, translate into other levels of the protocol stack, including topics like tunneling and encapsulation, path selection, and routing strategies. 
> 
> After looking at the diffs from -07 to -09, I do think -09 gives enough hints about this to encourage that work, and I note that it also dovetails with some of the items that https://datatracker.ietf.org/doc/html/draft-irtf-panrg-what-not-to-do-19#section-5 <https://datatracker.ietf.org/doc/html/draft-irtf-panrg-what-not-to-do-19#section-5> identifies as "Future Work", so I think it's fair to publish https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/> at this time. 
> 
> So I think you can change the IRTF state from "Waiting for Document Shepherd" to "Waiting for IRTF Chair".
> 
> Best,
> 
> Spencer
>  
> Cheers,
> 
> Adrian
> 
>  
> 
>  
> 
> From: Panrg <panrg-bounces@irtf.org <mailto:panrg-bounces@irtf.org>> On Behalf Of Spencer Dawkins at IETF
> Sent: 21 June 2021 21:38
> To: Colin Perkins <csp@csperkins.org <mailto:csp@csperkins.org>>
> Cc: Ciavaglia, Laurent (Nokia - FR/Paris-Saclay) <laurent.ciavaglia@nokia.com <mailto:laurent.ciavaglia@nokia.com>>; Brian Trammell <ietf@trammell.ch <mailto:ietf@trammell.ch>>; draft-irtf-panrg-questions.authors@ietf.org <mailto:draft-irtf-panrg-questions.authors@ietf.org>; panrg@irtf.org <mailto:panrg@irtf.org>; The IRSG <irsg@irtf.org <mailto:irsg@irtf.org>>
> Subject: Re: [PANRG] [irsg] IRSG review request draft-irtf-panrg-questions-07
> 
>  
> 
> Hi, Colin, 
> 
>  
> 
> On Mon, Jun 21, 2021 at 11:37 AM Colin Perkins <csp@csperkins.org <mailto:csp@csperkins.org>> wrote:
> 
> Hi,
> 
>  
> 
> There were some comments from Adrian Farrel in February - did they get addressed? https://mailarchive.ietf.org/arch/msg/panrg/w62vLVTaI-1Myr_u8jPUF8a0yRQ <https://mailarchive.ietf.org/arch/msg/panrg/w62vLVTaI-1Myr_u8jPUF8a0yRQ>
>  
> 
> Colin
> 
>  
> 
> I could reasonably let Brian answer this question, but if the shepherd should know the answer ... 
> 
>  
> 
> Adrian had two comments. 
> 
>  
> 
> The first one was about the definition of a path, and that also affected  https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/>. People might remember that we chased around this for a bit, because the definitive place where we defined terms was in https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/>, which was expected to be requested for publication after both https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/> and https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/>. So we discussed adding normative references to both https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/> and https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/>, which was one way of resolving the comment, at the cost of holding both drafts in MISS-REF until https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ <https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/> was also completed. 
> 
>  
> 
> So my understanding (and Brian can correct me) is that the changes between -07 and -09 in Section 1.1 are responsive to Adrian's comment. See https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt <https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt>.
> 
>  
> 
> Adrian's second comment, which was discussed in much more detail in private email that I happened to be copied on, was about the idea that (Spencer's paraphrase) PANRG is thinking about paths from an end-point's perspective, but there's also an inside-the-network way of thinking about paths, that's equally valid to think about, that includes what we commonly think of as routing, plus traffic engineering, tunneling, and several other aspects of packet forwarding.
> 
>  
> 
>  We had two or three exchanges that were pretty interesting, but I think we left things with the idea that there may be a recursive situation going on, where a path is 
> 
> how you get from one host to another (which is mostly the way PANRG people have thought about paths, as best I can tell), OR
> how you get from the edge router next to one host to either the edge router next to the other host or the router next to the "next network on the way to the other host", OR
> how you get from one core router to another core router, OR
> how you get from one physical layer box to another physical layer box, OR 
> well, it's just turtles all the way down.
> I don't think Brian, or I, thought that PANRG intentionally planned to exclude this layered view of paths, so the best way to take that forward was to start publishing drafts that explained how "path awareness" at various layers of the network was similar to, or different from, path awareness from host to host, and that ought to be in scope for PANRG.
> 
>  
> 
> Brian, did I get that about right?
> 
>  
> 
> Best,
> 
>  
> 
> Spencer
>