Re: [PANRG] Review of draft-irtf-panrg-path-properties-02

[[e-mail]]

Hi Theresa, all, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Panrg [mailto:[e-mail]] De la part de Theresa
> Enghardt
> Envoyé : vendredi 26 mars 2021 03:02
> À : Holland, Jake <[e-mail]>; [e-mail]; draft-irtf-
> [e-mail]
> Objet : Re: [PANRG] Review of draft-irtf-panrg-path-properties-02
> 
> Hi Jake,
> 
> Thank you so much for your review!
> 
> Replies inline:
> 
> On 3/20/21 8:05 PM, Holland, Jake wrote:
> > 1.
> > I have a little confusion over "Node" definition.
> >
> >  From 2. Terminology:
> >     Node:  An entity which processes packets, e.g., sends,
> receives,
> >        forwards, or modifies them.  A node may be physical or
> virtual,
> >        e.g., a physical device or a service function provided as a
> >        virtual element.  A node may also be the collection of
> multiple
> >        entities which, as a collection, processes packets, e.g., an
> >        entire Autonomous System (AS).
> >
> >  From 3.1 Path Selection:
> > For example,
> >     for sending a small delay sensitive query, a host may select a
> path
> >     with a short One-Way Delay, while for retrieving a large file,
> it may
> >     select a path with high Link Capacities on all links.  Note,
> there
> >     may be trade-offs between path properties (e.g., One-Way Delay
> and
> >     Link Capacity), and entities may influence these trade-offs
> with
> >     their choices.  As a baseline, a path selection algorithm
> should aim
> >     to not perform worse than the default case most of the time.
> >
> > Just to clarify: is for example a DSCP-selected queue in a switch a
> > Node under this definition?  I think so, as it may have some
> specific
> > relevant properties that are different from other queues, such as
> > latency targets and capacity limits.
> >
> > But as written the answer seems unclear to me, and I feel like it
> > might cause confusion if used that way.  Would it be helpful to
> > include something this as an example too?
> >
> > I think the AS example shows some helpful scope in the sense that
> this
> > aggregates to a macroscopic context, but if I'm understanding
> > correctly that it's intended to be generalizable like this, I think
> it
> > might be helpful to clarify that depending on the properties and
> > dynamics under discussion, it can also be useful to slice to a more
> > microscopic context than a whole device or virtual device.
> 
> Yes, a DSCP-selected queue in a switch can be a Node.
> 
> To illustrate that a Node is not necessarily a physical or virtual
> machine, but can be defined in a more microscopic context, we have
> already included a service function as an example. To make it
> clearer, we can also add "a single queue" as another example for a
> (virtual) Node.

[Med] Another example we can add is the VRF or the more general concept of "VPN Node" defined in:

draft-ietf-opsawg-l3sm-l3nm-07:

   VPN node:  An abstraction that represents a set of policies applied
      on a PE and that belong to a single VPN service.  A VPN service
      involves one or more VPN nodes.  As it is an abstraction, the
      network controller will take on how to implement a VPN node.  For
      example, typically, in a BGP-based VPN, a VPN node could be mapped
      into a Virtual Routing and Forwarding (VRF).

> 
> I may add text for this some time next week, and then I'll create a
> PR in our GitHub repo. For now, I already created an issue:
> https://github.com/panrg/path-properties/issues/46
> 
> 
> > 2.
> > I think there's a lot of use of the word "entity" when a narrower
> "Host"
> > or "Node" would be better.
> >
> > I'm getting a vague impression that in some situations, like when
> > information is exposed to an entity that can use it to achieve
> goals,
> > like in "3. Use Cases for Path Properties", "entity" is intended to
> > capture nodes in general plus things like traffic engineering
> > controllers that might have no part in a traffic path, whereas in
> > other cases I think it refers only to a host (like in "3.2 Protocol
> > Selection"--is there any non-host that can select a protocol for
> its
> > data traffic?  When it's sending data traffic it's acting as a
> host,
> > right?), and it would be nicer if I wasn't guessing at the intended
> > scope.
> >
> > I think there's a few ways to handle it, but my first suggestion
> would
> > be to use "entity" or "entities" as-is in the definitions, and try
> to
> > excise those terms from the rest of the doc, and if there are cases
> that
> > can't use a word that's in the terminology section (or combinations
> like
> > "nodes or links") as a substitution without losing the intended
> meaning,
> > it suggests another term might be needed.
> 
> Yes, "entity" is intended to be broader than just nodes on the path
> and
> can include off-path devices like traffic engineering controllers.

