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

[[e-mail]]

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:[e-mail]]
Envoyé : mardi 9 février 2021 22:29
À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
Cc : Brian Trammell (IETF) <[e-mail]>; Adrian Farrel <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi Brian, all,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Panrg [mailto:[e-mail]<mailto:[e-mail]>] De la part de Brian
> Trammell (IETF)
> Envoyé : lundi 8 février 2021 08:38
> À : Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>>; Adrian
> Farrel <[e-mail]<mailto:[e-mail]>>
> Cc : [e-mail]<mailto:[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

_________________________________________________________________________________________________________________________

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.