panrg / path-properties

A Vocabulary of Path Properties
Other
1 stars 3 forks source link

IRSG Review (Dave Oran): Path definition #86

Closed renghardt closed 1 year ago

renghardt commented 1 year ago

From the IRSG review by Dave Oran:

In the definition of “Path”, the second paragraph says “Paths are unidirectional and time-dependent, i.e., the sequence of path elements over which packets are sent from one node to another may change.” This seems to say a path can change (i.e. traverse a different set of nodes and links) over time, rather than packets may be diverted and traverse a different path. Somehow it seems that if you allow a path to change its composition (as opposed to the dynamics of its properties), I’m not sure how path-aware networking is ever going to identify a path in a useful or reasonably stable manner.

boucadair commented 1 year ago

Paths can be loose or strict, which allows for some form of flexibility when a path is explicitly specified. Think about ERO, for example.

The time-dependent aspect can be backed with a citation to ongoing efforts, e.g., https://datatracker.ietf.org/wg/tvr/about/

daveoran commented 1 year ago

Got it! It might be a good idea to mention the strict versus loose taxonomy explicitly.

renghardt commented 1 year ago

In my mental model, there are many different paths over which packet could theoretically be sent, and any particular path keeps its composition. So if the path changes, packets that were sent over Path A are now sent over Path B and no longer over Path A. But Path A still keeps being Path A and contains the same elements, as long as, theoretically, packets could still be sent over it. If the sentence sounds like, instead, Path A would somehow automatically change its composition if packets change the path over which they're sent, that seems wrong to me. I'll try and tweak the phrasing to make it clearer what "time-dependent" means - and I guess I'm talking about a strict path definition here.

In Med's linked example, paths indeed change their composition, e.g., due to mobility. I think we can allow that as a loose path definition.

renghardt commented 1 year ago

I just added a PR to clarify the definition as intended (at least by myself), which is a strict path definition.

As I said in the PR, I would prefer to avoid adding a loose definition here, but I'm willing to discuss.

(Somehow I couldn't add Med and Dave as reviewers to the PR, or even properly mention them in the issue... I'll ask Brian who should be able to change the settings or add you as collaborators.)

cyrill-k commented 1 year ago

I also thought of our path definition more in terms of the "strict" definition. As Reese said, paths in terms of the "loose" definition can be modeled via a collection of "strict" paths. Alternatively, such paths may be modeled as an abstraction in the form of a single virtual link between two path elements, where the actual routers and links within this virtual link may change over time.

boucadair commented 1 year ago

As I said in the PR, I would prefer to avoid adding a loose definition here, but I'm willing to discuss.

I do still think that there is a value in mentioning loose/strict taxonomy (not only to address Dave's comment), but also to be aligned with existing technologies, e.g., RFC3209:

The signaling protocol model supports the specification of an explicit path as a sequence of strict and loose routes. The combination of abstract nodes, and strict and loose routes significantly enhances the flexibility of path definitions.

renghardt commented 1 year ago

Ok, I'll propose text in the PR.

renghardt commented 1 year ago

Closed via PR #103