"As a path consists of a sequence of path elements, which can be nodes or
links, our definitions do not enforce specifying an interface or
sub-interface as part of the path.
We would like to make this clearer in the draft and we are wondering if the question comes from the choice of the term "access technology". We think what we actually mean here just the "link type" on the physical or link layer, no matter if in the access network or anywhere else on the path. Does renaming the property help? Or do you think the definition of the property has to be changed?
Otherwise, maybe it would help to say explicitly that defining a property, such as "link type", does not mean that we require each entity to specify or know about this property. So, if an entity does not know about the link type or the exact interfaces involved in a path, that is not a problem, the entity can still express the path based on all path elements it knows or cares about.
Does this help?"
On being flexible to include different levels of abstractions:
"Our intention is for the definitions to be flexible enough to accomodate both [a path can be simply equivalent to a route (i.e., a list of links) or something much more complex, including e.g. slots in FlexEth connections or ODUs in OTN, aggregated links in LAG configurations, etc.]
For example, using our current definitions it should be possible to express a complex path including slots in FlexEth connections, or aggregating multiple links (physical or virtual) to one virtual link.
We will consider how to make this clearer in the next revision."
On "access technology":
"As a path consists of a sequence of path elements, which can be nodes or links, our definitions do not enforce specifying an interface or sub-interface as part of the path.
We would like to make this clearer in the draft and we are wondering if the question comes from the choice of the term "access technology". We think what we actually mean here just the "link type" on the physical or link layer, no matter if in the access network or anywhere else on the path. Does renaming the property help? Or do you think the definition of the property has to be changed?
Otherwise, maybe it would help to say explicitly that defining a property, such as "link type", does not mean that we require each entity to specify or know about this property. So, if an entity does not know about the link type or the exact interfaces involved in a path, that is not a problem, the entity can still express the path based on all path elements it knows or cares about.
Does this help?"
On being flexible to include different levels of abstractions:
"Our intention is for the definitions to be flexible enough to accomodate both [a path can be simply equivalent to a route (i.e., a list of links) or something much more complex, including e.g. slots in FlexEth connections or ODUs in OTN, aggregated links in LAG configurations, etc.]
For example, using our current definitions it should be possible to express a complex path including slots in FlexEth connections, or aggregating multiple links (physical or virtual) to one virtual link.
We will consider how to make this clearer in the next revision."