IRSG Review (Dave Oran): Can links be transparent?

[renghardt]

From the IRSG review by Dave Oran:

In “Transparency” you talk about nodes begin transparent or non-transparent. What about Links? Can’t they also be either transparent of non-transparent - for example tunnels that screw around with the content of the packets they are tunneling?

[boucadair]

Tunnels are terminated in endpoints (terminating points)... which can be seen as a service function. As tunnel/links are always anchored in terminating points, I'm not sure there is a need to stretch the transparency discussion to links independent of their terminating points.

[daveoran]

I must be missing something. Two nodes (both intermediate hops in a long path) have two different "links" between the pair. One is a "transparent" direct L2 link. the other is a tunnel of some sort, which may do strange things to packets. Are you saying that these two different path elements can't be distinguished with different path properties, including their transparency?

[boucadair]

I'm saying they can...based on the transparency offered by the "Tunnel Terminating Point" service functions. As a reminder service functions are also considered as nodes as per:

Node: An on-path entity which processes packets, e.g., sends, receives, forwards, or modifies them. A node may be physical or virtual, e.g., a physical device, a service function provided as a virtual element, or even a single queue within a switch. A node may also be an entity which consists of a collection of devices or functions, e.g., an entire Autonomous System (AS).

[daveoran]

I won't belabor the point, especially if the view of the authors is that anything other than a conceptual single arc between a pair of nodes is intended to be modeled as a service function and hence as a node in-and-of itself. My mental model is a bit different, as I generally would not think of things like GRE tunnels being service functions intend to b expose to users as a service.

[boucadair]

My mental model is a bit different, as I generally would not think of things like GRE tunnels being service functions intend to b expose to users as a service.

There are cases where exposing things such as GRE terminating points makes sense especially when they perform additional tweaks, see for example, https://datatracker.ietf.org/doc/html/rfc8157. Other encapsulation terminating points can be exposed as a service, e.g., MAP BR which is basically a tunnel encap/decap (https://www.rfc-editor.org/rfc/rfc7597).

[renghardt]

I agree with Med, though my reasoning is slightly different: According to our terminology in Section 2, a link indeed is just a "medium or communication facility" over which packets can be transmitted, a "conceptural arc between a pair of nodes" if you will. A link cannot modify or perform any other action on a packet. As the Transparency path property is about performing an action on a packet, it doesn't apply to a link. In the GRE tunnel example, I consider the software instance (which we can also call Service Function) at both ends of the link, which performs the en/decapsulation, a node, or part of a node. FWIW, there can be multiple links between the same two nodes, if you want to consider the "direct" L2 link and the GRE link separately.

So I don't think we need to change the definition here, but maybe it's worth adding a clarifying sentence about links at the end?

[daveoran]

i think it would be helpful to say in the text exactly what you say in the above comment, as I didn't take this away from the current text. Thanks.