Re: [PANRG] Comments regarding draft-enghardt-panrg-path-properties

[Theresa Enghardt <[e-mail]>]

Hi Luis,

Thank you for reading our draft and for your questions and comments.

Having discussed these with my co-author, please find our answers inline:

On 01.12.19 10:32, Luis M. Contreras wrote:
> .- The access technology is mentioned as one of the path properties.
> This implies the consideration of the client interface (or
> sub-interface) as intrinsic part of the path. Is that the case? In the
> PCE stuff, the result of the computation of a path is the Explicit
> Route Object (ERO) who is basically a serie of nodes indicating the
> selected path. By considering the client interface the definition here
> would exceed the one considering in the ERO concept, thus being the
> ERO a sub-path according to the terminology in this draft. Please,
> could you clarify the approach?

Yes, you could represent an ERO as a subpath, i.e., a sequence of nodes
representing the selected path.

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?


> .- Service function is another of the properties considered for the
> path.. In my view, the service function is rather a client (or
> termination) of a given path, and not an intrinsic part of it.

(Answered by Med)


> .- Regarding the concept of path I wonder if it would be convenient to
> distinguish the idea of physical path vs logical path.

We already distinguish between physical and virtual (logical) nodes and
links, so perhaps a logical path would be a path consisting of virtual
nodes. Do you agree?

We think this also goes back to "entities may treat path elements at
different levels of abstraction": The physical topology could be one
level of abstraction and the logical topology could be higher level of
abstraction.


> .- I also was thinking on the realization of a path. I mean, 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. I presume that the purpose of the draft is about the latter, but
> some clarification would be benefitial.

Our intention is for the definitions to be flexible enough to accomodate
both.

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.

Any suggestions for wording are more than welcome.


> .- Finally some degree of recursiveness can be also considered. A path
> in a given layer is supported by paths on lower layers. Having this
> idea of recursiveness can be useful for purposes such as inventory,
> alarm correlation, multi-layer optimization, etc.

Is this concept of recursiveness covered by our concept of abstraction,
e.g., aggregating multiple "lower layer" path elements to a "higher
layer" path element?

Otherwise, could you provide a reference for the examples, please?


Best,
Theresa