[Med] Agree. That can be captured by making sure to convey the message that these entities may not belong necessary to the data plane, but to the control plane.  

 It
> doesn't have to be a physical device either, it could also be a
> service
> running "in the cloud".
> 
> I agree it would be good to substitute "entity" with a more specific
> term in many instances later in the document.
> 
> However, I am not sure what a good term for these is, as I'm not sure
> I
> want to overload "Node". But maybe it actually is a Node, which may
> be
> on-path or off-path, and maybe in some cases it has to be on-path?

[Med] Not sure about this. I'd prefer to add an entry for "entity" in Section 2 to cover the intended usage (data plane, control plane, on-path, off-path, can be a node/host). 

> (Though I imagine there could be cases where an off-path Node
> actually
> selects a protocol that some on-path Node then uses, or at least
> attempts to use.)

[Med] Yeah, this is for example the case of ATSSS (https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00#section-5.3) where the network instructs the host which protocol to use for traffic steering. 

> 
> > 3.
> > I had a slightly hard time with the Transparency example in
> Examples
> > of Path Properties:
> >
> >     Transparency:  A node is transparent with respect to a protocol
> >        header, payload, or both for a specific action if the node
> >        performs this action independently of the given
> >        (meta-)information.  Actions can for example be blocking
> packets
> >        or reading and modifying (other protocol) headers or
> payloads.  An
> >        IP router could be transparent for transport protocol
> headers such
> >        as TCP and UDP, in contrast to a NAT that actively modifies
> TCP
> >        and UDP header information.
> >
> > Is it correct to say that in this usage, Transparency is defined
> only in
> > relation to flow properties?
> 
> Transparency is defined in relation to a particular flow. Not sure if
> it's necessarily "in relation to flow properties", as I wouldn't say
> that a protocol header itself is necessarily a flow property. But I
> guess the presence of a header, or of a header field,  could be a
> flow
> property. For example, we already have a "Protocol Features
> available"
> property for features like ECN, and now one could define the actual
> presence/usage of ECN as a flow property.
> 
> > Is it correct that "block all TCP Syn packets" is transparent with
> > respect to IP but not with respect to TCP?  (Or does relying on the
> > protocol type already break that?  And if so, is that still
> transparent
> > with respect to the TCP payload?)
> 
> I think our Transparency definition does not yet go into that level
> of
> detail, but answering questions like these will refine it.
> 
> As a first proposal, I would say that blocking packets is not
> transparent to any part of a flow, as it prevents the entire flow
> from
> actually traversing the path. Therefore, it wouldn't be transparent
> with
> respect to IP either.
> 
> Would you agree with that?
> 
> Cyrill, do you have more thoughts on this, as you originally added
> the
> text for this Property?
> 
> > Is it also correct that a NAT is
> > transparent with respect to payloads, but not transparent with
> respect
> > to IP, TCP, or UDP headers?
> 
> Generally, yes.
> 
> We refined the Transparency definition to include different "degrees"
> of
> transparency with respect to a specific action. For example, NAT may
> not
> be transparent with respect to reading IP and TCP or UDP headers, but
> it
> could be transparent with respect to modifying TCP/UDP headers if it
> does not change port numbers (which might not be common or a good
> example - but I'm sure there's several on-path nodes that may read
> headers, but not modify them).
> 
> So I guess a specific path element can be "read-transparent" with
> respect to some parts of a packet/flow, and "modify-transparent" with
> respect to other (fewer) parts of a packet/flow.
> 
> Does that make sense?
> 
> > (If I got all that right, I feel like saying a few sharper examples
> > along these lines would help to clear it up better.  If not, I
> guess
> > I'm too confused to know what to suggest, and I think it needs
> > clarifying.)
> 
> I agree that adding examples will be good.

[Med] FWIW, another common usage of "transparent" is when a network function is invoked without requiring any signaling from the endpoints (unlike explicit mode) and while its presence is not easily detected by the endpoints (e.g., transparent proxies).

It would be useful if the overlap with the common usage is clarified/avoided. Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.