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

[[e-mail]]

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. 

> 
> Thoughts?
> 
> 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
> 
> _______________________________________________
> Panrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/panrg

_________________________________________________________________________________________________________________________

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.