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

From: "Luis M. Contreras" <[email-masked]>
Date: Sun, 1 Dec 2019 10:32:43 +0100

Hi all,

After attending the presentation of the draft during the PANRG session in
Singapore, I have gone through the document and some comments / doubts come
to my mind.

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

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

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

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

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

Best regards

Luis

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: <[email-masked]>
Date: Mon, 2 Dec 2019 06:24:56 +0000

Hi Luis,

Please see one comment inline.

Cheers,
Med

De : Panrg [mailto:[email-masked]] De la part de Luis M. Contreras
Envoyé : dimanche 1 décembre 2019 10:33
À : [email-masked]
Cc : LUIS MIGUEL CONTRERAS MURILLO
Objet : [PANRG] Comments regarding draft-enghardt-panrg-path-properties

Hi all,

After attending the presentation of the draft during the PANRG session in Singapore, I have gone through the document and some comments / doubts come to my mind.

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

.- 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.
[Med] An SF can be a termination point if it is the entity providing the requested service, but it is an intermediate element that is crossed when a packet travels from on end to another (or others). An endpoint may decide to avoid paths with some SFs or select a path with some SFs. An endpoint may even force a path to include some SFs (explicit model) that wouldn’t be invoked otherwise.

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

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

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

Best regards

Luis

--
___________________________________________
Luis M. Contreras
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
Global CTIO unit / Telefonica

---

From: Theresa Enghardt <[email-masked]>
Date: Thu, 5 Dec 2019 17:46:12 +0100

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)

> 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