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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 7 Feb 2021 19:33:44 -0600

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

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 8 Feb 2021 08:38:06 +0100

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?

Cheers,

Brian

> On 8 Feb 2021, at 02:33, Spencer Dawkins at IETF <[email-masked]> 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 ... 
> 
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg

---

From: Joachim Fabini <[email-masked]>
Date: Mon, 8 Feb 2021 17:16:07 +0100

Hi Brian,

On 08/02/2021 08:38, Brian Trammell (IETF) wrote:

[...]

> and that we could lift this into Section 1.1 of -questions.

Two references to earlier work, perhaps too technical but maybe helpful:

1. The ippm framework includes a concise technical definition of the
term path (https://tools.ietf.org/html/rfc2330#section-5 ) - it may be
useful as a starting point.

2. After some reasoning the word "can" in your path definition is
important and may conflict with the earlier extended definition. The
question I'm unsure about: is the path definition in panrg intended to
cover the set of all possible routes a packet can take from A to B -
i.e. the route ensemble as defined in
https://tools.ietf.org/html/draft-ietf-ippm-route-10#section-3.2 - or
the route actually taken by one packet under observation?

It seems to me that the two definitions differ and the extended one is
imo rather unspecific. Your (short) definition is read by me as "the set
of potential routes the packet can take from A to B (subject to some
scheduler/router decisions and packet header fields)" whereas the
extended definition is rather focusing on "the path taken by one
specific packet under observation through the network (i.e., the
packet's route)".

Reminds me of some discussions we had when developing the concepts for
AURA...

regards
Joachim

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 8 Feb 2021 11:17:03 -0600

Hi, Brian,

On Mon, Feb 8, 2021 at 1:38 AM Brian Trammell (IETF) <[email-masked]>
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)
>
> 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.
>
> 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:
>
> 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."
>

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

> 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/ 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
> >       • Assuming that the answer is "not very soon", I note in the
> current text in
> > 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 ...
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Feb 2021 18:03:23 -0000

[snip]

I don’t want to get sucked in to the debate, only to make sure the RG has a clean definition that satisfies them and so is useful for future work.

> 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. 

Indeed!

In fact, in the context of what-not-to-do, noting that the definition of “path” has been fluid or not well scoped is helpful. That is: “another thing we should not do is have a vague definition of path.”

> 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. 

Well, that is instructive!

“host” versus “router”?

“host” versus “node” versus “device” versus “node on the topology graph”?

Consider, if you will, a choice of multi-segment pseudowires [RFC5659]. You can select there may be a choice of SPEs in the network, and a choice of PWs between TPEs and SPEs.

Is the path, the path in the overlay (i.e., TPE1—PW1—SPEa—PW2—SPEb—PW3—TPE2) or the path in the underlay (i.e., TEP1—link1—R1—link2—R2—link3—SPEa—link4—R3—…   for routers Ri)?

Thus, the question is whether the path is an abstract concept applied in an layer network and applied to a logical topology, or is the path a concept in the IP/MPLS network comprising links and routers?

Ciao,

Adrian

---

From: <[email-masked]>
Date: Tue, 9 Feb 2021 07:53:39 +0000

Hi Brian, all, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Panrg [mailto:[email-masked]] De la part de Brian
> Trammell (IETF)
> Envoyé : lundi 8 février 2021 08:38
> À : Spencer Dawkins at IETF <[email-masked]>; Adrian
> Farrel <[email-masked]>
> Cc : [email-masked]
> Objet : Re: [PANRG] Dependence on
> https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/
> 
> hi Spencer,
> 
> 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.
> 
> 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:
> 
> 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."
> 

[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. 

> 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.
> publication on https://datatracker.ietf.org/doc/draft-irtf-panrg-
> path-properties/?
> 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/?
> "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 ...
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 9 Feb 2021 15:28:43 -0600

Dear All,

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

> [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.
>
> 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

---

From: Theresa Enghardt <[email-masked]>
Date: Tue, 9 Feb 2021 20:02:29 -0800

Hi all,

A quick note on the Path Properties draft: As co-author, I agree with 
the assessment that it will still need a few cycles until it is ready 
for publication. I'm planning to talk about what the RG needs to 
progress this document, and what is still missing until we can consider 
it done, at the next PANRG session.

Now, my thoughts about the dependency:
I agree that the "what-not-to-do" draft shouldn't have a dependency on 
the Path Properties draft, as I agree with the two points that Spencer 
makes below:

On 2/9/21 1:28 PM, Spencer Dawkins at IETF wrote:
>   * The current definitions of "Path" and "Path Aware" are given as a
>     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.
>
Following these points, I would be in favor of starting with that 
assertion, i.e., this document includes different technologies, which 
historically (mostly?) didn't use a rigorous definition of path.

Now, PANRG does have a (proposed, generic) definition of path, and I'm 
okay with having it pasted here, but please be aware that it *could* 
still change. So maybe say something like "The current definition of 
Path, as of early 2021"?
The questions draft does a similar thing when it says "This document 
poses questions in path-aware networking open as of 2021".

After this definition, I'm wondering if it makes sense to also say that 
the definition is generic, but each technology uses a specific 
definition: Each technology considers specific path elements at specific 
levels of abstraction, which then leads to each individual technology 
having own definition of "Path".
(This is directly related to, or a consequence of, the last sentence of 
the definition: "Note that an entity may have only partial visibility of 
the path elements that comprise a path, and entities may treat path 
elements at different levels of abstraction.")

For example, many technologies presented in the draft would define a 
path as a sequence of routers (which support the technology in 
question), and some technologies also explicitly consider (some) links 
between the routers.

Best,
Theresa

---

From: <[email-masked]>
Date: Wed, 10 Feb 2021 06:19:14 +0000

Hi Spencer, all,

I agree with your reasoning.

I sent you a PR (https://github.com/panrg/draft-dawkins-panrg-what-not-to-do/pull/5/files). Other than that, the diff looks good.

Thank you.

Cheers,
Med

De : Spencer Dawkins at IETF [mailto:[email-masked]]
Envoyé : mardi 9 février 2021 22:29
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : Brian Trammell (IETF) <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]
Objet : Re: [PANRG] Dependence on https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/

Dear All,

On Tue, Feb 9, 2021 at 1:53 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian, all,

Please see inline.

Cheers,
Med

> De : Panrg [mailto:[email-masked]<mailto:[email-masked]>] De la part de Brian
> Trammell (IETF)
> À : Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>; Adrian
> Farrel <[email-masked]<mailto:[email-masked]>>
> Cc : [email-masked]<mailto:[email-masked]>

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.

  *   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