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

[Joachim Fabini <[e-mail]>]

Hi Brian,

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

[...]

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

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




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