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

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

Dear All,

On Tue, Feb 9, 2021 at 1:53 AM <[e-mail]> wrote:

> Hi Brian, all,
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Panrg [mailto:[e-mail]] De la part de Brian
> > Trammell (IETF)
> > Envoyé : lundi 8 février 2021 08:38
> > À : Spencer Dawkins at IETF <[e-mail]>; Adrian
> > Farrel <[e-mail]>
> > Cc : [e-mail]
> > Objet : Re: [PANRG] Dependence on
> > https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/
> >
> > 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.
>
> [Med] I don't like this definition as it leaves out many aspects that we
> discussed when consolidating the definition in the properties draft.
> Theresa made a great job in considering various aspects: take into account
> overlays, underlay, service planes, endorse service function chains,
> abstract paths defined as an AS path, uncast/multicast, etc.
>
> I don't think that simplification is helpful here.
>
> If a path definition is needed and, for logistic matters, you don't want
> to cite the properties draft, my suggestion is to copy and paste that entry
> rather than defining a new one.
>

Narrowing the focus to what-not-to-do, because I think the issues are
different for -questions ...

What Med suggests here is what I have in the editor's copy of
what-not-to-do, with the diff at
https://github.com/panrg/draft-dawkins-panrg-what-not-to-do/commit/c9e40e60e854b19bf9acee0be31120f438226ac0,
with the additional point that I have references to -questions and
-properties, where the cut-and-paste came from.

It's worth making two points here.

   - The current definitions of "Path" and "Path Aware" are given as a
   courtesy to the reader, but where we've ended up on this in email
   discussion is that the contributions included in -what-not-to-do covered
   path aware technologies that were proposed without reference to our current
   definitions (some as long as four decades ago).
   - ISTM that I should just say that PANRG is now working under a more
   rigorous definition of "Path" and "Path Awareness", with a pointer to the
   RG, but -what-not-to-do is recording history that wasn't based on the
   current rigorous definitions.

Thoughts?

Best,

Spencer