Clarify the point raised by Dave Oran in #86 - Packets may traverse a different path, but any particular path itself does not change its composition.
This is a strict path definition, and my changes are intended to clarify it, rather than change/add anything to the definition.
Upon further reflection, I wonder if this use case could be accomodated using our current path definition, e.g., if a path gets disrupted, it no longer exists as such (as no packets can be transmitted over it anymore), but a different path may have started to exist.
If this works, I would prefer to keep our path definition as-is, rather than adding a loose definition to it, as it is already long and complicated.
If we have to add the loose definition, I wonder if we should confirm this with the Research Group.
As with the other PR, I added Med and Dave in case they want to chime in as well.
If I don't hear anything within a week (by March 3rd, 9am PT) I will merge.
Clarify the point raised by Dave Oran in #86 - Packets may traverse a different path, but any particular path itself does not change its composition. This is a strict path definition, and my changes are intended to clarify it, rather than change/add anything to the definition.
In the issue, Med brought up a loose path definition, as related to the Time-Variant Routing (TVR) proposed WG.
Upon further reflection, I wonder if this use case could be accomodated using our current path definition, e.g., if a path gets disrupted, it no longer exists as such (as no packets can be transmitted over it anymore), but a different path may have started to exist.
If this works, I would prefer to keep our path definition as-is, rather than adding a loose definition to it, as it is already long and complicated. If we have to add the loose definition, I wonder if we should confirm this with the Research Group.