Subject: [sfc] Review of draft-sfc-serviceid-header-01

From: Kyle Larose <[email-masked]>
Date: Wed, 14 Nov 2018 16:35:20 -0500

Joel asked for people to look over this draft. It's nice and short, so
I figured I'd take a stab at it to break my long silence. :)

For those who want a link:
https://tools.ietf.org/html/draft-sfc-serviceid-header-01

Overall, it makes sense. The draft clearly captures the problem we're
trying to address, while providing a good solution to it.

I do have a few pointed questions, along with some wider ones that may
warrant some discussion.

Specific questions:

> 3. Subscriber Identification NSH Variable-Length Context Header

> The classifier and SFC-aware SFs MAY be instructed via a control interface to inject or strip
> a subscriber identifier context header.

How does stripping work when there are multiple subcriber ID context headers?

---

> Also, the data to be injected in such header SHOULD be configured to nodes authorized
> to inject such headers.

Does this refer to the type/set of data to be injected (e.g. node X
should inject subscriber ID type Y), or does it refer to the actual
values: (e.g. node X should inject integer value Y for packets
originating from IP Z)?

---

> 4.  Policy Identification NSH Variable-Length Context Headers

> Dedicated service-specific performance identifier is defined to differentiate between services
> requiring specific treatment to exhibit a performance characterized by, e.g., ultra-low latency
> (ULL) or ultra-high reliability (UHR).

Are we saying here that the Policy Identification header is only to be
used for performance identifiers? Or is this just an example. The
majority of the text in this section discusses
performance/latency/etc, so it seems like that is the case. If so,
should we make the name of the header reflect that? Maybe "Performance
Policy NSH Variable Length ..."

That said, I would prefer if the header were more generic. Being
opaque, it could be used for many purposes. It'd be a shame to
restrict the ability to decide policy for purposes other than
performance simply because we couldn't see a use right now.

I think that the more generic use is intended by the text, but I find
leading the section with the performance use-case to be confusing.
---

> The policy identifier thus allows for the
> enforcement of a per-service policy such as a service classification
> function to only consider specific SFs instances during service
> function path establishment.

By service function path establishment, do you mean classification?
It's not quite clear to me if you mean for this to run as part of the
initial classifier (which doesn't really make sense, since that's
before we'l have added the NSH), or if we're defining a function which
reclassifies based on that input. Or, if it's simply used to restrict
the SFF's options when choosing the actual SF instance to send to. The
"classifier SF" case seems to be what is implied by the next
paragraph, so maybe this isn't a problem, but I found it slightly
confusing.

Thinking about more about the confusion I had, I wonder why we don't
just place the burden of choosing the path which meets the QoS
constraints/etc on the initial classifier? Do we foresee a case where
it does not have sufficient information about the network conditions
to make the decision? Is this just DSCP in NSH?

---

> Multiple policy identifier context headers MAY be present in the NSH; each carrying a distinct > opaque value but all are pointing to policies that need to be enforced for a flow.

This may seem obvious, but policies can conflict. Should we indicate
that dealing with such conflicts falls to the implementation, or
should be configured via the control plane?

---

General things to discuss:
1) I don't know how I feel about the fact that both of these options
are opaque variable-length values. With so little constraints, is the
protocol providing a great deal of benefit? I guess simply assigning
the types is useful. Further, providing guidance about how to
interpret them, and the control plane hooks that should be
implemented, will help implementers. But, I can't help but feel like
this will end up being used to build something complicated within the
opaque data. Lacking standardization of how information is packed into
the opaque structure, that information itself will be tied to specific
deployments/vendors/implementations/etc, possibly restricting interop.
within a deployment. Maybe that's fine?

Should we look discouraging such uses of the header? Or, should we
encourage it by providing more guidelines on how to make it
inter-operable?

Personally, I'm fine with keeping it as is. I worry that if we try to
do anything more, we'll just end up implementing context headers
within context headers for something that should really just be a
simple integer. But, I figured it was worth bringing up at least in
case others have a different opinion. :)

2) Should we provide guidance on what should and should not be used as
a subscriber identifier? Or, does requiring that the header be
stripped on egress act as a sufficient privacy guarantee?

3) Should we suggest that the subscriber id not be logged if possible?

4) The introduction suggests that the subscriber identifier's purpose
is to inform traffic forwarding policies. We can argue about what
constitutes traffic forwarding, but I think it wouldn't hurt to make
this more generic and suggest that the identifier is useful for any
policy applied by an SF.

Thanks,

Kyle

---

From: <[email-masked]>
Date: Wed, 14 Nov 2018 22:46:11 +0000

Hi Kyle, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Kyle Larose
> Envoyé : mercredi 14 novembre 2018 22:35
> À : [email-masked]
> Objet : [sfc] Review of draft-sfc-serviceid-header-01
> 

[Med] What we had initially in mind is to strip all instances of the subscriber ID context TLV. This is because all these instances are pointing to the same subscriber.

> values: (e.g. node X should inject integer value Y for packets

[Med] This refers to type/set data, typically. That's said, this is implementation-specific. 

> Policy NSH Variable Length ..."

[Med] Performance is only provided as an example.  

> leading the section with the performance use-case to be confusing.

[Med] We can update the text to make it clear this is not restricted to the performance example.

> By service function path establishment, do you mean classification?

[Med] We meant the SFP that will be constrained the policy TLV. The wording may be confusing. We can adjust it.  

> constraints/etc on the initial classifier?

[Med] That is indeed a deployment option. There might be cases where the classifier does not have the full visibility, think about hSFC case. Inserting the policy TLV will be helpful. 

 Do we foresee a case where
> to make the decision? Is this just DSCP in NSH?

[Med] As indicated above, the use is not restricted to performance. A service path can be selected in a distributed manner to meet a policy that is conveyed in the packet. 

> 
> > Multiple policy identifier context headers MAY be present in the NSH; each
> carrying a distinct > opaque value but all are pointing to policies that need
> to be enforced for a flow.
> 

[Med] We can add some text to warrant this. Thank you.

> within a deployment. Maybe that's fine?

[Med] We used to have specific format in previous version of the draft (IMSI, MSISDN, IP address, etc.) but the comments we got is that this can be used by misbehaving nodes from within the SFC-enabled domain. This might be a corner case, but with the opaque design, only entitled SFs will be aware of the semantic of the data and then can make use of it. 

> case others have a different opinion. :)

[Med] Thanks. I hope to hear more on this from the WG.

> stripped on egress act as a sufficient privacy guarantee?

[Med] Like any NSH TLV, there is no risk for TLV leak outside an SFC-enabled domain. This is an important characteristic compared to legacy practices such as http header enrichment. 

> 3) Should we suggest that the subscriber id not be logged if possible?

[Med] This is SF-specific. For example, SFs which have some kind of per subscriber quota  have to keep track of the subscriber. 

> this more generic and suggest that the identifier is useful for any

[Med] I agree with this.

> Thanks,
[Med] Thank you again for the review. 

> 
> Kyle
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc