Re: [PANRG] Dependence on https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Brian,

On Mon, Feb 8, 2021 at 1:38 AM Brian Trammell (IETF) <[e-mail]>
wrote:

> hi Spencer,
>
> (and hi Adrian, this message touches on peripheral questions in your
> message last week, though I'll answer the actual questions in another
> thread, hopefully today but I'm not optimistic about cycles)
>
> <chair hat off, -questions editor hat on>
>
> When I originally proposed/wrote the questions draft, I meant the title of
> the document to be taken literally: "we don't quite yet know what we are
> doing, we're informed by kinda-related work in a few inter-network and
> intra-network architectures, let's figure out whether there is a here
> here". So from that originalist viewpoint, references to -questions are
> fine, but not if those references are there because -questions has answers.
>
> Scoping the work in the RG such that even knowing what we're talking about
> requires the questions draft to define "path-aware networking", which it
> now does in section 1.1. Aside to Adrian's main point, he points out that
> that definition itself uses the word "path", which is also quite overloaded
> depending on your viewpoint.
>
> So my original desire to leave "path" explicitly undefined in -questions
> (indeed, question 1 in section 2.1 is "what is a path" with more words) is
> probably not going to fly.
>
> <-questions editor hat off, chair hat on>
>
> As co-chair, I do prefer not to have all three of the documents depend on
> each other in a cluster. I'm not sure where we are with the completion of
> the path properties draft, though I suspect there remains much more to talk
> about than with questions and what-not-to-do.
>
> What we care about, though, for the document dependency graph is merely
> the definition of path. The current state of the definition of path in path
> properties is as follows:
>
> >    Path:  A sequence of adjacent path elements over which a packet can
> >       be transmitted, starting and ending with a node.  A path is
> >       unidirectional.  Paths are time-dependent, i.e., the sequence of
> >       path elements over which packets are sent from one node to another
> >       may change.  A path is defined between two nodes.  For multicast
> >       or broadcast, a packet may be sent by one node and received by
> >       multiple nodes.  In this case, the packet is sent over multiple
> >       paths at once, one path for each combination of sending and
> >       receiving node; these paths do not have to be disjoint.  Note that
> >       an entity may have only partial visibility of the path elements
> >       that comprise a path and visibility may change over time.
> >       Different entities may have different visibility of a path and/or
> >       treat path elements at different levels of abstraction.  For
> >       example, a path may be given as a sequence of physical nodes and
> >       the links connecting these nodes, or it may be given as a sequence
> >       of logical nodes such as a sequence of ASes or an Explicit Route
> >       Object (ERO).  Similarly, the representation of a path and its
> >       properties, as it is known to a specific entity, may be more
> >       complex and include details about the physical layer technology,
> >       or it may be more abstract and only consist of a specific source
> >       and destination which is known to be reachable from that source.
>
> This is precise, but not succinct; this looks like a definition we need to
> talk about some more. However, I suspect that we as an RG would endorse the
> essence of the definition, something like:
>
> "Path:  A unidirectional sequence of nodes and links over which a packet
> can be transmitted, such that nodes represent devices which process packets
> at some layer(s), and links connect the nodes."
>
> and that we could lift this into Section 1.1 of -questions.
>
> Thoughts?
>

I think this (and, potentially, Joachim's reference in his e-mail) might be
useful for -questions, but the thing with -what-not-to-do is that the
definition of "path" (and "path aware") was pretty darned fluid across the
set of people who proposed "path-aware technologies" dating (in
-what-not-to-do) as far back as ST in the late 1970s. So it seems
reasonable to me for us to just say that, in what-not-to-do. I thought that
giving pointers to the current RG definitions might be helpful for some
readers, but maybe we'd do better if we just included one-line definitions
for "path" and "path aware" that would likely have made sense to the last
four decades of protocol engineers.

Your suggestion, "Path:  A unidirectional sequence of nodes and links over
which a packet can be transmitted, such that nodes represent devices which
process packets at some layer(s), and links connect the nodes.", is about
as minimalist as I can imagine. It would be more accurate historically if
"nodes" were "hosts", but that's just me being pedantic.

My suggestion for "Path Aware" might be "Path Aware: a technology intended
to exploit knowledge about the properties of traffic intended for a
destination and the properties of a path to that destination in order to
make decisions about what to send and how to send it". I think that is
accurate for the technologies included in Section 6 (and for ECN, if we are
adding that technology).

Thoughts?

Best,

Spencer


> Cheers,
>
> Brian
>
> > On 8 Feb 2021, at 02:33, Spencer Dawkins at IETF <
> [e-mail]> wrote:
> >
> > Hi, Brian and Jen,
> >
> > I apologize for causing confusion, but between the insertion of
> explanations of "Path" and "Path Aware" in
> https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/, it
> looks like I now have a dependency on both
> https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/  (for "Path
> Aware") and
> https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ (for
> "Path").
> >
> > The dependence on
> https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ seems like
> no problem, because it's also in the publication process.
> >
> > The dependence on
> https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ is a
> bit more problematic, because that draft is still in the RG.
> >
> > So, two questions.
> >       • Do we have any thoughts about when we're likely to request
> publication on
> https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/?
> >       • Assuming that the answer is "not very soon", I note in the
> current text in
> https://github.com/panrg/draft-dawkins-panrg-what-not-to-do/commit/c9e40e60e854b19bf9acee0be31120f438226ac0
> hasically says "here's the definitions of 'Path' and 'Path Aware' that the
> RG is using, but all of the contributions contained in this draft predate
> the formation of PANRG, so may not reflect the descriptions in the drafts
> where those terms are defined". How wrong would it be to make that clearer
> in the next version of the draft, so that there isn't a dependency on
> https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/?
> > I'd like to do the right thing, but I was included in the recent
> "AUTH48" for cluster 248 with the RFC Editor, so I'd love to not delay
> publication unless there's a really compelling reason to do that ...
> >
> > Please advise, of course.
> >
> > Best,
> >
> > Spencer
> > _______________________________________________
> > Panrg mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/panrg
>
>